Troy,
I think what you really want is the long _name_ of the object.
Try putting this in a button (or better yet, a frontscript):
on mouseDown
if (the controlKey is down) then
set the clipboardData["text"] to the long name of me
end if
pass mouseDown
end mouseDown
You can adjust as necess
On Jul 21, 2004, at 1:02 AM, Richard Gaskin wrote:
But I had thought that one of the parts of this thread noted that the
long ID will include the path to the stack containing the object.
This is no problem for an internally used stack that never moves, but
should the path to the stack change th
Troy Rollins wrote:
On Jul 21, 2004, at 12:30 AM, Richard Gaskin wrote:
set the clipboardData["text"] to the long id of me
But why the clipboard?
To get long, tedious explicit paths to objects into scripts more easily
and save some typing. The very reason this entire thread began. ;-)
But I ha
On Jul 21, 2004, at 12:30 AM, Richard Gaskin wrote:
set the clipboardData["text"] to the long id of me
But why the clipboard?
To get long, tedious explicit paths to objects into scripts more easily
and save some typing. The very reason this entire thread began. ;-)
--
Troy
RPSystems, Ltd.
http:
Troy Rollins wrote:
On Jul 20, 2004, at 11:47 PM, Richard Gaskin wrote:
What you should see is line 1 of the message box will contain the name
of the palette stack in which the button was clicked, but line 2 will
contain the name of the second, toplevel, stack.
Hey! I got an idea!
Anybody have a
On Jul 20, 2004, at 11:47 PM, Richard Gaskin wrote:
What you should see is line 1 of the message box will contain the name
of the palette stack in which the button was clicked, but line 2 will
contain the name of the second, toplevel, stack.
Hey! I got an idea!
Anybody have a good means to get th
Ken Ray wrote:
The defaultstack is always what is returned by the topStack() function,
unless it is set specifically to some other stack via script.
Not quite: the defaultStack is the stack in the current message path,
but can be set to point to any other stack to allow incomplete
references to o
On Jul 20, 2004, at 10:56 PM, Ken Ray wrote:
Mode 0: Closed bug not loaded
Freud would be proud.
--
Troy
RPSystems, Ltd.
http://www.rpsystems.net
___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution
On Jul 20, 2004, at 10:48 PM, Brian Yennie wrote:
Er, I guess that all means "agreed". =)
Actually, that helps. I'm still at a stage where I frequently say "it
works, but I'm probably not doing it the way which is intended." Any
confirmation that I'm not WAYY off-track, is a good thing.
--
Troy
On Jul 20, 2004, at 10:46 PM, Ken Ray wrote:
Now isn't that clear as mud? ;-)
Already committed to memory... and right out the other side. ;-P
--
Troy
RPSystems, Ltd.
http://www.rpsystems.net
___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists
> Mode 0: Closed bug not loaded (a stack window that is closed
> but the stack is still loaded in memory). Mode 1: A "normal"
> editable stack window Mode 2: A non-editable stack window
> (opened with its cantModify true) Mode 3: Modeless dialog
> Mode 4: Palette Mode 5: Modal dialog Mode 6: Sh
Rather slippery, the defaultStack. Now, who was asking why I found
myself using explicit paths? ;-)
Who? Me? =)
(Just kidding. I'm sure the defaultStack is plenty reliable and
controllable, and under most circumstances is exactly what you think
it would be... it just seems to get away from me s
> At 5:09 PM -0500 7/20/2004, Ken Ray wrote:
> > > But further on this... if the defaultStack is closed, what
> > determines
> >> what the new defaultStack is?
> >
> >Whatever is the top-most, non-palette stack (and if only
> palettes are
> >left, the one that is "in front".
>
> This is corre
On Jul 20, 2004, at 10:32 PM, Richard Gaskin wrote:
> But further on this... if the defaultStack is closed, what
determines
what the new defaultStack is?
Whatever is the top-most, non-palette stack (and if only palettes
are left, the one that is "in front".
This is correct in most situations,
Jeanne A. E. DeVoto wrote:
At 5:09 PM -0500 7/20/2004, Ken Ray wrote:
> But further on this... if the defaultStack is closed, what determines
what the new defaultStack is?
Whatever is the top-most, non-palette stack (and if only palettes are
left, the one that is "in front".
This is correct in
At 5:09 PM -0500 7/20/2004, Ken Ray wrote:
> But further on this... if the defaultStack is closed, what determines
what the new defaultStack is?
Whatever is the top-most, non-palette stack (and if only palettes are left,
the one that is "in front".
This is correct in most situations, but it can g
--- Ken Ray <[EMAIL PROTECTED]> wrote:
> on DoIt_2
> set the defaultStack to the topStack
> put "Hello" into field "Greetings"
> end DoIt_2
>
> ... causes no harm at all, and tells Rev
> to focus its attention on the topStack
> (which it probably was doing already)
probably.
i thought the
--- Troy Rollins <[EMAIL PROTECTED]> wrote:
> Most of my problems went away if I used
> explicit paths to objects and their scripts.
tht's it.
=
[EMAIL PROTECTED]http://www.erikhansen.org
__
Do you Yahoo!?
New and Improved Yahoo! Mail -
On Jul 20, 2004, at 4:30 PM, Brian Yennie wrote:
I dunno if this helps at all, but if the issue is with opening some
other stack mid-script and having that affect your object references
later in the script, you could consider wrapping up your own stack
opening routine which maintains the default
Troy,
I dunno if this helps at all, but if the issue is with opening some
other stack mid-script and having that affect your object references
later in the script, you could consider wrapping up your own stack
opening routine which maintains the defaultStack:
on openStackSafe stackName
put t
On Jul 20, 2004, at 1:13 PM, Ken Ray wrote:
If you have all kinds of non-linear stuff going on, with stacks being
able
to be opened or activated while other scripts are running, you're
right that
you can't depend on the context at any given time, and so in that case,
Troy, I think you're doing th
> Based on reading this, my guess would have to be that often the
> defaultStack is not what I think it is at any given time, or more
> specifically, portions of my code my not be aware that other portions
> of my code have opened another stack, thereby changing the
> defaultStack... so I freq
> As usual, it was a lot of help. So, if you have a main stack which
> opens and closes a lot of various substacks, and external resource
> stacks, do you also have a lot of setting the defaultStack explicitly?
Only if you want to work in a context *other* than the stack you're opening.
For exam
On Jul 20, 2004, at 2:04 AM, Ken Ray wrote:
I could refer to it in any of the following ways (assuming the
context/defaultStack is the stack "Stack1" and the currently displayed
card
is card #1):
field "Greetings" of group "innerGroup" of group "outerGroup" of
card 1 of
stack "Stack1"
field
On Jul 20, 2004, at 2:04 AM, Ken Ray wrote:
Well, if it's any help, the context in which one works is generally
the last
stack that was opened. The stack with the current "focus" is the
defaultStack, which can be changed explicitly if you want to work on
another
stack without having to use a long
> I'm writing software that works well in Transcript, but I'm a
> long way
> from understanding it, and it is a long way from what I know.
Well, if it's any help, the context in which one works is generally the last
stack that was opened. The stack with the current "focus" is the
defaultStack, w
On Jul 20, 2004, at 12:56 AM, Ken Ray wrote:
Troy, is there some specific reason you need to get the long name (or
long
identifier) of an object? The only reason I ask is that 99% of the
time I
don't need long identifiers; either a short (fld "Test") or
abbreviated (fld
"Test" of group "MyGroup"
Troy, is there some specific reason you need to get the long name (or long
identifier) of an object? The only reason I ask is that 99% of the time I
don't need long identifiers; either a short (fld "Test") or abbreviated (fld
"Test" of group "MyGroup") identifier has usually worked for me.
Just cu
On Jul 19, 2004, at 7:44 PM, Sarah Reichelt wrote:
Ah well, I guess that's the beauty of a modifiable IDE. I suppose I
can add something as a plug in. Typing some of those paths is
tedious, and I don't even see anything which actually displays the
full path to the object, even if it doesn't go a
You mean, like:
set the clipboardData to the long name of the selectedObject
Yes, I suppose so. This isn't something the IDE has built-in, I take
it? Seems like it should be supported via a context menu item in your
stacks, as well as the context menu in the application browser.
Ah well, I guess
On Jul 19, 2004, at 2:33 AM, Richard Gaskin wrote:
If the goal is to paste it into a script, the long ID is probably not
what you want, since it will include the file path to the mainstack
the object is in.
Yes, thanks - I tried it in the message window with a few objects, and
got those results.
>On 7/18/04 8:22 PM, Troy Rollins wrote:
>
>> Is there already some means to do this, and I have overlooked it?
>>
>> e.g. select and object, do something which copies its path to the
>> clipboard, paste into the script window, and get a result like -
>>
>> button "myButton" of group "MainControls"
32 matches
Mail list logo
