>>Which is better? Yes and no. It's sometimes good that you can't reference upstairs, or you can get into a habit of writing fugly code like xx=this.parent.parent.parent.pgf.page4.cnt2.DoSomething(), which I've seen a lot in visual classes. That can break in a dozen interesting ways.
>
>Such multilevel dependencies certainly are neither safe nor smell well, but sometimes crop up ;-)
>My way of "dressing up the warts" is to have either an .oLink subobject or oLink_XXX properties, which are used in code instead of
>this.parent.parent.parent.pgf.page4.cnt2
>and can be set and cleared at certain well defined times and locations

I have recently had to add a few extra options to a moderately complicated form, namely one of its containers, which has several subcontainers and controls which become visible when needed. Each of them had in its .refresh() something like this.visible=iif(inlist(crs1.fld1, 1, 2, 6, 12) or iif(crs1.fld2, .t., iif(inlist(crs2.fld5, "a", "c", "f"))), with varying conditions and some repetition here and there. That was written ages ago and only got more complicated as options were added. Luckily, all of these controls now have a .visible_expr which gets evaluated in .refresh() at the class level, so I put all those in one method I called .calcVisible() in the form, and assign these expressions (actually it turned out there were only about five of them) to new properties of the form, and then put "thisform.lHasPockets", "thisform.lHasBags", "thisform.lHasZipper" etc into ,visible_expr of each. Only took care to call thisform.calcVisible() from the .valid() of each control which can change any of the conditions. This has removed oodles of code.

And only then I was able to add two more options. The visibility of required controls was easy to set.