Re: Why do group ID's change when cloning a stack
No, it's sketchy because certain operations like cloning or copying cards can change ID's, because ID's must be unique in a Revolution stack. Also one programming method uses hidden objects as templates and then clones them so that there is consistency in the interface. It's easier than p[rogrammatically setting all the properties every time a new object is created. In this case ID's are useless. I just think it's bad programming practice. As a teacher, I am sure you know that part of what you are teaching your students is good programming habits. If they fail at that, they aren't going to be very good programmers anyhow. If their discipline is bad enough, they may even end up like me, and nobody wants that. Bob Sneidar IT Manager Logos Management Calvary Chapel CM Is this a programmer-thing? I ask because I have a devil of a time convincing my students to *name* their objects. They end up having problems and it's VERY frustrating... Judy On Fri, 11 Aug 2006, Robert Sneidar wrote: Since the days of Hypercard, I have known that using ID's to reference objects was sketchy at best. As a matter of good programming practice, you should keep track of all your variables and object names so there is no inadvertent duplication to bite you in the butt later. ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Why do group ID's change when cloning a stack
Robert Sneidar wrote: No, it's sketchy because certain operations like cloning or copying cards can change ID's, because ID's must be unique in a Revolution stack. Also one programming method uses hidden objects as templates and then clones them so that there is consistency in the interface. It's easier than p[rogrammatically setting all the properties every time a new object is created. In this case ID's are useless. Not to mention that they have no mnemonic value; it's just easier to use the name property. IDs are useful for dynamically obtaining absolute references to an object, such as setting properties of a newly created button: create button set the backColor of it to 240,240,240 There are many such examples, but for cases where object references must be hard-wired in a script it's usually simpler to just use the object's name. Going back to the original question, I wonder if the IDs of cloned groups change because it's possible to reference groups in other stacks as the menuBar group. I don't know, just guessing here. Scott Raney would know, but maybe Mark Waddingham may know the origins of this as well and could chime in with his opinion. -- Richard Gaskin Managing Editor, revJournal ___ Rev tips, tutorials and more: http://www.revJournal.com ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Why do group ID's change when cloning a stack
On Aug 14, 2006, at 11:21 AM, Richard Gaskin wrote: Going back to the original question, I wonder if the IDs of cloned groups change because it's possible to reference groups in other stacks as the menuBar group. I don't know, just guessing here. Scott Raney would know, but maybe Mark Waddingham may know the origins of this as well and could chime in with his opinion. Or maybe because some groups are owned by the stack. Dar ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Why do group ID's change when cloning a stack
On Sat, 12 Aug 2006, Claudi Cornaz [EMAIL PROTECTED] wrote: I am also interested WHY this should happen. If you have stack A with 2 grp's and you clone the stack then the id's of the 2 grp's will stay the same but every control in the grp will get a new ID. One interesting part of this is why - I did a quick test - the IDs of the two groups stay the same even when their layer should have been changed. My experience is that each time you change the layer of an object *and clone the stack or *copy * a card within a stack, the IDs (or new IDs) will be re-assigned following the order of the layers, e.g. if you have 4 buttons on a card with consecutive ID s of 1010 to 1013 and you change the layer of button 4 to lowest (of the buttons), then on the next (copied) card the sequence of IDs for these Buttons is 1015 to 1018. On the copied card button 4 now has the lowest ID instead of the highest as on the original card. When needing to copy a card when developing a new variant of a language program I several times ran into that problem. I then took care to rearrange the layers of objects to their original state to be able to reestablish references to objects more easily. And; if you put your two groups into a super-group and change their layers, the IDs of the embedded groups will be both new and in a different order than before. If I clone the same stack A again I now have 2 cloned stacks which are identical that is to say all the ids of all controls in both cloned stacks are exactly the same and both differ from the original. So Why? Best wishes Claudi The cloned stack are identical because you did not change any object layers in between the two acts of cloning. I assume, one reason behind the fact that lower order objects (such inside a group) get new IDs is that the original stack and the cloned stack are *open* at the same time and are somehow treated like two cards inside a stack (one of which is a copy of the first as I described above).- So IMHO the best thing you can do to optimize the creating of cloned stacks or copied cards is to reestablish the original layer order before cloning or copying. Best regards, Wilhelm Sanke http://www.sanke.org/MetaMedia -- ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Why do group ID's change when cloning a stack
On 8/12/06, Dar Scott [EMAIL PROTECTED] wrote: On Aug 11, 2006, at 11:08 PM, Sarah Reichelt wrote: Like Richard, I really like the way Rev allows you to have separate names labels, so that labels can be changed to suit customer preferences, languages or what ever you like, while keeping the name the same so all your scripts still work. I have the memory of a goldfish. By time I get the edit window open, I forgot the names of the controls. So, I like this idea a lot, but for initial development and experimenting, I usually have the name of the control on the card somehow. When I'm typing in the script, I can look over and see the name. Now if I could drag a control onto a script and have the editor insert a reference to that control, then I can have it all. Or maybe have the names float over controls while I'm editing, so I can glance over and see them. You need Galaxy! It shows the name of an object when you hover over it, and inserts the name in a script if you press Control-Escape :-) Sarah ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Why do group ID's change when cloning a stack
Hi all, Well, I do name all my controls, because ofcourse it's a lot clearer to read the code. The thing I am working on now is a frame-border kind of object. I design it in a 3D program slice into the right bits and import the images into runrev where they get assembled. There is provision for different states, like focused, unfocused, dimmed, dragEnter etc. There may also be many different styles and substyles, which ofcourse have theire different states. So actualy the component is a grp of grps which contain grps which contain img's. All these style grp's have basicaly the same setup, with the same names for theire subgrps and subparts. Now I can treat each grp the same way with the same code because the names of their subgroups/parts are all the same. So I only need the id of the enclosing grp to be very specific because id's are unique, whereas in this setup the names are NOT different on PURPOSE. That's the nice thing about unique id's combined with names which needen't be unique. With storing the unique id of the parent grp I can adress very specificly all parts in that grp although there might be tens or hundred of similar grps nested in other grps, which are nested in other grps. One id makes it very precise. Because of the unique id's I only need to store one ID istead of the whole chain of names till I reach a unique part which might be several levels up (img left of grp focused of grp border of grp greenstyle of grp defaultStyles of grp styles of grp fieldFrame. Instead of img left of grp id 1003) Well sure the id's stay unique, but they are not safe because they get changed. This is a real nuissance. What I am doing now is only about 3 levels deep, so it is manageable altough now I need to insert code to check for duplicate names otherwise it might get screwed up completly. (Names might be changed on the fly) I know I will get into situations where the number of levels get way beyond 3 and then it becomes very awkward. Also I believe this should be documented somewhere 'cause it might waste people a lot of time. I am also interested WHY this should happen. If you have stack A with 2 grp's and you clone the stack then the id's of the 2 grp's will stay the same but every control in the grp will get a new ID. If I clone the same stack A again I now have 2 cloned stacks which are identical that is to say all the ids of all controls in both cloned stacks are exactly the same and both differ from the original. So Why? Best wishes Claudi ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Why do group ID's change when cloning a stack
I agree that in most instances using the name of controls is the best way. BUT there is a **semantic** issue with the current behavior of the clone command because we expect a clone to be an exact copy of the original. Also, the problem of changing the ID especially for images is a nasty one. Suppose you have many groups displaying different images in fields where the imagesource reference the id of images, the result of the clone can be not only surprising but also dangerous if IDs are mixed... (for instance imagine a surgery imaging software which after cloning a stack displays another image instead of the orginal one and ... then you - the patient - awake with amputation of the left leg instead of a back pigmented mole ablation). Due to the semantic trouble of the current cloning way I suggest that Claudi who has found this disturbing behavior fills a bug. ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Why do group ID's change when cloning a stack
Since the days of Hypercard, I have known that using ID's to reference objects was sketchy at best. As a matter of good programming practice, you should keep track of all your variables and object names so there is no inadvertent duplication to bite you in the butt later. If nothing else, use variable and object names that specifically describe the actual object. That was, as we learned at Revconwest 2006, The code practically comments itself. Naming objects are definitely the way to go. (IMHO) Bob Sneidar IT Manager Logos Management Calvary Chapel CM On Aug 11, 2006, at 7:22 AM, [EMAIL PROTECTED] wrote: By accident I just discovered that group ID's change when you clone a stack. This can be very annoying when you work with tmplt stacks which you clone to use as, lets say a document or a viewer. snip Best wishes Claudi ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Why do group ID's change when cloning a stack
But then you get into issues where buttons have graphics referenced by IDs. The only way around this is to reassign the icon IDs at some point. At 01:19 PM 8/11/2006, you wrote: Since the days of Hypercard, I have known that using ID's to reference objects was sketchy at best. As a matter of good programming practice, you should keep track of all your variables and object names so there is no inadvertent duplication to bite you in the butt later. If nothing else, use variable and object names that specifically describe the actual object. That was, as we learned at Revconwest 2006, The code practically comments itself. Naming objects are definitely the way to go. (IMHO) Bob Sneidar IT Manager Logos Management Calvary Chapel CM On Aug 11, 2006, at 7:22 AM, [EMAIL PROTECTED] wrote: By accident I just discovered that group ID's change when you clone a stack. This can be very annoying when you work with tmplt stacks which you clone to use as, lets say a document or a viewer. snip Best wishes Claudi ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution Peter T. Evensen http://www.PetersRoadToHealth.com 314-629-5248 or 888-682-4588 ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Why do group ID's change when cloning a stack
Robert Sneidar wrote: Since the days of Hypercard, I have known that using ID's to reference objects was sketchy at best. As a matter of good programming practice, you should keep track of all your variables and object names so there is no inadvertent duplication to bite you in the butt later. If nothing else, use variable and object names that specifically describe the actual object. That was, as we learned at Revconwest 2006, The code practically comments itself. Naming objects are definitely the way to go. (IMHO) One of the many great things in Rev that HyperCard never dreamed of was having a separation of an object's name from its displayed label. This has totally changed my style of programming, allowing me to use names as mnemonic IDs while still have the label property for display to the user. And anytime I need to change the displayed label it never changes the object's name, so my scripts never need to be revised even with clients who change button labels a lot. :) -- Richard Gaskin Managing Editor, revJournal ___ Rev tips, tutorials and more: http://www.revJournal.com ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Why do group ID's change when cloning a stack
Do those graphics ID's change with a clone or do they remain the same? If they remain the same then for the sake of this discussion the point is moot. The original discussion was about how group ID's change, but other object ID's do not. Bob Sneidar IT Manager Logos Management Calvary Chapel CM On Aug 11, 2006, at 10:00 AM, [EMAIL PROTECTED] wrote: But then you get into issues where buttons have graphics referenced by IDs. The only way around this is to reassign the icon IDs at some point. At 01:19 PM 8/11/2006, you wrote: Since the days of Hypercard, I have known that using ID's to reference objects was sketchy at best. ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Why do group ID's change when cloning a stack
I did some further testing and it turns out like this: All objects (at least the ones I tested and I did most) don't change id when the stack is cloned. That is all controls that are not part of a grp! The id of all outermost grps don't change but the id's of ALL controls in a grp will change, including the id's of nested grp's. So each and every control in a grp get's it's id changed when the stack is cloned, except the id's of the outermost grp's. What would be the reason behind this? Why doesn't the id of the outermost grp's change but each and every control in each grp get's a new ID. What will happen when I clone a stack with hundred of grp's. How much time wil this take if each control in all these grp's need to be reIDed. I can live with the fact, well I will have to, there obviously is no choice, but I sure like to know! Best wishes, Claudi ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Why do group ID's change when cloning a stack
Ooops. I didn't read thoroughly. If the other object IDs don't change, it is moot. It is odd that the only the group ID's would change. At 01:47 PM 8/11/2006, you wrote: Do those graphics ID's change with a clone or do they remain the same? If they remain the same then for the sake of this discussion the point is moot. The original discussion was about how group ID's change, but other object ID's do not. Bob Sneidar IT Manager Logos Management Calvary Chapel CM On Aug 11, 2006, at 10:00 AM, [EMAIL PROTECTED] wrote: But then you get into issues where buttons have graphics referenced by IDs. The only way around this is to reassign the icon IDs at some point. At 01:19 PM 8/11/2006, you wrote: Since the days of Hypercard, I have known that using ID's to reference objects was sketchy at best. Peter T. Evensen http://www.PetersRoadToHealth.com 314-629-5248 or 888-682-4588 ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Why do group ID's change when cloning a stack
Naming objects are definitely the way to go. (IMHO) It is odd that the only the group ID's would change. Take a look whether the layers of your groups or their objects had changed! I ran into that sort of difficulty a couple of years ago and found it very annoying to have to reestablish references to objects based on IDs, however - at that time, I did not test now - the IDs were changed when a stack was cloned in case the *layers* of the objects had changed. Attributing of new IDs will also happen when a card is copied within the same stack or to another stack (because IDs are unique in a stack), but the order of the IDs will remain the same - unless you have changed the layers of the card objects. Wilhelm Sanke http://www.sanke.org/MetaMedia ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Why do group ID's change when cloning a stack
Is this a programmer-thing? I ask because I have a devil of a time convincing my students to *name* their objects. They end up having problems and it's VERY frustrating... Judy On Fri, 11 Aug 2006, Robert Sneidar wrote: Since the days of Hypercard, I have known that using ID's to reference objects was sketchy at best. As a matter of good programming practice, you should keep track of all your variables and object names so there is no inadvertent duplication to bite you in the butt later. ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Why do group ID's change when cloning a stack
On 8/12/06, Judy Perry [EMAIL PROTECTED] wrote: Is this a programmer-thing? I ask because I have a devil of a time convincing my students to *name* their objects. They end up having problems and it's VERY frustrating... Judy, apart from the ID problem, it's a matter of practicality. If your students come back to a line of script in 6 months time and it says: set the label of btn ID 8765 to Whatever they are not going to have a clue what is going on. However if it says: set the label of btn PrintSelectedText to Whatever they are going to be able to see immediately what it is. Like Richard, I really like the way Rev allows you to have separate names labels, so that labels can be changed to suit customer preferences, languages or what ever you like, while keeping the name the same so all your scripts still work. Cheers, Sarah ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Why do group ID's change when cloning a stack
On Aug 11, 2006, at 11:08 PM, Sarah Reichelt wrote: Like Richard, I really like the way Rev allows you to have separate names labels, so that labels can be changed to suit customer preferences, languages or what ever you like, while keeping the name the same so all your scripts still work. I have the memory of a goldfish. By time I get the edit window open, I forgot the names of the controls. So, I like this idea a lot, but for initial development and experimenting, I usually have the name of the control on the card somehow. When I'm typing in the script, I can look over and see the name. Now if I could drag a control onto a script and have the editor insert a reference to that control, then I can have it all. Or maybe have the names float over controls while I'm editing, so I can glance over and see them. Dar Scott ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
