When does a Stack Actually Die in the IDE???
Mark Smith
mark at maseurope.net
Tue Apr 18 10:53:33 EDT 2006
Ah, I see what you mean. I made the assumption (when will I learn?)
that the file name would be a superset of the stack name.
Which is a shame, where speed matters, as getting the short name from
the engine is quite a bit slower than simply parsing the file name.
Best,
Mark
On 18 Apr 2006, at 15:37, David Burgun wrote:
> 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
>
> _______________________________________________
> 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