We are going to be using a combination of ABL windows / dialogs and .NET forms / dialogs in our application for quite some time.
What is the best way to handle the WAIT-FOR ? Obviously in 10.1C world, we have persistent windows, and one WAIT-FOR statement.
When it comes to the mixed environment, we will have .net forms being called from .w windows. In the "Advanced GUI" documentation, it states
"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"
Does this mean that the WAIT-FOR in my .w window is sufficient, or would it be better to have a .net form as the front-end with it's WAIT-FOR active, and run all ABL windows persistently ?
Slightly confused of England.
Hi Julian,
in the early days of the TP we had many disussion about this subject. Here's my understanding:
One world - one wait-for is still the rule (except for modal dialogs).
The one and only wait-for statement (usually in a menu screen) should be the WAIT-FOR System.Windows.Forms.Application:Run() .
The Run can have no parameter or a number of Forms as their parameter.
This leads to the conclusion that the main menu form needs to be migrated to .NET first - or you use the Run method without a parameter and use the Application:Exit() to terminate the WAIT-FOR somewhere (you might want to check MSDN for the Run method of the Application singleton).
We also discussed that there should be a runtime error message when it's detected that .NET Forms run within an ABL event WAIT-FOR. I don't know the status of this. Maybe somebody from PSC-dev can give us an update on this when they returned from PSDN live.
Mike (hoping that this does not increase the confusion).
One world - one wait-for is still the rule (except
for modal dialogs).
good.
The one and only wait-for statement (usually in a
menu screen) should be the WAIT-FOR
System.Windows.Forms.Application:Run() .
ok
The Run can have no parameter or a number of Forms as
their parameter.
ok
This leads to the conclusion that the main menu form
needs to be migrated to .NET first - or you use the
Run method without a parameter and use the
Application:Exit() to terminate the WAIT-FOR
somewhere (you might want to check MSDN for the Run
method of the Application singleton).
So, if I had a startup .p program I could run my main window (.w) persistently and then issue the "WAIT-FOR System.Windows.Forms.Application:Run() " in the .p
This way my main screen can be a .w, and I could then run all the forms by doing a myapp:Show() ?
We also discussed that there should be a runtime
error message when it's detected that .NET Forms run
within an ABL event WAIT-FOR. I don't know the status
of this.
During my testing I think I came across this message. I created a .w, added a button that did a "a = NEW foo" and then a:Show(). However, I only got the error once, and thereafter everything worked as I hoped it would (the button launched the windows form)
Maybe somebody from PSC-dev can give us an
update on this when they returned from PSDN live.
Mike (hoping that this does not increase the
confusion).
Somewhat eased it. I think. Hold on, errr, no that's right. Um. wait. maybe...
One world - one wait-for is still the rule (except for modal dialogs).
Actually, traditional ABL modal dialogs don't need their own WAIT-FORs either.
AFAICS the WAIT-FOR is needed for ABL.NET dialogs.
So, if I had a startup .p program I could run my main
window (.w) persistently and then issue the "WAIT-FOR
System.Windows.Forms.Application:Run() " in the .p
This way my main screen can be a .w, and I could then
run all the forms by doing a myapp:Show() ?
Well it would make more sense if the main window would be a .NET class.
IMHO the main window is usually the first candidate to be migrated to .NET.
Well it would make more sense if the main window
would be a .NET class.
IMHO the main window is usually the first candidate
to be migrated to .NET.
I always do things back to front - we're redesigning the main screen (total revisit now that we can use all manners of .net controls), so it will be a lot of the smaller (easier) screens that get converted first whilst we plan the "big bang!"
So, if I had a startup .p program I could run my main
window (.w) persistently and then issue the "WAIT-FOR
System.Windows.Forms.Application:Run() " in the .p
This way my main screen can be a .w, and I could then
run all the forms by doing a myapp:Show() ?
Yep. You might have to create a dummy Form, since the Application:Run() method wants at least one form in the session. But that dummy form doesn't need to be anything more than dummyForm = new P.W.Form().
(AutoEdge does this (in maincontrol.p), since there are cases where you'll never have a Form in the session (for instance, when running the Windows ABL GUI container style).)
-- peter