Menu Item Clicked event remains unfinished

OpenSheetWithParm when opens a sheet from a menu item, menu item's Clicked event is not released immediately. instead all constructors of controls in the sheet are fired next, then open event is fired, after open event the activate event is fired and then if there are tab controls in the sheet then all selectionchanged events are fired of all tab controls.

During all that events processing the Clicked event of menu item (from which OpenSheetWithParm was called) remains hanging/unfinished/undone in the background. And as soon selectionchanged events are done the Clicked event is released.

Probelm i am facing is that declared Instance variables in the sheet are reset when process/focus goes back to Clicked event of menu item to close/finish itself. It does not mean that the Clicked script is not executed completely but something like a thread remain intact with Clicked event untill selectionchanged events are not done in the sheet.

Next thing is more confusing. When Clicked event's thread is destroyed focus is given back to the sheet and then at that time those events start firing one by one that were posted in constructors of controls in the sheet. In this process the jumping from sheet to menu backward releases instance variables. The variable specifically i am checking is a DataWindowChild as instance variable of the sheet which is reset and i have to re initialize it in posted _open event.

what i understand about this behavior is that some processing in sheet is completed immediately and some is left untill Click event's thread goes back to menu item script and close/destroy itself.

Is this behavior normal for menu item's clicked event?

