As described previously (see Initialize and block on .NET forms), in order to handle input for a given .NET form, you must execute a single WAIT-FOR statement that calls a .NET input-blocking method that is appropriate for the type of form (non-modal or modal). Thus, for any number of non-modal forms for which you handle input simultaneously, you must use a single WAIT-FOR statement that calls the System.Windows.Forms.Application:Run( ) method to handle events for all of them (see Block on non-modal forms). If you use non-modal .NET forms and ABL windows simultaneously, you can also use this single WAIT-FOR statement to handle input for all non-modal .NET forms and ABL windows.

For modal forms (dialog boxes), you must use a separate WAIT-FOR statement that calls the .NET ShowDialog( ) method on each modal form that you handle, similar to handling an ABL dialog box (see Block on modal dialog boxes). You can also handle input for modal ABL dialog boxes in the same session by blocking for each ABL dialog box using the same WAIT-FOR statement when not using .NET forms.

If you are adding .NET forms to an existing ABL application that already uses ABL windows, and this application simultaneously executes more than one WAIT-FOR statement or other ABL input-blocking statement (such as UPDATE or PROMPT-FOR) to simultaneously handle non-modal ABL windows and non-GUI ABL events (such as socket events), you must ensure that the one WAIT-FOR statement calling the .NET Application:Run( ) method is also executing in order to handle input for your new non-modal .NET forms.

Note: Progress Software Corporation recommends that you use a single WAIT-FOR statement to process all the non-modal events in your application, including both .NET and ABL events. However, if you choose to simultaneously execute multiple WAIT-FOR statements (stacked WAIT-FOR statements) to handle ABL non-modal windows in addition to the single WAIT-FOR statement handling .NET non-modal forms, you must ensure that all such WAIT-FOR statements terminate in reverse order of execution. Otherwise, your application can have unpredictable behavior.
Note: Also, if in the context of Application:Run( ) you directly or indirectly execute an additional ABL input-blocking or event-processing statement that blocks on a non-modal ABL window, in certain contexts (such as within a user-defined function or non-VOID method) the AVM raises the STOP condition.

.NET and ABL use somewhat different models for the initialization, display, and closing of forms and windows. For example, when a WAIT-FOR statement calling Application:Run(rForm1) on a main form (rForm1) returns from execution, all non-modal forms that were displayed and processed by that statement also close automatically. However, you must respond appropriately and explicitly close (hide) any open non-modal ABL windows that are handled by the same WAIT-FOR statement. In general, you must observe all the ABL requirements for managing elements of the traditional OpenEdge GUI whether or not you also use elements of the OpenEdge GUI for .NET.