renaming a group

[dunbarx]

Richard, Jacque, Hermann, et al.

I will check through the earlier threads on this one. I do not recall how we left it, beyond the user note in the dictionary I posted.

I think it is rightfully a bug, in that it can engender the sort of anguish we just saw with poor Jalz. I would think the Scots would consider this an important issue. I will post the report if I do not see it already there.

Craig

[dunbarx]

There is already a report, sort of, (#8275) still pending. I tried to affirm this with a new one, but was thwarted because I did not fill in the "OS Desktop" field. Not sure what that is. There was no such field in the form.

What am I doing wrong?

Craig

[bn]

setting the name of the templateGroup does not cure it all.

the recipe:
Use one of the old scripts and set the name of the group that groups the groups to "grp_card1"
There will be a "supergropup" "grp_card1"
Now manually ungroup "grp_card1"

If you check the name of the templateGroup from the message box it will be "group id 0"

now set the name of the templateGroup to lets say "mioGroupo" in Jalz's script and group

The name of the "SuperGroup" will be "grp_card1" and not "mioGroupo"

So what I learn from this is that group "grp_card1" although ungrouped and empty is still hanging around and used to group the groups.

It does not use the name you give the templateGroup.

Go figure.

I know Jaque sometime uses empty groups to store custom properties. But I did not know that apparently an empty group is used for the next group command.

Oh when testing from the message box for the groupNames of card 1 after ungrouping manually "grp_card1" is not among the names.

This is all a bit confusing to me, maybe someone can shed some light on this.

Kind regards

Bernd

Kind regards
Bernd

[Simon]

Hi Craig,
Keep your screen wide.
When you answer question 4 it pops up two more fields.

I think that's what you are talking about?

Simon

[bn]

a simplified recipe is

make a new stack with on button

set the name to the templateGroup to any name

manually group the button

the name of the button will be the one you gave to the templateGroup

now ungroup the button

set the name of the templateGroup to another name

now regroup the button manually

The name of the new group will be the former name and not the last name of the templateGroup

Kind regards
Bernd

[Simon]

Hi Bernd,
Yes, that is item 2 of bug report #8275.
MW wrote

Issue (2) - that of remembering group names is an intended way of how the 'meta' tools currently work (e.g. group/ungroup) - as far as I can see it is so that if you ungroup a group you can then immediately regroup it without losing any properties you may have set on that group. This is largely (I think) to help editing UIs (in particular, I suspect the MetaCard IDE or some old version of it).

I don't think this is a bug, merely a perhaps (somewhat legacy) behavior that has been around forever. Also, changing it doesn't seem worthwhile as it could be considered useful in some circumstances.

In this case it is of no help.

Simon

[dunbarx]

Here is something I have never understood about groups. I have used this to my advantage, but it requires remembering, or trouble will result. It is an adjunct to what Bernd wrote.

1- Pull a button onto a card.
2- Set the name of the templateGroup to "X1"
3- Group the button. It will be named "X1" (Well, of course)
4- ask LC for the number of groups. You will get "1". (Well, of course)
5- set the name of the templateGroup to "X2".
6- ungroup that button. Ask for the number of groups. You will get "0". (Well, of course??)
7- group that button again. The name of the group will be "X1" (Hmmm)
8- Pull another button. Group it. The name of that new group will be "X2". (Well, of course)

So if there are no groups around when the first group is undone in step 6, and we regroup it again (7), where in LC is the original reference stored? Now I seem to remember that ungrouping does not destroy the group, but rather just decouples it from the controls it once embraced. Well and good, but then I have a hard time understanding why there are zero groups in step 6, and how that ghost is linked to the control that it once was married to. So a group does not exist if it contains no controls, but it does not, er, not exist either. And it just can't wait to rejoin its old buddy.

Craig

[[-hh]]

..........

[FourthWorld]

FWIW, there is a request in the bug DB to have "it" return the long ID of a group created with the "group" command as it does when creating any object with the "new" command:
http://quality.runrev.com/show_bug.cgi?id=9408

I had tried to submit an additional comment there with a link to this forum thread to help illustrate the scope of the issue, but alas I ran into an odd never-before-seen issue with the bug DB itself; the team has been notified of the bug DB bug, and I'll post my new comment once that's resolved.

All that said, I find the discussion interesting because I've not had much of an issue addressing groups myself. This isn't to say it wouldn't be nice to have some consistency with "it"; after all, I did submit a request for that. But it suggests that while it's possible to find cases where this is problematic, we can also find many solutions for real-world scenarios.

In addition to Simon's suggestion of naming the templateGroup, we can note that in Jalz's layout the result of the group command creates a group which is the outer-most group on the card, the first group, so this can work as well:

Code: Select all

on mouseUp
   repeat with i = 1 to the number of groups
      set the selected of grp i to true
   end repeat
   group
   set the name of the group 1 to "grp_card1"
   set the vScrollbar of group "grp_card1" to true
end mouseUp

It may be that one of the reasons I rarely run into issues with the group command is that I rarely use it at runtime. In Jalz's layout, for example, if the desired outcome is to have a group that contains any number of sub-groups, the outer group could be created in advance, with the inner groups - all being pretty much identical - created with the "copy...to" command, using an offscreen copy of those inner groups as a sort of template object.

That sort of arrangement takes more time to set up, but provides a lot of flexibility by isolating the appearance of subgroups that can be added and deleted easily at any time. It's like having a very modest, simple DataGrid, but one in which you have total control over how it works and, with only the features you need, is easier to work with once you have it up and running.

You could even take it a step further by making the scrollbar appear only when needed:

Code: Select all

set the vscrollbar of grp "grp_card1" to (the height of grp "grp_card1" < the formattedHeight of grp "grp_card1")

Many ways to skin this cat....