I asked this a couple of days ago and got no response so I thought I'd try
again.
Why are locking size and position of an image inextricably linked? They seem
to me to be two separate entities. I know how to get around the situation via
script, but I don't know why there should
thought I'd try
again.
Why are locking size and position of an image inextricably linked? They seem
to me to be two separate entities. I know how to get around the situation
via script, but I don't know why there should be the inconvenience of having
to get around anything
are locking size and position of an image inextricably linked? They
seem to me to be two separate entities. I know how to get around the
situation via script, but I don't know why there should be the inconvenience
of having to get around anything. Is there a good reason for this or is
it just
On Feb 5, 2010, at 8:35 AM, Mark Swindell wrote:
I asked this a couple of days ago and got no response so I thought
I'd try again.
Why are locking size and position of an image inextricably linked?
They seem to me to be two separate entities. I know how to get
around the situation via
ago and got no response so I thought I'd try
again.
Why are locking size and position of an image inextricably linked? They
seem to me to be two separate entities. I know how to get around the
situation via script, but I don't know why there should be the inconvenience
of having to get
I was surprised to learn that a control that has its position locked in the
inspector can't be moved in edit mode, but can be moved under script
control. Should I have been so surprised?
In other words, is there a way to really, really lock such a property of an
object? (without trapping every
DunbarX wrote:
I was surprised to learn that a control that has its position locked in the
inspector can't be moved in edit mode, but can be moved under script
control. Should I have been so surprised?
In other words, is there a way to really, really lock such a property of an
object?
Sure:
I don't think you should be surprised (though it was an aha moment when I
first saw this was the case).
Not sure why you'd want to lock something down so tight even you couldn't move
it via script. But if you don't want it moved, you'd have to except the
particular object in your script
Mark, Richard.
It is mainly academic for me. It came up when I tried to set the loc of an
object in a certain stack from a utility stack I use, without specifying the
pathname of that object. A similar object in the utility stack moved
instead.
I was just playing around, set the lockLocation
RichardG wrote:
The lockLoc property prevents interactively adjusting the object with
the mouse, but leaves your scripts free to control its size and position.
The arrowkeys can also control (i.e., move) a locked object - handy.
Jim Lambert
___
I take it all back.
If I agree that a script should be able to move (or resize) an object whose
lockLoc is true because scripts probably have a good reason for doing so,
but that a user is precluded from doing so with a mouse, then why would
that user be given the right to do so with an
dunb...@aol.com wrote:
I take it all back.
If I agree that a script should be able to move (or resize) an object whose
lockLoc is true because scripts probably have a good reason for doing so,
but that a user is precluded from doing so with a mouse, then why would
that user be given the
J. Landman Gay wrote:
It's strictly to ease developers during the construction phase.
Oops, I should probably add that the functionality expanded after that.
Lockloc is, of course, now used to prevent resizing of some objects
(like groups and images) when their contents change. Without a
Jacques.
OK, as mainly a development aid I see all that.
Rev is far less forgiving about trapping reserved words than you-know-what,
so (I think) I cannot write a handler that traps set, checks to see if my
immovable object is in danger, and acts appropriately.
There was discussion a while
DunbarX wrote:
I take it all back.
If I agree that a script should be able to move (or resize) an object whose
lockLoc is true because scripts probably have a good reason for doing so,
but that a user is precluded from doing so with a mouse, then why would
that user be given the right to do so
Richard:
That explains that. Thanks. One day I will feel brave enough to look behind
the curtain of this unbelievably rich program. Right now I am still reading
the dictionary. I'm on page 5.
Craig
In a message dated 1/8/10 4:04:32 PM, ambassa...@fourthworld.com writes:
This is not an
dunb...@aol.com wrote:
Richard:
That explains that. Thanks. One day I will feel brave enough to look behind
the curtain of this unbelievably rich program. Right now I am still reading
the dictionary. I'm on page 5.
You're ahead of most people, I think. :)
--
Jacqueline Landman Gay
dunb...@aol.com wrote:
Jacques.
OK, as mainly a development aid I see all that.
Rev is far less forgiving about trapping reserved words than you-know-what,
so (I think) I cannot write a handler that traps set, checks to see if my
immovable object is in danger, and acts appropriately.
18 matches
Mail list logo
