When does a Stack Actually Die in the IDE???

David Burgun dburgun at dsl.pipex.com
Tue Apr 18 10:37:52 EDT 2006


Hi,

I have a stack called s1.rev, the short name of the stack is  
"untitled 1". If I run this:

on mouseUp
local myStackName

   set the itemDelimiter to "/"
   put (char 1 to -6 of item -1 of the long id of me) into myStackName,

end mouseUp

and step thru it in the debugger, then myStackName is set to "s1"  
which is the file name, not the short name (set in the Stack Property  
Inspector). If I do a put openStacks in the message box, I get this  
list:

Message Box
revMenubar
revScriptEditor 1
revVariableWatcher
Untitled 1
revTools

s1 is not among the openStacks, but "Untitled 1" is!

if I run the following:

   local myStackFilePathName
   put value(word wordoffset("stack",the long id of me ) + 1 of the  
long id of me) into myStackFilePathName
put the short name of stack myStackFilePathName into myStackName

Then myStackName is set to "Untitled 1" and so it finds it ok in the  
list returned by openStacks.

Do you get the same results? I'm running RunRev 2.6.6 MacOS 10.4.6

All the Best
Dave

On 18 Apr 2006, at 15:09, Mark Smith wrote:

> stackIsOpen2 takes the long id of an object, gets the short name of  
> the stack the object is in, and then checks whether or not it's  
> among the lines of the openStacks - which is a list of the short  
> names of all currently open stacks, not their file names.
>
> It seems to work perfectly well, here ( I assume the listing below  
> is not your actual script, there are typos ).
>
> Best,
>
> Mark
>
> On 18 Apr 2006, at 14:55, David Burgun wrote:
>
>> Hi,
>>
>> I tried this:
>>
>> function stackIsOpen1 pLongID
>>   return (the short name of pLongID is among the lines of the  
>> openstacks)
>> end stackIsOpen
>>
>> was, by my measurement, 4 times slower than
>>
>> function stackIsOpen2 pLongID
>>   set the itemDelimiter to "/"
>>   return (char 1 to -6 of item -1 of pLongID) is among the lines  
>> of  the openStack
>> end stackIsOpen
>>
>> on mouseUp
>> if stackIsOpen1(the long id of me) then
>>   beep
>> end if
>>
>> if stackIsOpen2(the long id of me) then
>>   beep
>> end if
>> end mouseUp
>>
>> And both functions always return false! stackIsOpen1() since it  
>> takes the short name of the button rather than the stack and  
>> stackIsOpen2 since the short name of the stack is not the same as  
>> the file name of the stack.
>>
>> The only way I've found to do it is like this:
>>
>> --------------------------------------------------------------------- 
>> -------
>> --
>> --  ISMGetStackShortName
>> --
>> --------------------------------------------------------------------- 
>> -------
>> function ISMGetStackShortName theObjectLongID
>>   local myStackFilePathName
>>   put value(word wordoffset("stack",theObjectLongID )+ 1 of  
>> theObjectLongID) into myStackFilePathName
>>
>>   return the short name of stack myStackFilePathName
>> end ISMGetStackShortName
>>
>> if ISMGetStackShortName(theObjectLongID) is not among the lines of  
>> openStacks then
>>
>> end if
>>
>>
>> All the Best
>> Dave
>>
>> On 18 Apr 2006, at 14:07, Mark Smith wrote:
>>
>>> Well, since
>>>
>>> function stackIsOpen pLongID
>>>   return (the short name of pLongID is among the lines of the  
>>> openstacks)
>>> end stackIsOpen
>>>
>>> was, by my measurement, 4 times slower than
>>>
>>> function stackIsOpen pLongID
>>>   set the itemDelimiter to "/"
>>>   return (char 1 to -6 of item -1 of pLongID) is among the lines  
>>> of  the openStack
>>> end stackIsOpen
>>>
>>> I wouldn't assume that the engines routines for getting short  
>>> names etc, are going to be faster than string slicing.
>>>
>>> I've no idea what kind of overhead there is in calling externals,  
>>> and it'd have to be a pretty good external to beat Rev's string  
>>> handling, I think...
>>>
>>> Best,
>>>
>>> Mark
>>>
>>> On 18 Apr 2006, at 13:28, David Burgun wrote:
>>>
>>>> Hi,
>>>>
>>>> I was really just after some speed. The problem is that this  
>>>> quite a common thing to want to do, you can do it, but it means  
>>>> parsing a string, which although the solution provided by the  
>>>> wonderful people on this list is pretty fast, it's still slow  
>>>> for doing something like this, which seems pretty silly really  
>>>> since I assume that this information would be almost instantly  
>>>> available in the Engine. I was actually considering writing an  
>>>> External Command to do this, but not sure how fast that would be  
>>>> and whether the solutions provided thus far would be quicker.  
>>>> Any ideas???
>>>>
>>>> Thanks a lot
>>>> All the Best
>>>> Dave
>>>>
>>>> On 18 Apr 2006, at 13:18, Mark Smith wrote:
>>>>
>>>>> I see what you mean. Maybe what's needed is a library of  
>>>>> functions to deal with this sort of thing.
>>>>>
>>>>> Mark
>>>>>
>>>>> On 18 Apr 2006, at 10:34, David Burgun wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> The problem with that is if you have groups or nested groups,  
>>>>>> you then have to loop thru until you find the card or stack.
>>>>>>
>>>>>> All the Best
>>>>>> Dave
>>>>>>
>>>>>> On 15 Apr 2006, at 13:07, Mark Smith wrote:
>>>>>>
>>>>>>> Well, you could try using 'the owner of'. I haven't  
>>>>>>> experimented with it much, so I don't know how flexible it is.
>>>>>>>
>>>>>>> Best,
>>>>>>>
>>>>>>> Mark
>>>>>>> On 15 Apr 2006, at 12:54, David Burgun wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> Thanks a lot for this. One thing that has puzzled me is why  
>>>>>>>> you can't access things like the stack or card of an object.  
>>>>>>>> For instance why can't I just do this:
>>>>>>>>
>>>>>>>> put the short name of the  stack of the long id of me  into  
>>>>>>>> myStackName
>>>>>>>>
>>>>>>>> or
>>>>>>>>
>>>>>>>> put the short name of the  card of the long id of me   
>>>>>>>> myCardName
>>>>>>>>
>>>>>>>> Which would return the name of the stack/card that the  
>>>>>>>> object resides in.
>>>>>>>>
>>>>>>>> It just seems like this ought to work, in fact when I found  
>>>>>>>> out that RunRev didn't support this I was surprised!
>>>>>>>>
>>>>>>>> Any ideas why this isn't supported?
>>>>>>>>
>>>>>>>> All the Best
>>>>>>>> Dave
>>>>>>>>
>>>>>>>> On 15 Apr 2006, at 02:33, J. Landman Gay wrote:
>>>>>>>>
>>>>>>>>> Mark Smith wrote:
>>>>>>>>> > I just had a doh! moment  in response to your <the short  
>>>>>>>>> name of
>>>>>>>>> > pStackLongID>, but then in order to see how much faster  
>>>>>>>>> the engine  does
>>>>>>>>> > this, I tested it the same way I tested my first tries  
>>>>>>>>> (which  was
>>>>>>>>> > actually with 10000 iterations, not 1000), and
>>>>>>>>> >
>>>>>>>>> > function stackIsOpen pLongID
>>>>>>>>> >   return (the short name of pLongID is among the lines of  
>>>>>>>>> the openstacks)
>>>>>>>>> > end stackIsOpen
>>>>>>>>> >
>>>>>>>>> > takes nearly 600 ms!
>>>>>>>>>
>>>>>>>>> Interesting. I never time these things enough. It looks  
>>>>>>>>> like if a script needs to make repeated calls to the  
>>>>>>>>> function, then your way would be preferable because of the  
>>>>>>>>> speed increase.
>>>>>>>>>
>>>>>>>>> It's been an interesting experiment, I like when the list  
>>>>>>>>> does these things.
>>>>>>>>>
>>>>>>>>> -- 
>>>>>>>>> Jacqueline Landman Gay         |     jacque at hyperactivesw.com
>>>>>>>>> HyperActive Software           |     http:// 
>>>>>>>>> www.hyperactivesw.com
>>>>>>>>> _______________________________________________
>>>>>>>>> use-revolution mailing list
>>>>>>>>> use-revolution at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your  
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution




More information about the use-livecode mailing list