To handle unplaced groups:
getProp uRuggedID
get the long id of the target
if card is among the words of it then return (word 1 to 3 of it
word -7 to -4 of it)
return word 1 to 3 of it
end uRuggedID
getProp uRuggedLongID
get the long id of the target
if card is among the words of
On 2/28/06 12:41 AM, Geoff Canyon [EMAIL PROTECTED] wrote:
To handle unplaced groups:
getProp uRuggedID
get the long id of the target
if card is among the words of it then return (word 1 to 3 of it
word -7 to -4 of it)
return word 1 to 3 of it
end uRuggedID
getProp
Handling cards as well:
getProp uRuggedID
get the long id of the target
if word 1 of it is card then return word 1 to 3 of it
if card is among the words of it then return (word 1 to 3 of it
word -7 to -4 of it)
return word 1 to 3 of it
end uRuggedID
getProp uRuggedLongID
get the
On 2/28/06 2:06 AM, Geoff Canyon [EMAIL PROTECTED] wrote:
getProp uRuggedID
get the long id of the target
if word 1 of it is card then return word 1 to 3 of it
if card is among the words of it then return (word 1 to 3 of it
word -7 to -4 of it)
return word 1 to 3 of it
end
On 28 Feb 2006, at 03:55, Dick Kriesel wrote:
-snip-
A rugged id is a native long id stripped of any of group id
clauses and
of stack clauses, intended for use within a single stack.
A rugged long id is a native long id stripped of any of group id
clauses, intended for use across multiple
On Feb 28, 2006, at 2:21 AM, Dick Kriesel wrote:
What about a control on a card in a substack?
Good catch. I don't have time this morning to figure my way around
that, and my script is getting near to yours in complexity anyway.
gc
___
On 28 Feb 2006, at 15:27, wouter wrote:
-snip-
Some corrections:
getprop uRuggedID
get the long id of the target
if word 1 of it is stack then return word 1 to 2 of it ###
in case it is a substack
if word 1 of it is card then return word 1 to 3 of it
if card is among
On 2/27/06 4:00 AM, Geoff Canyon [EMAIL PROTECTED] wrote:
HOOT takes advantage of the container based inheritance that
Revolution provides, by representing your class hierarchy as a set of
nested groups on a card. Each group is named for the class it
represents. Groups are nested to make the
I've updated the HOOT web site to clarify the instructions. I should
point out that HOOT is extremely simple to use: to set up HOOT you
need to do six things:
1. Edit HOOT's stack script to include the messages you want your
classes to handle.
2. Create and name the groups representing
It's just wrong how easy it is to be an xtalk h4x0r
--
On the first day, God created the heavens and the Earth
On the second day, God created the oceans.
On the third day, God put the animals on hold for a few hours,
and did a little diving.
And God said, This is good.
Geoff-
Looks nice. I'll spend some time with this today.
Regarding the long id thing, Dick Kriesel and I were talking about
this last month and I have now switched my usage over to just the
id, based on the fact that ids within a stack are unique and
immutable. You can pass ids without any
Recently, Mark Wieder wrote:
Regarding the long id thing, Dick Kriesel and I were talking about
this last month and I have now switched my usage over to just the
id, based on the fact that ids within a stack are unique and
immutable. You can pass ids without any problem and it's just a single
Scott-
Monday, February 27, 2006, 10:54:27 AM, you wrote:
control pID of this stack
I would be wary of this, from the standpoint of using object references in
variables. I've come across intermittent cases in complex scripts where I
artificially created an object reference by placing
Recently, Mark Wieder wrote:
control pID of this stack
I would be wary of this, from the standpoint of using object references in
variables.
Yes, thanks for the warning. I don't use object numbers myself and
did, of course, mean to type:
control id pID of this stack
Actually, that's
On 2/27/06 11:30 AM, Scott Rossi [EMAIL PROTECTED] wrote:
control id pID of this stack
Actually, that's not what I meant. Using the long name or ID provides a
full path to an object (including the card the object sits on, group its
in, etc). I haven't used your notation above but using a
Hi Geoff,
This Hacked Object oriented Transcript reads like an
extraordinarily useful addition to the techniques
available in this platform.
In this platform, i've played mostly with vector graphics.
With the stack PenTool, i'm able to create individual vector graphics,
but latter when these
On 27 Feb 2006, at 23:06, Dick Kriesel wrote:
-snip-
...
set the uPropertyThatRefersToARevObject of the target \
to the uRuggedID of tRevObject
...
getProp uRuggedID
put the long id of the target into tLongID
if word 1 of tLongID is not stack then
-- note: stacks do not have
On 2/27/06 6:02 PM, wouter [EMAIL PROTECTED] wrote:
Rugged id's are a good idea but this handler will not do the trick.
And it is difficult to deduce from this handler from where to where
or which parts of the long id is what you call the rugged id.
Thanks for catching my error, Wouter. I
On 2/27/06 6:37 PM, Dick Kriesel [EMAIL PROTECTED] wrote:
A rugged id is a native long id stripped of any of group id clause.
Close, but no cigar. (Why do people say that?)
A rugged id is a native long id stripped of any of group id clauses and
of stack clauses, intended for use within a
Scott-
Monday, February 27, 2006, 11:30:30 AM, you wrote:
Actually, that's not what I meant. Using the long name or ID provides a
full path to an object (including the card the object sits on, group its
in, etc). I haven't used your notation above but using a simple object
reference (that
Dick-
Monday, February 27, 2006, 2:06:23 PM, you wrote:
As Scott points out, the problem with storing short ids is that they can be
ambiguous. A stored short id isn't sufficient to set or get a property of a
control that appears on more than one card.
Object IDs are documented as being
On 2/27/06 8:11 PM, Mark Wieder [EMAIL PROTECTED] wrote:
For
the purposes of putting parentclass handlers in a group, you shouldn't
need to specify a particular card - there shouldn't be any ambiguity
to resolve. I think.
I agree: unplaced groups are good for single inheritance.
-- Dick
On 2/27/06 6:02 PM, wouter [EMAIL PROTECTED] wrote:
Rugged id's are a good idea but this handler will not do the trick.
And it is difficult to deduce from this handler from where to where
or which parts of the long id is what you call the rugged id.
For a stack, the rugged id is the long id.
The id needs to include the stack reference, because it is a
reference to the target object.
Based on that, it doesn't matter that the path can change, since the
long id is only stored for the length of the call to the class group.
The class groups are referenced by name and the long id of
On Feb 27, 2006, at 2:06 PM, Dick Kriesel wrote:
As I discussed with Mark, the problem with storing long ids is that
they can
be brittle. A stored long id becomes invalid when a developer moves a
control to a different group.
At least for the purposes of HOOT, the long id is only stored
On Feb 27, 2006, at 2:36 PM, capellan wrote:
Hi Geoff,
This Hacked Object oriented Transcript reads like an
extraordinarily useful addition to the techniques
available in this platform.
In this platform, i've played mostly with vector graphics.
With the stack PenTool, i'm able to create
On Feb 27, 2006, at 6:37 PM, Dick Kriesel wrote:
getProp uRuggedID
put the long id of the target into tLongID
if word 1 of tLongID is not stack then
-- note: stacks do not have rugged ids
put word 1 to 3 of tLongID into tRuggedID
put offset( of card id ,tLongID) into tOffset
27 matches
Mail list logo
