Page 1 of 2
nested grps and controls: how to get what you expect to get?
Posted: Mon Apr 10, 2017 4:09 pm
by rmuzzini
hi all.
have a grp, named "theParent"
inside:
- 1 fld, named "p"
- and another grp, named "theChild", which owns a fld named "p" (same name as the parent's one)
run the following:
Code: Select all
on scriptAttachedToParent
hide fld "p" of me
on scriptAttachedToParent
now, 2 chances:
- if the fld "p" of "theParent" has a layer number lower than the grp "theChild", it happens what expected:
visible of fld "p" of grp "theParent" is set the false
- if the fld "p" of "theParent" has a layer number higher than the grp "theChild", it happens what we (well, i, at least) do not expect:
visible of fld "p" of grp "theChild" is set the false.
conclusion: when searching for a control in a grp, the first one whose name matches the seeked is choosen, even if - strictly speaking - it is not owned by the grp itself, actually.
it seems a bug, to me. otherways (assuming this is not a bug but a… well… hidden feature…), does anyone can suggest me a workaround for this, i.e. is there any LC function to do sort of
get -the effective- fld "p" of me
?
Re: nested grps and controls: how to get what you expect to
Posted: Mon Apr 10, 2017 4:47 pm
by jmburnod
Hi,
I get same results.
How do you run your script ? Who is me ?
If you send your message by messages box, me = stack
Best regards
Jean-Marc
Re: nested grps and controls: how to get what you expect to
Posted: Mon Apr 10, 2017 5:26 pm
by rmuzzini
hi, Jean-Marc.
"scriptAttachedToParent" is a script in the grp "theParent"
invoke it from anywhere. doesn't matter. just a
Code: Select all
send "scriptAttachedToParent" to grp "theParent"
another funny test: in grp "theParent" add a button.
script of the button:
Code: Select all
on mouseUp
answer the id of the owner of me & cr & the id of the owner of fld "p" of the owner of me
end mouseUp
see the result in both cases.
case A (fld "p" before grp "theChild") you get something like
1006
1006
case B (fld "p" after grp "theChild") you get something like
1007
1009
funny. isn't it?
tested on LC 7.1.4 and LC 8.1.2
regards.
Re: nested grps and controls: how to get what you expect to
Posted: Mon Apr 10, 2017 9:29 pm
by dunbarx
I am not sure this is unexpected behavior.
Setting aside the fact that you have two fields with the same names, always risky, what happens if you "hide fld "p" of grp "child"? This explicit reference works as advertised, regardless of layer number, and is the least you could do for the engine with those identically named fields.
Craig Newman
Re: nested grps and controls: how to get what you expect to
Posted: Tue Apr 11, 2017 9:29 am
by rmuzzini
dunbarx wrote:I am not sure this is unexpected behavior.
Setting aside the fact that you have two fields with the same names, always risky, what happens if you "hide fld "p" of grp "child"? This explicit reference works as advertised, regardless of layer number, and is the least you could do for the engine with those identically named fields.
Craig Newman
hi, Craig.
yes, i could agree with you if i was using a generic
but in the case above described i'm referring specifically to the fld owned by a specific grp. what i mean is: any control should have a property like pParent returning the real parent grp. or this is what i think, otherways the property "owner" is not exactly what one expect to be(*).
in my opinion, this piece of code
Code: Select all
answer the id of the owner of me & cr & the id of the owner of fld "p" of the owner of me
is enough clear about the unreliability of that property. try it. it seems LC mixes two "owners".
there are many ways to resolve this "issue" (in quotes, to not hurt anyone :->). that's not the point.
about me, now i know that, in the future, while making a grp dinamically i'll remember to set for each control a custom property as decribed above (btw, this what i was hoping someone would have been replied: "you silly, use the XXX property, instead!").
in my case, currently i'm developping an app where there are parents grps owning child(s) owning child(s) owning child(s) and so on. each child is a clone of a model, added by user (it's a "decision making" app). each grp has fields with numbers to be calculated. the process is reiterative. since yesterday (after a small change during debug which moved a fld after a child grp) i know it's better to not run the following:
in child grps:
Code: Select all
on doCheckMe
return (fld "p" of me)*(fld "v" of me)
end doCheckMe
on btn "calculate" in child grp
Code: Select all
on doCheckMyGrp
return (fld "p" of the owner of me)*(fld "v" of the owner of me)
end doCheckMyGrp
on fld "v"
Code: Select all
on keyUp
return (fld "p" of the owner of me)*(me)
end keyUp
cause of this "expected behavior". note: of course all of the above works rightly IF the object is BEFORE another child inside the grp.
just curiosity: why, in your opinion, that should be an "expected behavior"?
the dictionary says:
"Use the owner property to find out which object another object belongs to in the object hierarchy."
the glossary also says:
"owner: The object that contains another object;[…]a grouped control is owned by its group"
and
"synonym: parent" (which actually does not work)
(*)so probably that's not a bug but a feature request, instead…? or half a bug…
regards.
Re: nested grps and controls: how to get what you expect to
Posted: Tue Apr 11, 2017 5:13 pm
by jacque
It's not a bug, it's just how LC works. When looking for a control by name, it starts at the highest layer and searches downward, stopping at the first control it finds with that name. That's why duplicate names can give unexpected results.
To be sure the engine finds the correct control it needs a full reference: fld y of grp x of grp y of grp z
Alternately use IDs, which are always unique.
Re: nested grps and controls: how to get what you expect to
Posted: Tue Apr 11, 2017 6:07 pm
by Klaus
jacque wrote:When looking for a control by name, it starts at the highest layer and searches downward...
It is actually the other way round, LC starts with the LOWEST layer up to the highest.
Re: nested grps and controls: how to get what you expect to
Posted: Tue Apr 11, 2017 6:12 pm
by dunbarx
Jacque, Klaus.
Lower, higher, let's call the whole thing off.
Craig
Re: nested grps and controls: how to get what you expect to
Posted: Tue Apr 11, 2017 7:03 pm
by Klaus
dunbarx wrote:Jacque, Klaus.
Lower, higher, let's call the whole thing off.
Craig
Sheeesh...
OK:
OFF!
Re: nested grps and controls: how to get what you expect to
Posted: Tue Apr 11, 2017 8:22 pm
by dunbarx
Klaus.
I am with you, the opposite of Jacque. I started with the idea that the lowest layer in the hierarchy contains controls, and the higher layer contains the engine. Jacque went to the dark side decades ago, believing that messages "fell" through and downward to the engine.
The Hypercard Script Language Guide has the engine at the bottom. Danny Goodman has it at the top. That is where I always liked it.
Craig
Re: nested grps and controls: how to get what you expect to
Posted: Tue Apr 11, 2017 8:35 pm
by Klaus
Of coures I made a test before posting, see screenshot.
The engine start counting from 1 when resolving names.
- Bildschirmfoto 2017-04-11 um 21.34.17.jpg (30.68 KiB) Viewed 10544 times
Re: nested grps and controls: how to get what you expect to
Posted: Tue Apr 11, 2017 9:33 pm
by jacque
One long-time user called it "sky worshippers" and "earth worshippers" or something like that. But I did use the word "layer" so I was technically wrong and Klaus is correct.
Re: nested grps and controls: how to get what you expect to
Posted: Wed Apr 12, 2017 9:05 am
by rmuzzini
jacque wrote:It's not a bug, it's just how LC works. When looking for a control by name, it starts at the highest layer and searches downward, stopping at the first control it finds with that name. That's why duplicate names can give unexpected results.
To be sure the engine finds the correct control it needs a full reference: fld y of grp x of grp y of grp z
Alternately use IDs, which are always unique.
hi, jacque.
half a bug…
again: i know there are alternative methods to get the expected result. as usual. that's the funniest part of software development.
i was trying to focus on the meaning of property "owner". which is not what described. currently, you run the risk to choose the first altrernative which seems to be the correct way, following the language dictionary. why seek for other ways? but it's the wrong one.
expert developers have skills and memories of this kind of "bug" (in quote… :->) to avoid this kind of risk.
but what about LC beginners? what weapons do they have to understand the way "LC works"?
am i wrong?
regards.
Re: nested grps and controls: how to get what you expect to
Posted: Wed Apr 12, 2017 7:11 pm
by jacque
- if the fld "p" of "theParent" has a layer number lower than the grp "theChild", it happens what expected:
visible of fld "p" of grp "theParent" is set the false
- if the fld "p" of "theParent" has a layer number higher than the grp "theChild", it happens what we (well, i, at least) do not expect:
visible of fld "p" of grp "theChild" is set the false.
I may not understand your layout. How can a parent group have a layer number higher than its child?
Re: nested grps and controls: how to get what you expect to
Posted: Thu Apr 13, 2017 4:53 pm
by rmuzzini
jacque wrote:- if the fld "p" of "theParent" has a layer number lower than the grp "theChild", it happens what expected:
visible of fld "p" of grp "theParent" is set the false
- if the fld "p" of "theParent" has a layer number higher than the grp "theChild", it happens what we (well, i, at least) do not expect:
visible of fld "p" of grp "theChild" is set the false.
I may not understand your layout. How can a parent group have a layer number higher than its child?
hi, jacque.
not the parent group. its fld "p".
the fld "p" of "theParent"
regards