SIZE EVENT in Dialog

Opto_Will

I have an issue with the SIZE event, that is being called multiple times opening a form, taking a LONG time.

First a bit of background.....
I have a form that I initially created to run from a FW_COMMAND from the Ribbon Control while in development and testing. It is a Databound Window. It uses SRP_TAB and has a couple of hundred fields. Performance was reasonable.

Now I am trying to turn it into a Dialog as that is it's final use case, as it will never be run stand alone from the Menu.
However, now it is taking a good 30 seconds to get control upon launch of the Form which renders it frustratingly unusable.

My simple test is just open the form and click a 'Close' button immediately when I can and then wait for response. (The Close now has a Debug in it so I can capture various Form based variables I am setting).
The CREATE is not an issue. It processes fast.
You can see below the repetitive SIZE pretty much consumes over 20+ seconds when called a s a dialog.
It takes 26 seconds to respond to the CLICK for the close in my example. This indicates how long it is taking to be able to use the screen

Apart from the Call stack, I am capturing Info via a GoSub at the top of the Commuter just to log the current Event, how many times that Event has happened from launch, and the time of that occurence.

This is when being called from a Dialog. The command is:
rv = Dialog_Box("DBW_FORM_NAME", @WINDOW, CreateData)





This is calling that exact same Form using that carry over FW Command I have yet to remove.
[There is no CreateData to process. This is handled in the CREATE event with defaults.]
As you can see, the EventFlow is different and the Size Events are much quicker.





My question is what is the difference of a Form's Eventflow when started from a Dialog and, morre impoortantly, what might be making those SIZE events WAY slower when doing so?

DonBakke

I would be helpful if we knew what was in the call stack each time the SIZE event was triggered. That might reveal some unexpected activity that could be used to resolve the problem.

Aside from that, does the dialog become visible prior to the Promoted CREATE event calls SRP_Show_Window?

Opto_Will

Happy New Year Don (and SRP Team and fellow forum followers) !

I would be helpful if we knew what was in the call stack each time the SIZE event was triggered. That might reveal some unexpected activity that could be used to resolve the problem.

I captured the Call Stack via DEBUG for every time SIZE was was tiggered, via the Commuter . Every instance showed the same Call Stack above.

Aside from that, does the dialog become visible prior to the Promoted CREATE event calls SRP_Show_Window?

Short answer there is yes, It is visble by the end of the Promoted CREATE but is unresponsive to any input for another 25ish seconds or so while is goes through all the other 'background' Events.


I am about to create a Dummy copy of this form and remove all the Controls to see how that behaves.

Opto_Will

What would be too many Controls for a Dialog to handle reasonable?

No 'Silver Bullet' as such but I have progressively stripped out all the Controls and the time-to-respond time kept dropping. Removing masses of controls saved a few seconds. removing a couple of dozen more saved even more time than the mass but the savings kept accumulating.

Performance is now good ok but, of course, there are only like 6 or 7 controls.

We do a similar Dialog for a non-DataBound window and that would easily have 70-100 Controls and doesn't exhibit the same behavior.

This DataBound window has something like 200 (or a touch more)?
Both use the SRP_TAB, which I understand has overhead but that was the first thing I removed with minor effect.

DonBakke

@Opto_Will

Short answer there is yes, It is visble by the end of the Promoted CREATE but is unresponsive to any input for another 25ish seconds or so while is goes through all the other 'background' Events.

I'm not sure the way you answered my question is clear. Does "by the end" mean the same thing as "prior to the Promoted CREATE event calls SRP_Show_Window"? If so, then I'm not surprised that the form is incurring more overhead than expected. Visible forms incur overhead as other activity changes things in the window. Ideally, the forms would be invisible until the last possible moment. Something to look into, especially because FrameWorks forms are normally invisible until the end of the promoted CREATE event. I am curious why this form is already visible.

What would be too many Controls for a Dialog to handle reasonable?

I don't think there is a simple answer to that question. It really is a "your mileage may vary" situation. A lot of it depends on what your form is doing. That said, I noticed that you do not have any CHANGED events being logged in your previous screenshot. Is that because there are none or is it because you didn't add a check for them? If the latter, I am curious if you add a check for the CHANGED event if you will get a lot of hits. That might be a more relevant issue than the SIZE event.

Opto_Will

I apologize Don, It wasn't clear (and was wrong to the question you asked anyway)

Right at the end of the PROMOTED_CREATE_EVENT.POST (Frameworks) there is this code:
SRPShowWindow = Get_Property(@Window, '@SRP_SHOW_WINDOW') Visible = Get_Property(@Window, 'VISIBLE') Begin Case Case Len(SRPShowWindow) SRP_Show_Window(@Window, SRPShowWindow<1>, SRPShowWindow<2>, SRPShowWindow<3>, True$, '', False$, False$) Case Not(Visible) SRP_Show_Window(@Window, '', 'L', 'T', True$, '', False$, False$) End Case
Immediately before this there is NO Window displayed. Right after it, the Window IS displayed (but unresponsive)


There are no Changed events, not yet anyway. Basically the form is a whole lot of EDL's. The user enters some info, hits an OLE Button and it goes off and calculates stuff via a Service and then returns a lot of info into teh remaininhg field in teh Dialog. Another OLE button saves that Data to a table and closes the Dialog, returing the data table entry key to be stored at the origin poiint of the dialog (as supporting info).

I am abbout to start adding fields back into my stripped out test. I will pop in a Change then and see what it does.
I actually dont expect it to do anything as I was already capturing (as per my first post) ANY event that triggered in the Commuter. We shall see.

DonBakke

I actually dont expect it to do anything as I was already capturing (as per my first post) ANY event that triggered in the Commuter.

I guess you did mention this, albeit it was inferred. I'll plead the "wall of text" defense. ;-)

I think I would focus on what is happening during the SIZE event itself that is consuming so much time.

Dialog_Box creates a tight loop and relies on Yield() to allow the dialog boxes' event handlers to be processed. As a result, this incurs more overhead and it allows other queued events to get executed as well. Since the OLE events are asynchronous, they will get executed last. As an experiment, put an OI button on the form and see if it responds quicker.

You can also experiment with the BLOCK_EVENTS SYSTEM property.

Opto_Will

I guess you did mention this, albeit it was inferred. I'll plead the "wall of text" defense. ;-)

A VERY valid defense. I shuffle between 'ask a simple question with no context', which inevitably leads to MANY questions and 'present the entire bank of evidence' upfront. I never seem to find the right balance....

I think I would focus on what is happening during the SIZE event itself that is consuming so much time.

Also a good note. Not sure what is triggering the Size. I have no code asking for it. I figured it was deep in Frameworks code (hence why I was trying for a shortcut). Last time I tried to track something through Frameworks with all the activity, my collegues found me huddling in the corner mumbling to myself ;-)

I will certainly give the OI button a Test. The OLE Button I was using to test was just because it was already there and easy as a capture point. Looks like I picked the worst available option! When I noted 'unreponsive' I meant to get in and do pretty much anything, click into a EDL, trigger a option, drag the Window, etc. so I dont expect too much of a difference.

BLOCK_EVENTS. I recall using that once. I did make a slight difference in performance for that instance but it also captured (blocked) a few other things that we didn't want so we had to drop the use. I will have to reinvestigate.

DonBakke

The SIZE event is triggered whenever the form is resized (obviously) or moved. I was convinced quickly that you weren't triggering it in your own code, but that it was responding indirectly to other things. It could still very well be underlying OI stuff.

Opto_Will

A OI BUtton made no difference.

However, I might have a solution, if not an answer.....
I will report back soon.