Resize Stack Sent Everytime a Stack Opens?

[Richard Gaskin]

Sannyasin Brahmanathaswami wrote:

 > 1) You cannot get the coordinates of anything on start up or opencard.

"anything" is vast.

On mobile, resizeStack should be sent to your stack before it is first 
rendered.  Its arguments are the width and height of the stack.

Given a card's origin always being 0,0, this should always work:

on resizeStack x,y
    answer "The rectangle in which you can place controls is: " \
     0,0,x,y
end resizeStack

If it doesn't that would need an engine fix.


 > 2) The resizestack in not firing automatically in many cases. There is
 > difference between Android and iOS. If it does, we get nothing in.
 > x,y.

If resizeStack is not being sent before the card is rendered, and/or the 
expected values are not being sent, that sounds like a bug.


 > 3) using the send 'command' [params] in 0 millisecond is now causing
 > problems.

Such as...?

(Though you should not need to use timers for something as fundamental 
as layout.  They are useful elsewhere, though, and if broken would need 
to be fixed. If the issue you've had with them is limited to layout, I 
suspect the cause is the message triggering the timer rather than the 
timer itself.)


 > 4) if you get the card width and height after orientationChanged. Just
 > put then in you handler

An orientationChanged message should be accompanied by a resizeStack 
message.  This lets you handle common layout tasks from a common 
resizeStack handler, while using orientationChanged for the subset of 
things one might want to do specifically in response to the orientation 
being changed.

Allowing resizeStack to be the common trigger for layout adjustment 
keeps things simple, learnable, and predictable.

If that were not the case, then doing ordinary layout tasks would become 
more complicated than necessary, reducing the value of using LC.


 > 5) But, major caveat, returning for "face up" or to "unknown" has the
 > consequence of swapping the x,y values.

If that's by design it would seem a poor choice, given how consistently 
the language provides x before y.

If that's not a design decision it would be a bug.


 > 6) But... an android  a case where
 >
 > card rect
 > 0,0,360,649
 >
 > Screen rect
 > 0,0,360,672
 > # 24 point too long!
 >
 > And, I turn the phone form  landscape to portrait, my footer is 24
 > pixels below screen.

Using card width and card height is always better for adjusting interior 
controls than using screenRect, on all platforms, mobile and desktop.


-- 
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  Ambassador at FourthWorld.com                http://www.FourthWorld.com