Control parent bug when changing container indices

General
1

I think that I’ve narrowed down an IDE bug that has been plaguing me for years and can lead to total corruption of a complex window layout. FYI, by “container” I don’t mean the actual container control, I mean the control which “contains” (is the parent) of a set of child controls. Here is the story:

I have a preferences window containing a toolbar and page panel control. On this page panel I have a canvas for each “page”, and on the canvases are the various controls. The individual page canvases are part of a control set (cvsSettings). Each canvas is a different height, and I use the height value to smoothly change the window size to perfectly match the items being displayed (like the Safari preferences dialog). Recently I needed to change the order of pages on the page panel, and the IDE provides a nice little mechanism for doing this, but the problem arose when I tried to change the indices of the canvases to keep them in numerical order (in my case 0 through 6). Ignoring the pain of having to renumber items multiple times because indices can’t be reused (i.e. from 3 to 7, then 4 to 3, 5 to 4, 6 to 5 and finally 7 to 6) once the index of an item in a control array is changed, it seems to forget which controls are it’s “children” and all controls end up getting assigned to the underlying control (in my case a background canvas).

Everything appears to be fine in the IDE. Switching pages of the page panel using the little arrows looks perfectly fine and gives no indication that the control parent/child relationship has been corrupted, but running the application produces a window with controls drawn one over top of the other. Since there is no way (like right clicking on a control in the old IDE) to determine what a control’s “parent” truly is, I don’t see how this is even possible to fix, or even notice, while in the IDE.

Luckily I use version control and was able to get back to the uncorrupted layout, but I still have no way of re-indexing the canvases.

I’m going to file a bug report, and curse a lot under my breath. Has anyone else been plagued with this bug?

2

I just experimented with controls placed on a control set. Actually, two canvases in Canvas1(), and on each, a button containing

msgbox me.Parent.Name+" "+str(me.parent.Index)

The MsgBox displays Canvas1, and the index.

If I change the index, I get a nil exception, since the button has a nil parent. The same occurs if I change the name of the member.

When the canvas is not in a control set, if I change its name, the parent property is updated for the controls it contains.

So it does look like it is a bug. You want to report it, but make sure to submit a project that demonstrates it.

The workaround I found was to move the controls away, then move them back in making sure the red shows around the canvas to reset the parent.

3

Thanks for the corroboration Michel. I’ll put a sample project together tonight and file the report.

I agree that moving controls off and then back onto the canvas will re-establish the parent relationship, but my pages often contain dozens of items which require pixel perfect placement and it’s often impossible to even select everything reliably.

4

What I do in this instance is hightlight the control and in the Inspector, add 2000 to the Left property, Then subtract it back out to put the control exactly where it was before. (You can do that by appending “+2000” to the value in the property. The IDE will do the math for you.)

5

[quote=143262:@William Koperwhats]Thanks for the corroboration Michel. I’ll put a sample project together tonight and file the report.

I agree that moving controls off and then back onto the canvas will re-establish the parent relationship, but my pages often contain dozens of items which require pixel perfect placement and it’s often impossible to even select everything reliably.[/quote]

You may want to abstain reindexing your canvases members, then, until the bug is fixed. Even if you can change the controls parent in code, that seems even more cumbersome than the move out and in.

6

Tim, I agree with you, but here’s the odd thing with doing that…

The parent/child relationship of a control will get updated when physically dragging them around in the IDE, and they’ll also get updated (correctly?) when selecting one and moving it with the arrow keys (i.e. if you select a control and repeatedly hit the “left” key until it moves off of it’s parent, the red “highlighting” will change to show it’s new parent (this is fairly new behavior in the IDE and I actually would prefer if it did not do this). But if you simply change the location by updating the left/top values in the inspector, the parent/child relationship is retained (so this actually wouldn’t solve my initial problem).

For now I’m leaving the indexing alone (which wreaks absolute havoc with my OCD) and have an array of window heights that I check against. sobs

7

I can’t find a bug report BUT created one as the detailed explanation you gave made the problem apparent

<https://xojo.com/issue/36689>

15 lines of code - done
Check it in the next beta’s

9

Thanks Norman. Got busy and didn’t get around to putting a bug report together. Saves me the effort :slight_smile:

10

[quote=143290:@Norman Palardy]I can’t find a bug report BUT created one as the detailed explanation you gave made the problem apparent

<https://xojo.com/issue/36689>

15 lines of code - done
Check it in the next beta’s[/quote]

AND IT TOOK ONLY 18 MINUTES… unbelievable!! And that includes the fix!!

11

The power of a VERY nice repeatable set of steps and Norm deciding his wrists hurt to damn much to work another few hours - so I was perusing the forums saw this & it intrigued me

Once I had the steps the fix was patently obvious