John,
Spencer's suggestion isn't bad and would allow you to use SET SUBFORM
OBJECT within a method executed using EMIS called by the parent.
The only other way I've been able to accomplish what you want to do is with
nested EMIS calls:
{Parent Form} EXECUTE METHOD IN SUBFORM
("Subform_1";"EMIS_1";*;"EMIS_2";"Update_form_tab";"param
2")
{Subform_1} executes EMIS_1 which is: EXECUTE METHOD IN
SUBFORM("SubSubForm";$1;*;$2;$3)
{SubSubForm} executes EMIS_2 which gets $1= "Update_form_tab" and $2="param
2"
It works. And it's ugly. In such a case having a really solid naming
convention is going to be crucial. Because a subform only exists in the
context of the parent form nesting them makes for a twisty winding path to
"push" commands onto them from any place besides the parent form. This
makes me think about the reverse - typically a subform can simply access
anything on the parent - but I wonder about accessing objects on the
grand-parent?
I would encourage taking a step back and look at the whole task, or set of
tasks, you're trying to accomplish and seeing if nested subforms is really
the best solution. If you decide it really is the way to go then perhaps a
strategy where you store all the data the subforms will interact with in a
single process object is what you need. An object is great for this because
it's extensible and flexible. The code for each subform expects that object
(creates it if it's not already there) and so acts like an input form for a
subset of the process object. Think of the subform as a way to display
what's in the process object, that is - the real data - instead of the
subform *being* the data. From this point of view the subform's nested
level doesn't really matter and actually becomes independent of the parent
form.
This doesn't directly solve the problem you have at the moment but you
could use SET TIMER in the subform (according to the docs SET TIMER is
scoped to the subform) so you could look at some list in the process object
and configure itself if the list in the object doesn't match the list on
the subform. Code on the subform would respond to changes in this list and
update the process object. Boom - you've got a way to update a nested
subform based on something set by the grand parent form. No idea what kind
of performance issues you might encounter if you went wild with various SET
TIMER intervals on multiple subforms though. The key here, I think, would
be designing things so whatever is looking for the data
displayed/edited/set by the subforms resides in the process object and
everything that accesses that data only looks for it in the process object.
On Sun, Dec 24, 2017 at 8:37 AM, truegold via 4D_Tech <[email protected]>
wrote:
> But I discovered I need one of the subform pages, let’s call it “Edits”,
> to change, based upon a different context, to either a different page or a
> different subform using code. The key here is that some action in the
> parent form needs to cause the subform container to display a different
> form.
>
> Seems easy… But I haven’t been able to get it to work.
>
> Parent Form (Tab control)
> -> Subform container
> -> actual subform
>
> Logically it seems that I need to programmatically set the correct tab and
> tell the subform container to change the subform displayed. And then, of
> course, have the subform appear in the subform container.
--
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:[email protected]
**********************************************************************
