Position control

[chelling]

I am trying to position a button in the upper left screen. This works on the desktop, but no the iPhone simulator. What am I missing? Thanks

put the item 1 of the screenRect into theTop
put the item 2 of the screenRect into theLeft
set the top of button "goBackBtn" to (14 + theTop)
set the left of button "goBackBtn" to (14 + theLeft)

[FourthWorld]

What is the name of the handler that's in?

[chelling]

preOpenCard

This is the stack script

on openStack
if the environment is "mobile" then
set the fullscreenmode of this stack to "showAll"
iphoneUseDeviceResolution true, true
set the acceleratedrendering of me to true 
end if
end openStack

[LiveCode_Panos]

Hi chelling,

Is the problem still present if you swap the code of preopenstack and openstack?

Code: Select all

on preopenstack
  if the environment is "mobile" then 
    set the fullscreenmode of this stack to "showAll"
    iphoneUseDeviceResolution true, true
    set the acceleratedrendering of me to true 
  end if
end preopenstack

Code: Select all

on openstack
  put the item 1 of the screenRect into theTop
  put the item 2 of the screenRect into theLeft
  set the top of button "goBackBtn" to (14 + theTop)
  set the left of button "goBackBtn" to (14 + theLeft)
end openstack

Best,
Panos
--

[FourthWorld]

I see you're both placing your objects at specific coordinates, and also using the fullscreenMode property. Generally speaking, the two options are incompatible, given what fullScreenMode does.

Since fullscreenMode is designed for very specialized types of apps and is neither needed or desirable for many, perhaps you could comment out that line and see if it stop interfering with your manual object placement.

[chelling]

Adding it to the preOpenStack or openStack handlers had no effect. It was the "ShowAll" fullscreenmode. As expected, the card was clipped. What is a better way to position these buttons? I should also add that I tried to position using the Geometry Manager, but that was unsuccessful as well.

[FourthWorld]

It was the "ShowAll" fullscreenmode. As expected, the card was clipped. What is a better way to position these buttons?

Just don't use fullScreenMode and then it won't be able to muck with your positioning code.

[jacque]

Since fullscreenMode is designed for very specialized types of apps and is neither needed or desirable for many

I'd reverse that for mobile apps, I find that fullscreenmode is nearly mandatory for Android apps. IOS is a bit easier without it, since there are fewer sizes to worry about, but if you want cross platform apps with a single code base then you end up using it anyway.

@chelling: what exactly didn't work? How did it fail?

Note that the items in your calculation are reversed, the left is always the first item, but since the screenrect always begins with 0,0 it doesn't matter in this case.

LC doesn't always redraw objects outside the card rect, depending on several different factors, but if the side edges are clipped then that won't matter either.

If you can get by without fullscreenmode then do that, otherwise explain what you see and there's likely a way around it.

[chelling]

It's an iPad app for children, one main stack and three substacks. I want to make it universal, and believe it or not the ShowAll property does pretty well with scaling to the iPhone dimensions. Each screen has a single navigation button that is positioned in the upper left corner of the card. It loses the positioning (imagine moving a good ruler inch to the right). It doesn't look right. I do have a background image that is 1500 × 768 to accommodate the black borders from scaling. Can that be a factor?

[jacque]

It sounds like the problem could be that you've turned on iphoneUseDeviceResolution. When fullscreenmode is on, everything is scaled. If you specify you want your position calculations to be by exact pixels rather than scaled pixels, you won't get scaled adjustments. Don't set that property, and you probably won't need to set the location of the button either since it's location will scale along with the rest of the card.

