Pointer icon: limiting movement by axis

[EricMC]

This is probably a beginner's question — but I can't find any mention in the literature or forums.

When I use the pointer tool:
• mostly its icon is four-way arrows (a cross: up/down/left/right);
• but I've noticed that, on occasion, its icon is limited to one axis (a line: either up/down or left/right);
• and sometimes it's even apparently limited to a diagonal (a line: either down-right/up-left, or down-left/up-right).

Why is that?

Is there some way actually to constrain the movement of grabbed objects within a particular vector?

Back in the days of Hypercard, you could limit object drags to horizontal or vertical by holding down the shiftKey when dragging.

This was very handy when copying and laying out fields.

Is there a similar shortcut in LiveCode to save me having to use the alignment tool?

Thanks for your thoughts,

Eric

[FourthWorld]

I don't believe there's a keyboard constraint, but there is the Grid property, which saves me lots of time. I set it to 4 in Prefs, and turn it on from the View menu, and everything I lay out snaps in 4-px increments, flexible enough to handle nearly any layout (I can always arrow-key to nudge if needed), but course enough to allow effortless alignment.

[jacque]

The shape of the pointer tool indicates which directions you can drag the handles during resizing. Diagonal cursors appear on corner handles and horizontal/vertical cursors appear at middle handles. If the pointer has a small cross at the lower right, it's just in plain selection mode.

As Richard mentioned, I don't believe there's a way to limit the drag direction. But there are some cool keyboard shortcuts during resizing. Shift-drag contrains the object to its starting ratio size, and if the object is an image, Cmd-drag will crop it. (Be careful, there's no undo.) Option-drag clones the object.

[EricMC]

Thanks, jacque and FourthWorld for the advice.

I did have a go setting the snapToGrid in Prefs — which was tricky on a Mac, due to a bug in the revPreferencesGUI.rev stack (Panos helped me to patch that by adding the round() function to the arrow buttons' scrollBarDrag routine:
Then I dropped a Grid on/off checkBox onto the preferences tab for good measure).

Meanwhile, I banged out some code to constrain movement by axis in Edit Mode, called by the mouseMove function. It's a bit clunky, but it does sort of work - if anyone's interested?

Yes, the sparse nature of the undo command in LiveCode catches me out again and again. We've got so used, now, to applications running on multiple undo/step-back/change histories that only to be able to undo once (if you're lucky) feels primitive. But my guess is that such features must require a complete bottom-up redesign of the way changes are stored (effectively, a paradigm is turned around: instead of saving/auto-saving the current state of a file, a long history of each change step is auto-saved every time one is made - which must demand a careful documentation of the exact function of every menu and button so it can be reproduced from the last saved version). Perhaps there's a chance it'll creep in with LiveCode 10?