formattedheight and formattedwidth

Richard Gaskin ambassador at
Mon Jun 27 10:27:51 EDT 2011

Pete wrote:

> OK I see what you mean about the formatted versions of height/width.  The
> straight height and width properties don't seem to come anywhere close to
> working even allowing for menu bar issues (I'm on OS X). They set the
> height/width to what they were for the previous card opened in the stack,
> not the current card.

This thread confuses me, since the height and width properties of a card 
object cannot be set at all.

A card is merely a container for controls inside the stack, allowing 
multiple sets of controls within a given window.  But the card always 
fills the stack, so changing the size of the stack will change the size 
of the card, but the size of the card itself cannot be set 
independently. Indeed, if it could what would happen to the area beyond 
the edges of a card which is smaller than the window displaying it?

AFAIK, there's only one exception to the general rule that the card size 
will always be the same as the stack size:  if the stack has a menubar 
defined, its editMenus property is false (the default), and it's 
currently running under OS X.

Since OS X has a global menu bar, the stack's menubar is scrolled out of 
view and the size of the stack is automatically cropped by the height of 
the menubar group.

In that case, the height of the card will be the stack height + the 
height of the menubar group, and the card width will remain the same as 
the stack's width.

Aside from that one set of circumstances on OS X, the card size should 
always reflect the stack size, and even on OS X with a menubar the stack 
size still governs the card size, the only difference being the height 
of the menubar group.

So if you want to change the size of the window, just change the size of 
the stack.

If you don't want to change the size of the window, what is the goal of 
attempting to change the card size?

  Richard Gaskin
  Fourth World
  LiveCode training and consulting:
  Webzine for LiveCode developers:
  LiveCode Journal blog:

More information about the Use-livecode mailing list