Piotr,
On Thu, Nov 23, 2017 at 5:14 AM, Piotr Chabot Stadhouders via 4D_Tech <
4d_tech@lists.4d.com> wrote:
> As I understand correctly, when not on page 1, this subform is only
> initialized when the page is loaded
>
I assume you are talking about a subform you placed in the design
environment and not one where you used OBJECT SET SUBFORM.
I'll also assume by "initialized" you mean it fires an On load form event.
When and how often a subform gets the On Load form event depends on what
page it's on, as you have noticed.
If the subform is on:
page 0 - On Load ONLY the first time the parent form is loaded
page 1 - When the form is loaded AND each time you re-load page 1
(assuming the parent form has more than 1 page)
page 2+ - Each time that page is loaded - which means each time you use
GOTO PAGE (n)
You can see this for yourself: make a simple subform with a single
variable. The form method simply writes the form event to this variable and
then calls the parent method. Make a 2 page form and put this subform on
Page 0, 1 and 2 (label them to keep them straight). Load the parent form
and watch the how each form event is handled.
> In my widget I have an attribute defined called "enabled"
> When using a dropdown for example, I can disable the dropdown "On load",
> even when the dropdown is on page 2
> Because the widget is not initialized on load (because it is on page 2), I
> have to "remember" the disabled state in a variable, or re-execute the
> disable logic, when changing to page 2
>
Now we're talking about strategies for managing subforms. As with most
things 4D there isn't a single strategy that's 'best' for every situation
and especially with subforms because they can be used in so many different
ways. With that in mind my preferred strategy for handling subform config
is to put the subform config in a process method and call it from the
parent form.
There's no rule that says the subform has to initialize itself or if it
does the code has to be in the subform method. Sometimes it's easier if you
control when this happens. So just move all the subform config code to a
process method and call it using EXECUTE METHOD IN
SUBFORM("subform";"Subform_config_method"). A bonus here is you can pass
params, like a c-obj, to dial in the setup. You can also call it from the
subform method if you need to.
This is especially handy if, as you describe, you want to do all the
config while the parent form is loading. This way you can. Or to circle
back to the case of using OBJECT SET SUBFORM this is a reliable way to
handle config.
While trying to eliminate variables I have to introduce others. This
> doesn't make sense to me
>
True but it's a matter of scope. A subform, especially a widget, is like
a mini-process within the parent form that can have its own variables and
it's own set of form events it responds to. That can be quite useful but it
means you have to have a little more infrastructure on the subform to take
advantage of it. Again a couple of strategies:
you can have invisible subform variables
you can use duplicate object to populate a subform with specific objects
you can use the parent form object as the data object
#3 is especially useful in v16 since the subform object can be a c-object.
In your specific case I bet you already have a form boolean var called
'enabled'. You know it doesn't have to be visible and it doesn't have to be
big - you can set it's coords to 0 width and 0 height.
Gr,
>
Hope this gives you some ideas.
--
Kirk Brooks
San Francisco, CA
=======================
*The only thing necessary for the triumph of evil is for good men to do
nothing.*
*- Edmund Burke*
**********************************************************************
4D Internet Users Group (4D iNUG)
FAQ: http://lists.4d.com/faqnug.html
Archive: http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub: mailto:4d_tech-unsubscr...@lists.4d.com
**********************************************************************