I have often used a background image to allow for the black borders, so that shouldn't be a problem. Whenever possible though, I set the backcolor of the stack to a compatible color and that is drawn instead of the default black. It's an easy way to account for the clipping, if your app design is compatible with a colored border. Note that LC will only redraw the actual card area when changing cards, so you have to handle that separately (there's a trick) but it's easier if the same color just works everywhere.

[FourthWorld]

Since fullscreenMode is designed for very specialized types of apps and is neither needed or desirable for many

I'd reverse that for mobile apps, I find that fullscreenmode is nearly mandatory for Android apps. IOS is a bit easier without it, since there are fewer sizes to worry about, but if you want cross platform apps with a single code base then you end up using it anyway.

FullScreenMode scales, and if scaling is what you need it's a good fit.

Other layouts may not lend themselves to scaling.

Monument Valley is a great app that depends on a fixed ratio, so scaling is a great solution. One fixed layout on all devices.

On the other hand, apps like GMail, Evernote, Facebook, LinkedIn, etc. wouldn't look so good if designed for a 4" phone with a 9x16 ratio and then merely scaled up to fill a 10" tablet at 3x4. Depending on the mode, you'd either have buttons four times actual size, or a small layout in the middle of the screen with the rest empty. And the difference in ratios would require either blank edges, cropped content, or distortion, depending on the fullScreenMode option chosen.

Writing a resize stack handler lets us decide how to make optimal use of every pixel available to us in a single layout, just as web developers do with responsive design.

My test pool has only 8 devices, but they cover a wide range of OS versions, screen sizes, pixel densities, and ratios. LC does a wonderful job of adapting for the density of each device and accurately reporting the card rect. With that rect I can script layouts that shift things as needed. And when I lay the devices side by side I've been delighted at how consistently LC renders them, quite on par with OS controls and just about everything else.

Both options have a place, responsive UIs and automated scaling. I think it's useful that both options are available, and to encourage developers to consider the strengths and weaknesses of each for the specific design they want to implement.

[jacque]

Both options have a place, responsive UIs and automated scaling. I think it's useful that both options are available, and to encourage developers to consider the strengths and weaknesses of each for the specific design they want to implement.

I agree, but if the app has lots of controls then it is much easier to let the engine do it and develop with the knowledge that you need to accomodate for the mode you'll use. It took me days to write the resizeStack handlers for one project with many cards and hundreds of objects. I swore I'd never do that again. When I was done it worked very well but it was a depleting experience I don't want to repeat. I haven't seen any change in responsiveness when using fullscreenMode, just a considerable time savings during development.

So yes, it's good we have a choice but I do have a strong preference for the easy way out.

Edit: BTW, if a stack or card had only a few objects, I would use the resizeStack method. It's the monster projects I won't handle manually.

[chelling]

I am pretty sure iphoneUseDeviceResolution is true, so I will check that. Do you know of any sample stacks that demonstration the resizeStack method? Thanks everyone for your help with this.

[FourthWorld]

Your script above seems a good starting point. The resizeStack message is sent whenever a stack size changes. On the desktop that's in response to the user action of resizing the stack window. On mobile it's when the stack first opens, and whenever the orientation changes.

[chelling]

I still cannot get the navigation button to position to the upper left of the screen.

The stack size for development is 1024 X 768.

This is the fullscreenmode handler in the stack script:
on preOpenStack
if the environment is "mobile" then
set the fullscreenmode of me to "showAll"
end if
end preOpenStack

I placed the navigation button to 850,100 (to test the positioning)

Using Test Target iPhone Simulator 10.2, this happens:

Card rect returns 0,0,1024,768
Screen rect returns 0,0,568,329
Button loc before moving remains 850, 100
If I move the button based on the card rect or screen rect, the top is 14 and the left is 106 using either of these scripts:

on mouseUp
put item 1 of the rect of this card into theLeft
put item 2 of the rect of this card into theTop
put (theLeft + 14) into newLeft
put (theTop + 14) into newTop
set the left of card button "TestButton" to newLeft
set the top of card button "TestButton" to newTop
end mouseUp

on mouseUp
put item 1 of the ScreenRect into theLeft
put item 2 of the ScreenRect into theTop
put (theLeft + 14) into newLeft
put (theTop + 14) into newTop
set the left of card button "TestButton" to newLeft
set the top of card button "TestButton" to newTop
end mouseUp

The button is positioned as expected in LiveCode. I think I am missing something with the fullscreenmode. Why doesn't it just reposition based on the screen size?