nested grps and controls: how to get what you expect to get?

[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
?

[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

[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.

[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

[rmuzzini]

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

Code: Select all

hide fld "p"

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.

[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.

[Klaus]

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.

[dunbarx]

Jacque, Klaus.

Lower, higher, let's call the whole thing off.

Craig

[Klaus]

Jacque, Klaus.

Lower, higher, let's call the whole thing off.

Craig

Sheeesh...

OK: OFF!

[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

[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 10541 times

[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.

[rmuzzini]

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.

[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?

[rmuzzini]

- 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