showDialog from an ABL Window/procedure

I thought it could be caused by OE Service Pack (ID solution P165110).

This solution is related to a crash when closing a Form launched from an ABL window. But what you are describing is a crash when starting it.

Do I have to update my Service Pack?

Always a good idea 10.2B04 is the current release and that's almost 1.5 years more recent than 10.2B

I'd investigate a couple of other things:

1.) is the first wait-for statement in your session a .NETish WAIT-FOR, i.e.

WAIT-FOR System.Windows.Forms.Application:Run ()

2.) If you switch from the WAIT-FOR vForm:showDialog() to a simple vForm:Show() does it still crash?

If not than the issue might be related to the WAIT-FOR.

3.) When upgrading to 10.2B04 (or 10.2B02 at least) try the currently unsupported -IOEverywhere 1 startup parameter. That will lift restrictions on where WAIT-FOR (and PROCESS EVENTS) statements are legal in the Progress client. When there is any function or non-void method in the stack trace the WAIT-FOR is illegal without this parameter. The result is a STOP condition and they are sometimes not too gently handled while GUI for .NET Forms are started.

What is f-main.r? Is that a piece of ABL you or a GUI for .NET Form?

Hy Mike,

I'm sorry, I was wrong when I was saying that it's when I launch the form there is crash. It's when I close my form ;-)

So...

Always a good idea  10.2B04 is the current release and that's almost 1.5 years more recent than 10.2B

I think it's a good idea too. What are new in this release?

1.) is the first wait-for statement in your session a .NETish WAIT-FOR, i.e.

The main window (F-main) has a classic WAIT-FOR. Then into a ON CHOOSE trigger, I launch my .NET form.

2.) If you switch from the WAIT-FOR vForm:showDialog() to a simple vForm:Show() does it still crash?

No. But if I use vForm:Show() and then run an ABL Window, if I don't close this window before then .NET form, Progress crash. That's why, I use showDialog method.

3.) When upgrading to 10.2B04 (or 10.2B02 at least) try the currently unsupported -IOEverywhere 1 startup parameter.

I will try it.

What are new in this release?

Many fixed related to GUI for .NET You should check out the list of fixes included in the service pack, for me the -IOEverywhere 1 is really very important.

3.) When upgrading to 10.2B04 (or 10.2B02 at least) try the currently unsupported -IOEverywhere 1 startup parameter.

I might have used the wrong term here. I guess it's supported, but undocumented. That's expected to change in OE11.

And about :

But if I use vForm:Show() and then run an ABL Window, if I don't close this window before then .NET form, Progress crash. That's why, I use showDialog method.

How can I fix it? I would still use the Show() method :/

I think you need to modify your main window to use a .NET WAIT-FOR instead of an ABL WAIT-FOR.

WAIT-FOR System.Windows.Forms.Application:Run () . /* no parameters */

The ON CLOSE OF THIS-PROCEDURE Trigger then should include the

System.Windows.Forms.Application:Exit () .

That may be the root cause of your issue. Then you should be fine with the ShowDialog again. Mixing .NET and non .NET WAIT-FOR in the Progress client is a critical thing. .NET is designed to only allow a single message loop per thread. Another WAIT-FOR creates a second message loop. That's only o.k. for Dialogs.

Hi,

Thank you for your email. I'm currently out of the office for business. I will return on April 27. During my absence I will have limited access to email. For urgent matters, call our office, leave a message on my voice mail or contact Gary Calcott (gcalcott@progress.com).

Best regards,

Wouter

--

Wouter Dupré

Senior Solutions Consultant

Progress Software NV

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

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

I think you need to modify your main window to use a .NET WAIT-FOR instead of an ABL WAIT-FOR.

Agree and here is my new code:

The first program is a .NET form.

Two buttons into this form. The one show another .NET form like this:

DEFINE VARIABLE MyCustomerForm AS CustomerForm NO-UNDO.
        
MyCustomerForm = NEW CustomerForm ().
MyCustomerForm:show().

And the second button launch an ABL Window like this:

RUN c-win.w.

When I open ABL Window then .NET form and I close the first form...my .NET form crash (on a datagridview control...).

Guess it's due to WAIT-FOR in the ABL Form but it's impossible to make without this statement.

So in one Program you are running the

WAIT-FOR System.Windows.Forms.Application:Run () .

and in anouther one you have an ABL WAIT-FOR?

That should work (but is not recommended) as long as the first WAIT-FOR is the .NET WAIT-FOR and this one is terminated last.

Could you clarify which WAIT-FOR's you have where and what you need the ABL WAIT-FOR for?

The ABL WAIT-FOR is a standard "WAIT-FOR ON CLOSE" (.w program) and the problem occurs when I close this window while I've launched a .net form.

So I have to ensure that the user closes windows in the correct order.

