Value-Changed Triggers not always firing

Posted by justinfowler on 30-Mar-2010 11:53

I have a .NET form class that runs a ABL window program persistently. (more here http://communities.progress.com/pcom/thread/25277)

All triggers and controls I talk about below are in the ABL window.

If I launch the screen by running the wrapper program directly, no issue.

Now I've put it into the application, the wrapper is launched in between a set of window-1:sensitive commands.

eg.

window-1:sensitive = false.

run launchDotNet.p(param).

window-1:sensitive = true.

If I take out the sensitive commands, no issue (except I can do stuff on the window below, which I don't want).

Otherwise the following happens all the time:

1) Load Form -> UnCheck Toggle Box - Vale-Changed trigger does not fire (Box is unchecked on screen) -> Check Toggle Box - Trigger Fires

2) Load Form -> Change Radio Set Selection - Trigger never fires no matter how much I change the radio-set selection.

3) Load Form -> Press a button -> On Choose trigger fires, no issue -> Now the Toggle Box and the Radio Set triggers are working as expected!

Has anyone encountered this behavior?

OpenEdge Development - Forum

All Replies

Posted by justinfowler on 30-Mar-2010 13:54

Tried the suggestions in this KB article:

ID: P93781
Title: "VALUE-CHANGED trigger does not fire as expected for a widget when using mouse"

No success. There are no on leave triggers in the window at all.

Posted by justinfowler on 07-Apr-2010 14:24

Work around is to replace the 4GL toggle-box and radio-set with .NET controls.

Posted by Wouter Dupré on 07-Apr-2010 14:26

Hi, I'm out of the office on vacation. During my absence I will have no or limited access to my e-mail.

For immediate assistance please call our office at +32 (0) 15 30 77 00.

Best regards,

Wouter.

--

Wouter Dupré

Senior Solution Consultant

Progress Software NV

Stocletlaan 202 B| B-2570 Duffel | Belgium Direct Line +32 (0) 15 30 77 00 Fax +32 (0) 15 32 12 60 Mobile +32 (0) 478 50 00 49 wdupre@progress.com

Posted by Admin on 07-Apr-2010 15:07

Can you share a sample that demos this behaviour? I use embedded windows a lot and haven't seen the behaviour you are describing.

Which version of OpenEdge are you using?

Posted by justinfowler on 07-Apr-2010 15:43

I am using 10.2B.

Wow I just put this together in the last 15 min so sorry it is so sloppy. I'm actually kind of surprised I was able to reproduce it outside the application, but here it is!

RUN mEdtScr.w.

Click the button, toggle the toggle box. Trigger does not fire the first time.

Remove the :SENSITIVE commands and it WILL fire the first time.

Let me know what you find out.

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

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

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

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

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

Thanks,

Justin

Posted by justinfowler on 08-Apr-2010 09:16

Did it reproduce for you?

Posted by Håvard Danielsen on 09-Apr-2010 15:22

I cannot think of any valid reason why setting a window sensitive false should have any effect on events in another window. You should contact Support and report this as a bug. Note that I may very well miss known limitations when using .Net Forms and ABL windows together, so Support will have the final say in whether this really is a bug.

Posted by Admin on 09-Apr-2010 20:34

Yes!

And here's how to fix it: The first (or top-most) active WAIT-FOR statement when using .NET objects and events should be the

WAIT-FOR System.Windows.Forms.Application:Run () /* with or without a Form reference. */

I've changed that in your mEdtScr.w - I've also added the

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

to the WINDOW-CLOSE trigger.

In mEdtScrLaunch.p there is no need for an additional WAIT-FOR (except you want it modal) statement.

So I've replaced the WAIT-FOR (and the following cleanup code) with

c123:Show () .
So the first VALUE-CHANGED Trigger will occur. Anyway the behaviour looks suspicious. The way I described it is the proper way to use ABL windows and .NET Forms together. You should report your behaviour to tech support anyway. I more informational behaviour (error message) is what I'd expect to see.
Sample attached.
[View:~/cfs-file.ashx/__key/communityserver-discussions-components-files/19/ValueChanged.zip:550:0]

Posted by justinfowler on 12-Apr-2010 09:30

Hi Mike,

Thanks so much for the response!

I've got a couple concerns with the changes. One is the :SENSITIVE commands no longer do their job. So I can open many instances of testForm.

Second, we need to imagine mEdtScr.w as being a very large screen inside of a very large application which has been around for 20 years. The wait-for 'go' that you replaced with WAIT-FOR System.Windows.Forms.Application:Run () is going to cause me a lot of stress. eg replace all the apply 'go' etc.

Also, this wouldn't be the top-most wait-for. Each screen in the app has a wait-for so you would have 5 screens open at this point. Lets not get into this lol!

So my goal is that I want zero .NET in mEdtScr.w and I want all of the .NET to be handled inside a wrapper that opens the new form with the embedded mEdtScr2.w in it.

Let me know what you think. I really appreciate your input!

Justin

Posted by Admin on 12-Apr-2010 22:01

I've got a couple concerns with the changes. One is the :SENSITIVE commands no longer do their job. So I can open many instances of testForm.

 

Is it not doing anything or do we miss to execute that due to the code changes we've made? I don't remember but it would be important to know.

The wait-for 'go' that you replaced with WAIT-FOR System.Windows.Forms.Application:Run () is going to cause me a lot of stress.

Explain me why! The program in which you have the WAIT-FOR GO becoming replaced with the WAIT-FOR Application:Run () should only need an ON GO Trigger which does the Application:Exit () call.

Also, this wouldn't be the top-most wait-for.

It has to! The topmost WAIT-FOR has to be the WAIT-FOR Application:Run () when using the .NET GUI in the AVM.

Posted by justinfowler on 13-Apr-2010 08:15

I've got a couple concerns with the changes. One is the :SENSITIVE commands no longer do their job. So I can open many instances of testForm.
Is it not doing anything or do we miss to execute that due to the code changes we've made? I don't remember but it would be important to know.

Your change to mEdtScr.w (replaced wait-for go with wait-for system...application:run().) is causing the :sensitive commands around the .p that launches the .net class to do nothing.

This means I can click the button in the window behind it and launch the .net form over and over again.

The wait-for 'go' that you replaced with WAIT-FOR System.Windows.Forms.Application:Run () is going to cause me a lot of stress.
Explain me why! The program in which you have the WAIT-FOR GO becoming replaced with the WAIT-FOR Application:Run () should only need an ON GO Trigger which does the Application:Exit () call.

You are right about that. I am just trying to minimize the changes I make to the initial 4GL screen since these are giant windows/programs that have been around for years. People seem to be more receptive to gradual change. Putting .NET commands here is a change (small or big, doesn't matter) to a main program.

Also, this wouldn't be the top-most wait-for.
It has to! The topmost WAIT-FOR has to be the WAIT-FOR Application:Run () when using the .NET GUI in the AVM.

Sorry I misspoke. This won't be the ONLY wait-for.

I need a solution that does not modify mEdtScr.w and I need the SENSITIVE commands to work.

Anyway, I have a tech support case open with Progress so I will keep you updated.

Justin

This thread is closed