WebForms Core provides several additional event methods for controlling browser event behavior, triggering existing events, configuring Master Pages, and adding confirmation dialogs to existing events.
These methods do not represent a separate communication protocol such as HTTP, SSE, WebSocket, or Front Events. Instead, they provide additional control over how events are triggered and handled by WebFormsJS.
The TriggerEvent method programmatically fires a specified event on a target element. The element is identified through an InputPlace, which acts as a reference to the element you want to trigger the event on. This allows you to simulate user interactions — such as clicks or key presses — without any actual user input.
The HtmlEventListener parameter specifies the event to trigger. An optional ConstructorName can be used when the event requires a specific event constructor.
An event constructor can also be specified:
The available constructor categories include mouse events, keyboard events, UI events, focus events, input events, and general events.
Note:TriggerEventutilizes theHtmlEventListenerevent definition, even for direct events that do not involve a listener. Therefore, theHtmlEventListenerclass must be used for both direct events and listener-based events. Please note that theHtmlEventclass and strings prefixed with "on"—such as "onclick"—should not be used.
The SetPreventDefaultEvent method prevents the browser's default action for an assigned HTML event.
For example, the default action of a link can be prevented for its click event:
The EventListener form is provided by SetPreventDefaultEventListener:
The two methods allow the same behavior to be defined using either the HTML event or EventListener representation.
| Method | Event definition |
|---|---|
SetPreventDefaultEvent |
HtmlEvent |
SetPreventDefaultEventListener |
HtmlEventListener |
An assigned prevent-default behavior can be removed with RemovePreventDefaultEvent or RemovePreventDefaultEventListener.
For example:
The SetStopPropagationEvent method stops propagation of the specified event from the selected element.
For example:
The EventListener form is provided by SetStopPropagationEventListener:
This allows event propagation behavior to be controlled without writing a JavaScript event handler manually.
Stop-propagation behavior can be removed with the corresponding removal methods.
For example:
The MasterPages methods provide a page-configuration mechanism in WebForms Core that can be used to implement a Master Pages style of page architecture.
Master Pages are normally assigned to the onload event of the body element. With this approach, a Layout is returned for every browser request and every route. The Layout contains the Master Pages event registration on the body element.
After the body onload event occurs, WebFormsJS sends a GET request to the server through the Master Pages mechanism. Because the request generated by WebFormsJS contains the Post-Back header, the server can distinguish this request from the initial page request.
As a result, the server does not return the Layout again for this request. Instead, it returns the page associated with the requested route.
The general request flow can therefore be represented as:
body element.body onload event occurs.Post-Back header.This approach separates the common page structure from the route-specific page content while retaining the HTML-based structure of WebForms Core.
The SetMasterPagesEvent method assigns the Master Pages behavior to an HTML event.
The optional OutputPlace specifies where the page returned by the Master Pages request is placed.
In a typical Master Pages configuration, the event is assigned to the body onload event.
The EventListener form is provided by SetMasterPagesEventListener.
For example:
The two methods provide the same Master Pages mechanism through the two event-definition forms used by WebForms Core.
| Method | Event definition |
|---|---|
SetMasterPagesEvent |
HtmlEvent |
SetMasterPagesEventListener |
HtmlEventListener |
Master Pages event assignments can be removed with RemoveMasterPagesEvent and RemoveMasterPagesEventListener.
For example:
The Master Pages configuration can be combined with a Service Worker to improve client-side efficiency. A Service Worker can cache the Layout on the client, allowing the common page structure to remain available locally while route-specific content is requested separately.
This approach can reduce repeated transfer of the same Layout and can improve the efficiency of applications that use a common page structure across many routes.
The Master Pages mechanism itself is responsible for the page-configuration flow. Service Worker caching is an additional capability that can be combined with it.
Note: The complete Master Pages architecture and its implementation patterns are documented separately in later sections.
The AssignConfirmEvent method attaches a confirmation dialog to an event that has already been assigned to an element.
Unlike the other Event and EventListener assignment methods, AssignConfirmEvent does not define a new event through an HtmlEventListener. It applies a confirmation requirement to an existing HTML event.
For example, an existing click event can be given a confirmation dialog:
When the user triggers the event, the confirmation is displayed first. The assigned event is executed only when the user confirms the operation.
The confirmation can be customized through the method parameters:
| Parameter | Description |
|---|---|
InputPlace |
The element containing the existing event. |
HtmlEvent |
The already assigned HTML event to which confirmation is applied. |
Text |
The confirmation message. |
Type |
The confirmation message type. |
Title |
The confirmation dialog title. |
OkText |
The confirmation button text. |
CancelText |
The cancellation button text. |
Important:AssignConfirmEventworks withHtmlEventand does not have an EventListener version. It assigns confirmation behavior to an event that is already assigned.
An assigned confirmation can be removed with RemoveConfirmEvent.
For example:
Removing the confirmation does not represent removal of the underlying event itself. It removes the confirmation behavior associated with that event.
The following table summarizes the additional event-control methods provided in this section.
| Method | Purpose |
|---|---|
TriggerEvent |
Programmatically triggers an event. |
SetPreventDefaultEvent |
Prevents the default action of an HTML event. |
SetPreventDefaultEventListener |
Prevents the default action through an EventListener. |
RemovePreventDefaultEvent |
Removes a prevent-default event assignment. |
RemovePreventDefaultEventListener |
Removes a prevent-default EventListener assignment. |
SetStopPropagationEvent |
Stops propagation of an HTML event. |
SetStopPropagationEventListener |
Stops event propagation through an EventListener. |
RemoveStopPropagationEvent |
Removes a stop-propagation event assignment. |
RemoveStopPropagationEventListener |
Removes a stop-propagation EventListener assignment. |
SetMasterPagesEvent |
Assigns the Master Pages mechanism to an HTML event. |
SetMasterPagesEventListener |
Assigns the Master Pages mechanism through an EventListener. |
RemoveMasterPagesEvent |
Removes a Master Pages event assignment. |
RemoveMasterPagesEventListener |
Removes a Master Pages EventListener assignment. |
AssignConfirmEvent |
Assigns confirmation behavior to an existing HTML event. |
RemoveConfirmEvent |
Removes confirmation behavior from an existing HTML event. |
Other Events provide low-level and architectural event controls that complement the communication and execution mechanisms documented in the preceding sections.
TriggerEvent allows events to be triggered programmatically. Prevent-default and stop-propagation methods control browser event behavior. Master Pages events provide a page-configuration mechanism based on a Layout and route-specific page requests. Finally, AssignConfirmEvent adds confirmation behavior to an existing HTML event without creating a separate EventListener definition.