Determining the coordinates of a nested ContainerControl

Given a ContainerControl that is embedded in a hierarchy of other embedded ContainerControls and RectControls, the topmost of which is scrollable, how do I programmatically determine the top and left coordinates of that container?

When looking up the “Top” and :Left" properties of a ContainerControl in the LR, the user is taken to the page for the same properties of the Window class. I know that a ContainerControl is KIND OF a window, but I’m having trouble getting what space the coordinates of Rect- and ContainerControls are relative to.

If they’re not absolute to the screen, perhaps they’re in relation to the container’s parent?

[quote=181568:@Peter Truskier]Given a ContainerControl that is embedded in a hierarchy of other embedded ContainerControls and RectControls, the topmost of which is scrollable, how do I programmatically determine the top and left coordinates of that container?

When looking up the “Top” and :Left" properties of a ContainerControl in the LR, the user is taken to the page for the same properties of the Window class. I know that a ContainerControl is KIND OF a window, but I’m having trouble getting what space the coordinates of Rect- and ContainerControls are relative to.[/quote]

A container control instance reports top and left like any regular control. If you have nested it several times, go

[code] dim top as integer = self.top
dim left as integer = self.left
dim w as rectcontrol
w = self.parent
while w <> nil
top = top+w.top
left = left+w.left
w = w.parent
wend

msgbox str(left)+" "+str(top)[/code]

Thank you, Michel. I had tried several variations on this approach before I posted the question, but the values were not correct. I’ll try your precise snippet, and report back…

I tested it on Mac with three successive Container Controls, works fine.

Thank you for taking the time to test this, Michel.

Here is a screenshot of the control in question. (It’s a configurable db search control.) Each criterion “row” is a container control. Any number of these may be embedded within another container control (the white-filled rounded rectangle). One or more of those may be embedded within the parent container control, which is then placed within yet another container.

If I calculate the coordinates of the top criterion row (marked with the red arrow and #1) in the screenshot using your method, or the one I originally had, the value is correct (as shown by the blue arrow). I’m guessing that this is what you tested?

However, as I move down the rows within the group, the calculated value moves down by the spacing between rows. If I calculate the supposed position of the fourth criterion down (the second one with the red arrow and #4), the calculated top is shown by the black arrow. It is off by 3 X the delta between rows.

The same thing is true of the groups further down. The top row is correct, but each succeeding row’s top is vertically displaced.

I can get this to work (with a hack) since I have predictable behavior, but I’d like to understand what stupid thing I’m missing to get this result…

I dont see what is going on. When I place twice the same nested container controls onto a window, I obtain the right value on each. Would it not be a matter of top cumulating somehow ?

Well, yes, but I can’t figure out what’s the “matter” :stuck_out_tongue:

The problem is with a container nested multiple times within a container that is nested multiple times within another container, right? Both your code and my original code seem like they should work, but somehow not - at least for me…

[quote=181773:@Peter Truskier]Well, yes, but I can’t figure out what’s the “matter” :stuck_out_tongue:

The problem is with a container nested multiple times within a container that is nested multiple times within another container, right? Both your code and my original code seem like they should work, but somehow not - at least for me…[/quote]

All I can suggest is to place a system.debuglog str(w.top) in the loop and see what is going on.

Well, I tried that before I posted this, but was unable to determine what was going on. I’ll keep trying.

In the meantime (and to hijack my own thread), I have another issue. The multiply-nested comboboxes which can be seen in the screenshot above are not behaving correctly in the Windows build, yet they do on the Mac. The problem is that they do not respond to mouse clicks if their “AutoComplete” attribute is turned on (either in the IDE or programmatically), but they do if it is off.

For testing, I’ve put a MouseDown event handler in one of them, and the event IS raised, so it is getting the mouse click. Even if I return false from that handler the list does not appear. If I tab into the combobox, however, it does work as expected.

Has anyone else seen this sort of behavior with nested comboboxes under Windows (Windows 7 and Xojo 2015r2, BTW)?

The inspector in the IDE is containers in containers in containers (and sometimes a few more inside those)
Things work as long as you remember to accumulate all the top & lefts and account for whatever spacing you have between rows

The curious thing is row 4 has 3 gaps preceding it and you say the calculation is 3x too large
Does row 3 have a gap that is 2x too large ?
If so I’d suggest its the calculation including gaps thats amiss

[quote=181824:@Norman Palardy]The inspector in the IDE is containers in containers in containers (and sometimes a few more inside those)
Things work as long as you remember to accumulate all the top & lefts and account for whatever spacing you have between rows

The curious thing is row 4 has 3 gaps preceding it and you say the calculation is 3x too large
Does row 3 have a gap that is 2x too large ?
If so I’d suggest its the calculation including gaps thats amiss[/quote]

Yes; row 3’s gap is 2X too large, and I think you’re right about the calculation being off; I just can;t figure out where I’m going of the rails :stuck_out_tongue:

Do you have any idea about the other issue - i.e., the fact that the nested comboboxes don’t respond to a mouse click by displaying the list, or even appearing to have focus, for that matter, even though the mouseDown event does get raised when I click in one?

Cant say I do as we use those for the font inspector & have no issue with that that I am aware of

Are those nested in containers?

Everything in the inspector is containers in containers - at least 2 levels if not more - deep

Hmmm. I wonder, then, what’s different. My nesting is within canvases that are contained in the container control next up the chain. I’m puzzled by the following:

  1. Works on Mac and not on Windows

  2. A MouseDown event handler on the combobox DOES get raised, but the combobox doesn’t get the focus or react to the mouse click.

  3. The combobox DOES react as expect if the user tabs into it, as opposed to clicking on it with the mouse.

Anybody have an idea what to check next?

Oh, and one more thing:

  1. If I turn OFF AutoComplete on the combobox, it works!

BTW, Norman, I just checked the Font Inspector in the IDE, and it doesn’t appear to have AutoComplete turned on. If that’s the case, then I, too, can get it to work with AutoComplete off…

Ahah ! That is the missing detail ! I tested my code on Mac. Let’s see if I can check that on Windows.

Nope. Same result. No difference on Windows.

Then, although this won’t help you understand what triggers the wrong result, I would suggest you simply turn that off before getting the values, and reinstate it afterward if needed. At least, you will have solved the current issue.

This seemingly does;t work. If I turn it on programmatically after it’s been opened, it behaves as though autocomplete is off.

My next step is to try and pare this down to a simple project I can test and submit if it still fails.

Thanks again for the time you’ve taken on this, Michel…