Re: strange nested groups behaviour
Björnke- The commented line 'do put the quote existingProperty quote' should in my opinion result in an error, but puts the actual text entered. However, RunRev will argue that this is a design decision, not a bug (At least i'd guess they would). I agree that it should be considered a bug, and I'll file a report about it, no matter what the team decides about its final disposition. I can't imagine a scenario in which this would be a useful and unambiguous syntax.. -- Mark Wieder [EMAIL PROTECTED] ___ 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: strange nested groups behaviour
Mark, I'm aware of that and usually name my objects with french words. In my previous posts I used date and day for the only purpose of my demonstration for an english-speaking audience. Best, JB jbv- In addition to the above weirdnesses with the owner of a group, I think it's also bad form to use a keyword as the name of an object. You'll probably stay out of trouble more if you name it something like grpDate. YMMV. ___ 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: strange nested groups behaviour
On 10 Sep 2007, at 23:03, Mark Wieder wrote: jbv- In addition to the above weirdnesses with the owner of a group, I think it's also bad form to use a keyword as the name of an object. You'll probably stay out of trouble more if you name it something like grpDate. YMMV. Can you elaborate on why that would be bad form? I never had problems with naming things the same as a keyword, as long as I quoted the name, which I always do. I did however have problems with using only numbers as names, or starting a stack's name with rev. -- official ChatRev page: http://chatrev.bjoernke.com Chat with other RunRev developers: go stack URL http://homepage.mac.com/bvg/chatrev1.3.rev; ___ 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: strange nested groups behaviour
Hello Björnke, Mark and all, Le 11 sept. 07 à 12:47, Björnke von Gierke a écrit : On 10 Sep 2007, at 23:03, Mark Wieder wrote: jbv- In addition to the above weirdnesses with the owner of a group, I think it's also bad form to use a keyword as the name of an object. You'll probably stay out of trouble more if you name it something like grpDate. YMMV. Can you elaborate on why that would be bad form? I never had problems with naming things the same as a keyword, as long as I quoted the name, which I always do. I did however have problems with using only numbers as names, or starting a stack's name with rev. I think that Mark wanted to point out that using 'reserved' word for controls names, variables, etc. is, in itself, not a good idea. Sure if you quote all controls names (as I do it :-) there should not be any problem: it's only a question of 'right' behavior to avoid issues when coding. Making variables explicit, not using 'reserved words' (BTW 'date' is the same word in English and French :-), quoting all controls names is probably more exigent but prevents many errors ;-) As for stacks prefixed with 'rev', yes, the IDE treats them in another way (for instance, such stacks are hidden when editing a script). Actually it's very interesting to use this prefix when building plugins but it is a bit touchy, in particular when debugging (you have to set the gRevDevelopment global variable to true to be able to debug). There are many other differences, of course and 'rev' prefix should be only used when building tools for the IDE. If I remember well, the IDE displays a well documented confirmation dialog when you attempt to name a stack with a 'rev' prefix :-) Best regards from Paris, Eric Chatonet. Plugins and tutorials for Revolution: http://www.sosmartsoftware.com/ Email: [EMAIL PROTECTED]/ ___ 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: strange nested groups behaviour
I think it's always a good idea to NOT name anything with system keywords. And you're in for real problems naming custom properties with the same name as system properties, quotes or no quotes. Rev doesn't like that. Custom Properties, too sometimes have problems when they start with a number. On 10 Sep 2007, at 23:03, Mark Wieder wrote: jbv- In addition to the above weirdnesses with the owner of a group, I think it's also bad form to use a keyword as the name of an object. You'll probably stay out of trouble more if you name it something like grpDate. YMMV. Can you elaborate on why that would be bad form? I never had problems with naming things the same as a keyword, as long as I quoted the name, which I always do. I did however have problems with using only numbers as names, or starting a stack's name with rev. -- stephen barncard s a n f r a n c i s c o - - - - - - - - - - - - ___ 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: strange nested groups behaviour
Björnke- It's hard to add to much to what Eric and Stephen have already posted, but let me also point out that while you (and I) may always quote object names, the rev engine isn't always so consistent about it. Create a new stack with a single button named date. Then get the short name of button 1. On mouseUp local tObj local tQuotedObj put the short name of button1 into tObj put quote tObj quote into tQuotedObj do put the tObj do put the tQuotedObj End mouseUp -- Mark Wieder [EMAIL PROTECTED] ___ 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: strange nested groups behaviour
On mouseUp local tObj local tQuotedObj put the short name of button 1 into tObj put quote tObj quote into tQuotedObj do put the tObj --do put the tQuotedObj End mouseUp So if I fix your code to work (as above), and use a button with the short name set to an existing property, it'll output the property. However, that is completely expected, as using a string that results in a property will give you the property. Coincidentally, using the above script with a button that is not a property, will just give you an error. So your code is only useful if the button is expected to be named as a property to begin with, and your code would be faulty if that is not the sole purpose of it. The commented line 'do put the quote existingProperty quote' should in my opinion result in an error, but puts the actual text entered. However, RunRev will argue that this is a design decision, not a bug (At least i'd guess they would). To verify, enter 'put the something' into the message box (no single quotes). Bjoernke -- official ChatRev page: http://chatrev.bjoernke.com Chat with other RunRev developers: go stack URL http://homepage.mac.com/bvg/chatrev1.3.rev; ___ 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: strange nested groups behaviour
Hi JB, This is not the perfect approach but should solve the strange behaviour. If this fragment was put in place of the line that has the owner of the owner of me repeat with x = 1 to 12 if the id of group (search x) is in the long name of me then exit repeat end repeat put (search x) into tMyGrandparent -- now you have the name of the ultimate owner of the field. In my nested group heirarchy I set a custom attribute for the sub groups and objects in the group called parent_group. That way I can get the parent_group of the owner of me... HTH John -Original Message- From: Stephen Barncard [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 12, 2007 01:42 AM To: 'How to use Revolution' Subject: Re: strange nested groups behaviour I think it's always a good idea to NOT name anything with system keywords. And you're in for real problems naming custom properties with the same name as system properties, quotes or no quotes. Rev doesn't like that. Custom Properties, too sometimes have problems when they start with a number. On 10 Sep 2007, at 23:03, Mark Wieder wrote: jbv- In addition to the above weirdnesses with the owner of a group, I think it's also bad form to use a keyword as the name of an object. You'll probably stay out of trouble more if you name it something like grpDate. YMMV. Can you elaborate on why that would be bad form? I never had problems with naming things the same as a keyword, as long as I quoted the name, which I always do. I did however have problems with using only numbers as names, or starting a stack's name with rev. -- stephen barncard s a n f r a n c i s c o - - - - - - - - - - - - ___ 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 ___ 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
strange nested groups behaviour
Hi list, I'm facing a strange behaviour regarding nested groups. I have a substack that contains 12 groups named search1 to search12. Each group contains various objects (exactly the same kind of objects in the same order with the same names), among which is a group date that contains 3 fields named day, month and year. Here the strange behaviour : if I put in grp date of any grp search the script line : put the owner of me it always returns the right group name (search1, search2 etc) BUT when I put the following script line in each field of groups date put the owner of the owner of me it always returns group search1 Any idea of what's happening ? Thanks in advance, JB ___ 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: strange nested groups behaviour
well, I just found the explanation. the owner of me returns group date (for instance), and since each of my groups search contains the same kind of objects with the same names, Rev checks some lookup table for a group date and the first one it finds is group date in group search1... I've been deeply into xml lately and I thought that the owner of me would return some kind of unique object identifier... next time I'll think twice before coding blindly... Best, JB Hi list, I'm facing a strange behaviour regarding nested groups. I have a substack that contains 12 groups named search1 to search12. Each group contains various objects (exactly the same kind of objects in the same order with the same names), among which is a group date that contains 3 fields named day, month and year. Here the strange behaviour : if I put in grp date of any grp search the script line : put the owner of me it always returns the right group name (search1, search2 etc) BUT when I put the following script line in each field of groups date put the owner of the owner of me it always returns group search1 Any idea of what's happening ? Thanks in advance, JB ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: ___ 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: strange nested groups behaviour
--- jbv [EMAIL PROTECTED] wrote: well, I just found the explanation. the owner of me returns group date (for instance), and since each of my groups search contains the same kind of objects with the same names, Rev checks some lookup table for a group date and the first one it finds is group date in group search1... I've been deeply into xml lately and I thought that the owner of me would return some kind of unique object identifier... next time I'll think twice before coding blindly... Best, JB Hi JB, As you concluded, the owner of me returns a short reference to the group, which can of course be ambiguous. If you have multiple groups with the same name on your card, Revolution will then grab the first group it can find. The solution is to work with the long ID of the object itself. The long ID of the owner is then word 4 to -1 of this long ID. This trick resolves the name ambiguity. Hope this helped, Jan Schenkel. Quartam Reports PDF Library for Revolution http://www.quartam.com = As we grow older, we grow both wiser and more foolish at the same time. (La Rochefoucauld) Got a little couch potato? Check out fun summer activities for kids. http://search.yahoo.com/search?fr=oni_on_mailp=summer+activities+for+kidscs=bz ___ 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: strange nested groups behaviour
Jan, Nevertheless I think it can be considered as a bug, or at least as a serious limitation of the engine. The Rev doc for owner says Reports which object is next in the object hierarchy, and since xml is now widespread, one can expect owner to behave somehow like parentNode... JB As you concluded, the owner of me returns a short reference to the group, which can of course be ambiguous. If you have multiple groups with the same name on your card, Revolution will then grab the first group it can find. The solution is to work with the long ID of the object itself. The long ID of the owner is then word 4 to -1 of this long ID. This trick resolves the name ambiguity. ___ 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: strange nested groups behaviour
Jan, it's me again... I'm afraid your solution doesn't work with more than 2 levels of nested groups with similar names The solution is to work with the long ID of the object itself. The long ID of the owner is then word 4 to -1 of this long ID. This trick resolves the name ambiguity. Here's the situation : I have group search1 (id 1021) which contains group date (id 1038) which contains field day (id 1029) and group search2 (id 4334) which contains group date (id 4335) which contains field day (id 4336) if I type in the msg box : put the long id of owner of fld id 4336 it returns : group id 1038 of group id 1021 of card id 1002 of stack ... But put the long id of the owner of grp id 4335 returns group id 4334 of card id 1002 of stack ... Conclusion, I need to rename my groups date to date1, date2 etc. Best, JB ___ 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: strange nested groups behaviour
On Sep 10, 2007, at 7:31 AM, jbv wrote: Jan, it's me again... I'm afraid your solution doesn't work with more than 2 levels of nested groups with similar names It you always start with the long id of the target and then delete 4 words for each level you want to move up in the hierarchy you will be safe. put the long id of the target into theID delete word 1 to 4 of theID -- gives the owner delete word 1 to 8 of theID -- gives the owner of the owner .. etc. IMO the owner should work in your scenario but it doesn't. -- Trevor DeVore Blue Mango Learning Systems www.bluemangolearning.com-www.screensteps.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: strange nested groups behaviour
Hi JB, Could you then use: put the owner of the owner of (the long name of me)? That would not be ambiguous because it is the long object path to the source of the message Regards John Subject: Re: strange nested groups behaviour well, I just found the explanation. the owner of me returns group date (for instance), and since each of my groups search contains the same kind of objects with the same names, Rev checks some lookup table for a group date and the first one it finds is group date in group search1... I've been deeply into xml lately and I thought that the owner of me would return some kind of unique object identifier... next time I'll think twice before coding blindly... Best, JB Hi list, I'm facing a strange behaviour regarding nested groups. I have a substack that contains 12 groups named search1 to search12. Each group contains various objects (exactly the same kind of objects in the same order with the same names), among which is a group date that contains 3 fields named day, month and year. Here the strange behaviour : if I put in grp date of any grp search the script line : put the owner of me it always returns the right group name (search1, search2 etc) BUT when I put the following script line in each field of groups date put the owner of the owner of me it always returns group search1 Any idea of what's happening ? Thanks in advance, JB ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: ___ 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 ___ 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: strange nested groups behaviour
jbv- In addition to the above weirdnesses with the owner of a group, I think it's also bad form to use a keyword as the name of an object. You'll probably stay out of trouble more if you name it something like grpDate. YMMV. -- Mark Wieder [EMAIL PROTECTED] ___ 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