Just a question unrelated: what are you using instead of "shared variables" into your .net classes?

The ABL WAIT-FOR is a standard "WAIT-FOR ON CLOSE" (.w program) and the problem occurs when I close this window while I've launched a .net form.

I still don't get the whole picture. Where do you have the .NET WAIT-FOR (WAIT-FOR Application:Run ())?

 Just a question unrelated: what are you using instead of "shared variables" into your .net classes?

GLOBAL-SHARED: Static properties of a "Session" class

SHARED: A context object known to a group of object instances.

From OpenEdge Architect, I run my main program Main.cls.

This Main program contains 2 buttons.

The one launches GridView.cls like this:

DEFINE VARIABLE MyMainClassInstance AS gridViewTest NO-UNDO.

MyMainClassInstance = NEW gridViewTest().

MyMainClassInstance:show().

GridView.cls is a simple form with a datagridview component bound to a

prodataset. Very simple.

And the second button launches a classic ABL Window, C-Win.w like this:

run c-win.

If I click on the second button (c-win.w) then click on the first

(GridView.cls) then close c-win....my datagridview on GridView.cls crash!

Exception: System.IndexOutOfRangeException: index 0 has no value

At System.Windows.Forms.CurrencyManager.get_item(Int32

index)

At

System.Windows.Forms.DataGridView.DataGridViewDataConnection.GetError(Int32

rowIndex)

Note that I have no calculated column or datagridview event, GridView.cls is

really really simple.

Hi,

Thank you for your email. I'm currently out of the office for business. I will return on May 13. During my absence I will have limited access to email. For urgent matters, call our office, leave a message on my voice mail or contact Gary Calcott (gcalcott@progress.com).

Best regards,

Wouter

--

Wouter Dupré

Senior Solutions Consultant

Progress Software NV

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

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

Like Mike said, your Main Program should contain the following line:

WAIT-FOR System.Windows.Forms.Application:Run () . /* no parameters */

Do you have that?

No. I thought it was only to launch .NET Applications from ABL and in my case I run directly from Architect.

So, when do I have to use this Wait-for?

No. I thought it was only to launch .NET Applications from ABL and in my case I run directly from Architect.

As I tried to explain before: It enables the client for proper event handling on the ABL and .NET side of things. The first WAIT-FOR in the application must be

WAIT-FOR System.Windows.Forms.Application:Run () . /* no .net main menu */

or

WAIT-FOR System.Windows.Forms.Application:Run (oForm) . /* .net main menu in oForm reference */

See http://blog.consultingwerk.de/consultingwerkblog/2010/09/openedge-gui-for-net-adoption-and-migration-strategies-part-2-parallel-use/

Deep breath...

I've read Mike's article but concretely I still don't know, with my example, how to fix this crash.

I've read Mike's article but concretely I still don't know, with my example, how to fix this crash.

Get rid of the WAIT-FOR CLOSE OF THIS-PROCEDURE or WAIT-FOR CLOSE OF {&WINDOW-NAME} in your main ABL window.

Get rid of the WAIT-FOR CLOSE OF THIS-PROCEDURE or WAIT-FOR CLOSE OF {&WINDOW-NAME} in your main ABL window.

It's done.

I give you a tiny archive with my sources files.

You will see inside:

Menu.w : my main ABL Window.

gridViewTest.cls : sample Grid View Form.

c-win.w : classic ABL Window.

I''m using Sports database.

My real problem is this one in attached files ( processus.jpg).

I've understood that on step 3, the bindingsource handle is no more valid! Progress bug?

[View:~/cfs-file.ashx/__key/communityserver-discussions-components-files/19/MainOE.rar.zip:550:0]

Hope to find any solutions...

supportg2 wrote:
Get rid of the WAIT-FOR CLOSE OF THIS-PROCEDURE or WAIT-FOR CLOSE OF {&WINDOW-NAME} in your main ABL window.
It's done.
Hope to find any solutions...

There's a WAIT-FOR in c-win.w, and that WAIT-FOR is being executed because you're running c-win.w NON-persistently (in the trigger it just says "RUN c-win."

Change that to RUN c-win PERSISTENT and things will work as you'd expect.

You should always run GUIs persistently (unless they're dialogs).

-- peter

Yes it works, it's great!

I confess that I never use PERSISTENT in my application and what will be the consequence on it? No stack oversize? Consequence on transactions?

I have to make sure that it's for my customers safe.

Thank you very much guys.

Well PERSISTENT is what you should always use for Windows.

NON-PERSISTENT should be used for dialogs only.

If you start windows non-persistently like you did until today you can get strange side effects, one of which you have noticed here.

Starting a window non-persistently makes it more or less modal like a dialog while windows must be non-modal.

One world, one wait-for to handle all your events (except for modal dialogs).

Therefore your application will become more stable and safer for your customers if you start your windows persistently.

-peter