Re: Subform initialize logic
Piotr,
On Fri, Nov 24, 2017 at 2:59 AM, Piotr Chabot Stadhouders via 4D_Tech <
4d_tech@lists.4d.com> wrote:
> As an example I have the following scenario:
> An employee form with a lot of fields and a checkbox “manager” on page 1
> Other fields on page 2
> The items of some “dropdown lists” (custom widget) on page 2 depend on the
> manager status (checkbox) on page 1
>
> So when going through the records with next/previous buttons and being on
> page 2 I have to re-populate the dropdown widgets when the manager status
> changes
> But now, when being on page 1 and going to page 2 for the first time I
> also have to populate the dropdown widget.
>
Good example. The way I'd approach this is in the On load event of the
parent form:
EXECUTE METHOD IN
SUBFORM("dropdown_widget";"config_employee_widget";*;$isManager)
'config_employee_widget' would also set the display value. The only action
the subform needs to deal with is the On data change event. You know you
could just set the drop down display value at this point and populate the
actual list when/if the user clicks on it.
I'd run that same code in response to the checkbox changing as well.
So now I have 2 places where I have to populate (by method or not) the
> dropdown widget
>
Personally I don't use drop downs for this sort of selection very often.
Totally an aesthetic thing for me but I prefer to either use a button or a
form var and a button.
For the button alone I set the button title to the selected value when the
parent form loads. On Click I build and display a menu of options, store
the user choice and update the button title.
The other interface is a non-enterable var to display the value and some
small graphic, like a hamburger button
RE: Subform initialize logic
Kirk, As an example I have the following scenario: An employee form with a lot of fields and a checkbox “manager” on page 1 Other fields on page 2 The items of some “dropdown lists” (custom widget) on page 2 depend on the manager status (checkbox) on page 1 So when going through the records with next/previous buttons and being on page 2 I have to re-populate the dropdown widgets when the manager status changes But now, when being on page 1 and going to page 2 for the first time I also have to populate the dropdown widget. So now I have 2 places where I have to populate (by method or not) the dropdown widget I hope you understand what I am saying Needing 2 calls instead of 1 is what I don’t like Gr, Piotr Piotr, On Thu, Nov 23, 2017 at 11:01 AM, Piotr Chabot Stadhouders via 4D_Tech < 4d_t...@xxx.xxx> wrote: > I have to do this “On Page Change” > Yep, this is exactly the sort of situation that makes having the subform config code in a process method useful - the subform doesn't need to even know what page it's on because the parent form is controlling when it configures itself. Is it the case your subform on page 2 changes configuration while the parent form is displayed? -- 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...@xxx.xxx ** ** 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 **
Re: Subform initialize logic
Piotr, On Thu, Nov 23, 2017 at 11:01 AM, Piotr Chabot Stadhouders via 4D_Tech < 4d_tech@lists.4d.com> wrote: > I have to do this “On Page Change” > Yep, this is exactly the sort of situation that makes having the subform config code in a process method useful - the subform doesn't need to even know what page it's on because the parent form is controlling when it configures itself. Is it the case your subform on page 2 changes configuration while the parent form is displayed? -- 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 **
RE: Subform initialize logic
Hi Kirk,
Thanks for your comprehensive explanation.
I think I am on the right track.
A lot of things you are saying I am already doing, based on some example
components
My widget is a “custom dropdown list” widget
I am converting system dropdown lists to this widget
The system dropdowns are populated by arrays in the form on load event
However, in the process of converting, I have to remember that populating the
custom ones on load has no effect when the widget is not on page 0 or 1
I have to do this “On Page Change”
Gr,
Piotr
Piotr,
On Thu, Nov 23, 2017 at 5:14 AM, Piotr Chabot Stadhouders via 4D_Tech <
4d_t...@xxx.xxx> 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
===
**
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
**
Re: Subform initialize logic
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
**
