+- Atozed Forums (https://www.atozed.com/forums)
+-- Forum: Atozed Software (https://www.atozed.com/forums/forum-1.html)
+--- Forum: IntraWeb (https://www.atozed.com/forums/forum-3.html)
+---- Forum: English (https://www.atozed.com/forums/forum-16.html)
+----- Forum: IntraWeb General Discussion (https://www.atozed.com/forums/forum-4.html)
+----- Thread: Mainform update on return from subform ? (/thread-1168.html)
Pages:
1
2
RE: Mainform update on return from subform ? - DanBarclay - 08-07-2019
(08-07-2019, 01:08 PM)SorenJensen Wrote: Hi Dan,
Trying to figure this non-modal issue out in a clever way, I need a little guiding:
In the non-modal environment, any lines in the procedure after the form.create.show, will be executed right away but only acting on data before the form.create. And at the end of the procedure, the calling form is terminated. As far as I understand it, the calling form, will be reactivated, as if it was just launched, once the called form terminates.
As such, the purpose of UserSession is (among others I presume) to keep values between page refreshes, and can be used to pass data between forms. I take it, the Usersession form, is NOT refreshed during the life of an application. But if I initialize values in it as part of the launch of the mainform, I'll need to know that I've done that before, so that I do not overwrite any data from before, being passed between forms.
Are the any preferred ways of doing that ?
One way to visualize the code operation, and process, is to picture a "completion" operation that actually executes the things you have specified in your code. As an example, if you "show" a form, the form is not rendered or started until after all of your code is complete. Your .Show method only queues the operations to render the form. That is, changes in color, size, position, components, ANYTHING is not touched until this "post code" completion looks over your changes and then sends a rendered form to the browser. In VCL, those operations would have been applied to the form/component as your code executed them.
That's a good starting place... but also note that you can participate in the rendering operation if you want to put code in other events (render, etc) but you should get a good picture of how things are built first.
Also, the forms you have used are in a stack. If you have shown forms A, B, C (with C current) then if you kill C it will automatically make B the "current form", unless you have told it to start some other form. Whatever is the "current form", whether it is "B" from the stack or "D" that you decided to ".Show", will be rendered. The form "B" (your mainform in this case) will be rendered anew, including the FormLoad and other events, just as a new form ("D") would be shown.
As for UserSession, it is a Data Module (not a form) and exists for the entire life of the user's session. It is completely independent of forms. It gives you a place to put data (or objects) that you want to keep up with beyond a form.
The above description is very generalized, not precisely the way everything works under the hood, but is a good way to start your understanding of how it works. When starting out I created a few test apps (starting from some of the demos) and explored the boundaries. I strongly recommend that you do that. Put dummy code in some of the events, create and destroy forms and components, etc, and just play with it. As you discover the details of how things work, you'll continuously think "Of course! That's exactly how it should work!".
Chad mentioned you can also do callbacks and other things in addition to tinkering with the rendering, but I'd suggest that you get the basics under control first.
Dan