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 **********************************************************************