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 | [EMAIL PROTECTED]
HyperActive Software | http://
www.hyperactivesw.com
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage
your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage
your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage
your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
