But what if he later realizes that he needs a third radio in this group? When he enlarges the Group area and adds Radio 3, Radio3 is not placed in Group1. It should be.

Why not? If you insert Radio3 in group - it will be in group. This behaviour was from the beginning.

I suggest that code be added to Koda: when a group is created, include in it all controls which are within the area of the group.

I don't think it's good idea. First of all it's just plain hard to implement. And how handle it when you have group in group?

Now you can select multiple controls, cut them and paste into group. Simple and clear.

If you insert Radio3 in group

I now understand what you mean: insert Radio3 when Group1 is focused.

I have found that if Radio 3 is created when the focus is on the form, you can then drag it to the group.

I haven't found anything on this in the help. Perhaps it should be there.

you can then drag it to the group

Correction: cut it, click on Group1, paste it

With the above procedure, while a Radio shows as moved to the Group in the Object Treeview, the Radio doesn't land up back exactly where it was. It is off by about the Top and Left of the Group control. Looks like a bug to me.

With the above procedure, while a Radio shows as moved to the Group in the Object Treeview, the Radio doesn't land up back exactly where it was. It is off by about the Top and Left of the Group control. Looks like a bug to me.

Positions of each control in Koda are relative to it's parent, not a form. And those positions are retains when control is copying/pasting. So, this is definitely "by design".

Please take a look at the attachments. 1.* is with the label created with the form in focus. 2.* is after cutting the label in Object Treeview, focusing on the group, and pasting.

As a user, I ask: where did the label go? Koda doesn't seem friendly to the user OR Koda seems to be buggy.

Looking at the .kxf files, I see for (left,top):

• Group: (224,40)

• Label: (304,72)

To me, when the label is inserted into the group, its (top,left) should be (80,32)

It is true that the generated AutoIt code gives you what you see, i.e. the label code is generated, but you can't see the label!

When a control is cut, its (left,top) should be changed to relative to the form. When it is pasted, its (left,top) should be changed to relative to the group.

To me good design would be that the user never needs to touch the generated code. It would be wonderful if users always thought systematically when adding controls. e.g. when a user wants to add three radio buttons to a group, he focuses on the Group, then adds them. But if he forgets to click on the group before adding them (or clicks on the wrong group), he will swear and curse at Koda for making him delete the three of them and create them again, rather than cutting and pasting them.

AutoRadios are a particular problem. To me, Koda should be smart enough to realize that a control created within a group's rectangle belong to the rectangle.

My Koda to PerfectScript converter is able to include these three controls in the group, so a group of radios includes those that are within the area but not, per Koda, in the group, and I can write one for .au3 files, but I shouldn't need to.

I cannot think of any situation where a control that is within a group's bounds does not logically and functionally belong to the group. To create such a situation would be bad GUI design.

I am trying to help. I am sorry if I seem to be (and probably am) questioning your design. I think Koda is great, and I am sure it has taken a huge amount of effort to bring it to this point. I just think that it could be slightly better.

   x1.jpg (643.8 KiB)
   x2.jpg (641.6 KiB)
   x1.kxf (3 KiB)
   x2.kxf (3 KiB)
   x2.au3 (0.5 KiB)

As a user, I ask: where did the label go? Koda doesn't seem friendly to the user OR Koda seems to be buggy.

I agree with this statement and this probably good to work out this problem. This is not too convenient when control become hidden somewhere in group. I already think about this. But

To me, when the label is inserted into the group, its (top,left) should be (80,32)

This is can be ok for particular case. But, what if control is not overlap with Group and have coordinates, larger then Group size? What position it should have after pasting?

But if he forgets to click on the group before adding them (or clicks on the wrong group), he will swear and curse at Koda for making him delete the three of them and create them again, rather than cutting and pasting them.

To me, Koda should be smart enough to realize that a control created within a group's rectangle belong to the rectangle.

I think any application required some minimal acquired practice that user should know to correctly work with. In Koda one of this - always select container control before inserting something into it. It's not that hard.

Sorry, but I generally don't like an idea to add in Koda some fuzzy logic to fix user mistakes.

I wouldn't want to see Koda indulge in fuzzy logic. But I would like to see it user-friendly.

I don't think of myself as a dumb user, but I did recently create controls in a group. I later realized that I needed to add more. I forgot to focus on the group, so their parent was the form. I then had to delete and recreate them in the group. I was not happy. Such unhappiness can be avoided, to a degree.

In previous discussion,I have been thinking of the approach you now have: cut and paste. But I think that user errors can be made visually obvious if a drag-and-drop, in the Object View, approach is used.

The drag-and-drop approach:

1. When a user creates a group, the edges are visually constrained from extending outside the group (and form). e.g. A user clicks on Label. He then clicks in GroupA, creating the control. Koda stops him moving it such that it extends beyond GroupA.
2. A user is prevented from resizing a control such that it extends beyond the group it was created in.
3. When a user creates a control (or a group), It belongs to the lowest-level group that it is entirely within. If it extends outside all groups, it belongs to the form.
4. A control is visually constrained from extending outside the form.
5. The user sees what its parent is from the Object Treeview.
6. The user can drag a control (or group) from one group to another (and from the form to a group).
7. If a user tries to drag a control (or group) to a group that is too small for it, Koda shows what the result would look like for 2 seconds, then returns the control (or group) where it was.

I think that this approach will result in fewer user mistakes, will make it obvious when he makes them, and allow him to correct them. To me, the tricky part may be implementing the drag and drop. I hope this is clear to you. What do you think?

No-no-no. Sorry, but in current designer drag'n'drop from/to group - no way. If this would possible - this would already was here. Changing entire designer to support this feature - definitely no way. At least not in Koda 1.x. Seriously, this "problem" is just matter of expirience.

I would prefer work out the paste coordinates - this thing is really have the field to improvement.

I accept that drag-and-drop in Object Treeview will not be seen until much later (if at all).

I was playing with VB5 to see how it handles the group problem. Here is what I saw:

• There is no object treeview, so the only way of re-parenting a control or group is cut and paste.

• If a control is created in a group, you can't move it out of the group. When you move a control such that it is partly out of the group, the part out of the group disappears. You cannot move a control any further out of its group about 40% of the control's width and/or height.

• Similarly, for a control created with the form as its parent, you can't move it into a group further than 40%.

• I seem to remember that VB will not save a form that has a control that is partly out of its group.

• If you cut a control from a group and paste it into another group, if it won't fit in the same relative position in the new group as in the old one, it is pasted at the top left of the group, i.e. its top,left is forced to 0,0 relative.

Perhaps this helps.

I will likely make pasted controls with position that out of group bounds appear as close to their coordinates as possible, while keep they visible.