Is it possible to tell clicked event to just open the sheet and die immediately( disregard anything that happens in the sheet but dont go back to the menu item event?

Is it possible to keep instance variables alive even if focus is shifted from sheet to menue?

Do you think i overlooked some problem in the events order?

Berka Frenfert Accepted Answer Pending Moderation

Tuesday, 26 March 2024 11:43 AM UTC
PowerBuilder
# 1

Gross: just the reference to GetChild variable is lost when focus (or may be i should call it process flow) is shifted to menu item and return back to sheet again.

for example: i call GetChild("user_code", dwc) in the open event where dwc is instance variable of the sheet

In open another event _open is posted already because sheet is inherited

When focus return back to sheet from menu clicked event and _open is executed then right there in_open i have to do the GetChild() again because dwc does not have any link to the user_code.

Comment

Berka Frenfert
Wednesday, 27 March 2024 06:41 AM UTC

to avoid any confusion i declared another testing variable which isnt used anywhere in code except for constructor of a datawindow control where i initialize it because constructor executes before any other event.

and last event where i used dwc.RowCount in a MessageBox after checking IsValid is _Open which inherently posted from Open. MessageBox from constructor shows 113 rows and MessageBox in _Open event shows 0 rows.

That test confirms that only DataWindowChild variables are effected. strange and PIA

Helpful 0

Berka Frenfert
Wednesday, 27 March 2024 07:46 AM UTC

I am sorry had to go home yesterday the time i was reading this post. also checked a few things this morning to make sure i write what i know.

Helpful 0

There are no comments made yet.

Benjamin Gaesslein Accepted Answer Pending Moderation

Tuesday, 26 March 2024 11:39 AM UTC
PowerBuilder
# 2

Is this behavior normal for menu item's clicked event?

I would say so, yes. The code of any event or method will not continue executing until a method it called has returned. This is normal control flow and expected behavior.

Is it possible to tell clicked event to just open the sheet and die immediately( disregard anything that happens in the sheet but dont go back to the menu item event?

What does "disregard" mean here? And what do you mean by "go back to the menu item event"? If you want the clicked event of your menu item to finish before the sheet is opened, you can try posting the OpenSheetWithParm call. Mind that this could cause issues if you're passing an object to your sheet because it might go out of scope in the meantime.

Is it possible to keep instance variables alive even if focus is shifted from sheet to menue?

Can you find out what exactly happens to your instance variables? Once initialized, instance variables should not "die" like you're describing.

Comment

Berka Frenfert
Wednesday, 27 March 2024 06:53 AM UTC

>> What does "disregard" mean here? And what do you mean by "go back to the menu item event"?

disregard means just ignore or dont wait for what happens next and complete the menu item script without waiting. As you said function call hold the execution of next line in the menu item script and wait for return value of the function, the idea of posting event was checked but to my surprize posted _clicked event does the same , wait for retrurn value of the function.

And this is the exactly the important point. when focus shifted from sheet to menu item (which i checked in debugger) and completed menu item script and then again returned to sheet there it lost dwc link to user_code. dwc is still valid but i guess has lost the link to user_code DDDW.

Helpful 0

Berka Frenfert
Wednesday, 27 March 2024 07:05 AM UTC

>> Can you find out what exactly happens to your instance variables?

I am unable to figure out the reason. except for one thing i doubt can be reason, In the window i posted an event inside another event that is already posted so that i can make sure that the last posted event in posts chain always execute in the end when every other event is already completed. This is not confusing because i tested execution sequence of all my events and they fire in the order they are supposed to be firing.

The only unintended unintentional unexpected execution in whole chain is the menu item clicked event(triggered or posted , both have same logic).

Another Interesting thing is that when the idea of posting an event from another posted event is not used then dwc reference to its user_code is not lost. And in that case focus shift from sheet to menu item during debugging is not lost when focus return back to sheet.

Helpful 0

There are no comments made yet.

John Fauss Accepted Answer Pending Moderation

Tuesday, 26 March 2024 11:37 AM UTC
PowerBuilder
# 3

Hi, Berka -

How does the menu item’s Clicked event fire the OpenSheetWithParm PowerScript function, via (implied) trigger or via (explicit) post?

If you do not want execution to return to the menu item, post the OpenSheetWithParm - it will then execute after the Clicked event has finished.

Best regards, John

Comment

Load more comments

Berka Frenfert
Wednesday, 27 March 2024 10:44 AM UTC

Hi Benjamin,

Thank you for the idea of POST function. I did not know that functions can be posted :(

It took me long time to re-evaluate events firing sequence.

Before posting OpenSheetWithParm() i wanted to check if modify() is being called. and that was the root cause of the problem DatawindowChild's link to user_code was lost somewhere between Open and _Open.

If it is possible, could you please give a bit more detail on why modify() does that.

Your skill solved a significant issue in my code and not only saved the day but also taught me two new things.

Thank you for your exceptional assistance!

True regards,

Berka

Helpful 0

John Fauss
Wednesday, 27 March 2024 14:33 PM UTC

Examine the table of DDDW.xxxxx properties in the following link: https://docs.appeon.com/pb2022r3/datawindow_reference/XREF_54577_dddw_property.html

As Benjamin mentioned, when some DataWindowChild (DWC) properties are changed, the reference to the DWC object becomes invalid. I presume this invalidation occurs because PB internally must to destroy and recreate the DWC object when some of these properties are modified. Please note this is not a new or recent change in PB's behavior... PB has worked this way as far back as I go (version 4) and possibly earlier. The table in this documentation indicates which DWC properties are affected by this behavior.

You may wish to carefully review the PB Help topics "trigger function and event" and "post function and event", as they provide nice explanations of some important distinctions between triggering and posting of events and functions and related information you should know about.

Helpful 1

Berka Frenfert
Thursday, 28 March 2024 12:03 PM UTC

Hi John,

You are correct about careful review of Help topics.

I have 2 versions of same app and older one is more than 2 years old. Older version seemed to be working fine but actually old version have problem.

Events order in newer version is perfect but because modify() behavior (which i certainly experienced in past but thought that PB itself had problem and i did not confirm by reading PB help) was not in my mind at that time neither newer version was tested properly, i faced the issue yesterday.

All modify() calls were collected in a special event which was triggered in Parent object (in older version). And triggered from constructor's last line.

That is why problem did not appear in older version because child objects's constructor executed after all calls to modify were done already and there in child's constoctor the DataWindowChild variable was initialized.

New version actually POST the special event for modify calls from constructor of parent object. and that is why the event execute after constructor of child object in which DataWindowChild was initialized. This way modify executed after constructor (the initialization) of child object and problem appeared.

Its purely coding related logic problem (modify is already executed and dataobject is set later). Posting modify from constructor is suitable approach because in many places open event decide wich dataobject will be set to a datawindow control.

Have you seen any PB app that let user add new columns, apply formulas, display error messages and save data and all new design changes everything at runtime?

Helpful 0

There are no comments made yet.

Resolved Menu Item Clicked event remains unfinished