Run .w as dialog from .Net form

Posted by chrlau on 26-Sep-2012 08:35

Hi, I would like to run an old .w program from a new .NET form but as a dialog, can't seem to find how to do it with the good old run statement.

When I run another .NET form from my new .NET form, works great with WAIT-FOR clsInst:ShowDialog().

How can I run as an example the program ar/customer.w as a dialog? Actually i simply use run ar/customer.w.

Any help appreciated.

Regards, Christian

All Replies

Posted by rbf on 26-Sep-2012 09:18

Well normally the good old GUI program should contain something along the following lines of code:

  IF NOT THIS-PROCEDURE:PERSISTENT THEN
    WAIT-FOR CLOSE OF THIS-PROCEDURE.

This means that a simple RUN should do it.

Posted by Admin on 26-Sep-2012 09:28

Hi, I would like to run an old .w program from a new .NET form but as a dialog, can't seem to find how to do it with the good old run statement.

Unlike in the .NET UI the Progress UI uses a different type of widget for a dialog. It's a dialog-frame. When you create a Dialog in the AppBuilder and run it non-persistently (Dialog's don't support persistent run) it should behave as you'd like.

The other alternative would be to embed an ABL window in a .NET Form and then use the Form's ShowDialog() method.

Posted by chrlau on 26-Sep-2012 09:58

Ok I finally found how to resolve this issue.

I disabled the .NET form that is active before running the .w, then run the .w and then close the .NET form, it worked for me, it kind of simulates a dialog box, worked for me !

Here's the code:

  THIS-OBJECT:ENABLED = FALSE. /* disables the .NET form */
  RUN ar/customer.w.
  THIS-OBJECT:CLOSE(). /* closes the .NET form after */

Thanks a lot guys !

Christian

Posted by rbf on 26-Sep-2012 10:59

Well that solution does not fit the original question...

Are you saying that the .NET form can still be edited and closed while the modal GUI dialog is active? That should not be the case.

Anyway, make sure you test the result of the dialog before closing the .NET form as you probably don't want to close it when the user CANCELs the dialog.

Posted by Admin on 26-Sep-2012 11:13

Well that solution does not fit the original question...

 

I'd doubt he's using an ABL dialog at all. Sounds like he's running an ABL window.

Posted by rbf on 26-Sep-2012 11:48

mikefe wrote:

Well that solution does not fit the original question...

I'd doubt he's using an ABL dialog at all. Sounds like he's running an ABL window.

Ouch running a GUI window non-persistently so multiple WAIT-FORs are active - that is a recipe for disaster.

He is in for a lot of trouble since all other open windows in the same application will still be enabled as well.

This has nothing to do with GUI for .NET of course, the same problems would occurr in plain old GUI.

Posted by chrlau on 26-Sep-2012 12:55

That is correct, I am calling an ABL Window from a .NET form.

To clarify the way we are setup right now, we are in a mixed environment, our main screen is shoppro.w

From that menu, we call both .w's and .Net forms.

So the scenario I was describing is as follows:

  The application is launched with shoppro.w

  Then, I select an option that calls a .NET form.

  Then, from that form, I call either a .w or another .NET form.

  If I call another .NET form, I use this:

        /* This is a real Dialog */

        clsInst = DYNAMIC-NEW clsName().
        WAIT-FOR clsInst:ShowDialog().
        THIS-OBJECT:CLOSE().

  If I call a .w window, I use:

        /* I disable the .NET form, then run the .w, the user must close the .w, then the .NET form will be closed automatically, this simulates a dialog for me */

        THIS-OBJECT:ENABLED = FALSE.
        RUN VALUE(lvPrg:SelectedItems[0]:TEXT) .
        THIS-OBJECT:CLOSE().

This scenario works for me because I want to make sure that the user can launch only 1 program from the .NET form.

Thanks,

Christian

Posted by mopfer on 26-Sep-2012 16:37

We run in a similar mixed environment, and as Mr. van Dam says, running windows non-persistently in that environment causes problems.  If you add a PERSISTENT at the end of your RUN VALUE statement the envirnoment will be happier.  If the application such that there is currently processing that happens in the calling method after the window closes, that code will have to be moved to a method that gets called by the window as it closes to keep the processing in order.  Not much fun, but it can be made to work.

Posted by Tung on 19-Mar-2013 06:25

We have a similar setup, the main screen was converted into .NET form and runs our old ABL ADM1 windows persistently. Some of those windows have buttons that run other windows non-persistently, this worked okay on Windows XP and 7.

But we have a new customer on Windows 2008 Server and when they click a button in a window to run another window, it appears then disappears because it isn't run persistently.

Has anyone else experienced this? Is the only solution to manually go through all our code to add PERSISTENT to the RUN statements?

Posted by Wouter Dupré on 19-Mar-2013 06:26

Hi,

Thank you for your email. I'm currently out of the office, travelling for business. I will return on March 20, 2013. During my absence I will have no or very limited access to email and phone. For urgent matters, please call our office general number +32 15 30 77 00.

Warm regards,

Wouter

--

Wouter Dupré

Sr. Systems Engineer

Progress Software NV

A. Stocletlaan 202 B | B-2570 Duffel | Belgium

Office +32 (0) 15 30 77 46 | Mobile +32 (0) 478 50 00 49

This thread is closed