- Status Waiting feedback
- Percent Complete
- Task Type Feature Request
- Category Application
- Assigned To No-one
- Operating System All
- Severity Low
- Priority Very Low
- Reported Version Development
- Due in Version Undecided
-
Due Date
Undecided
- Votes
- Private
FS#147 - TAGroup: A suggestion
Koda works well at grouping if the user creates a group and then adds radio buttons to it: he decides in advance what area of the form will be needed for the radios, and then adds the radios. For example, he creates Group1 and then creates Radio1 and Radio2 within it.
But two scenarios:
- 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.
- The user creates Checkbox1 and CheckBox2. He then surrounds them with Group2. The checkboxes are not made part of Group2. They should be.
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.
Why not? If you insert Radio3 in group - it will be in group. This behaviour was from the beginning.
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.
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.
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):
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.
x2.jpg (641.6 KiB)
x1.kxf (3 KiB)
x2.kxf (3 KiB)
x2.au3 (0.5 KiB)
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
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?
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:
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:
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.