I got LC 1 year ago for no other use than mobile. Very quickly I saw the LC light and am using it as a replacement for VB6, but I digress.
When the multiple resolutions and rotation reality hit me..... I first tried just to resize and re-position controls by a factor calculated from resizestack message (newWidth,newHeight,oldWidth,oldHeight). This of course introduced precision errors. This was very easy to see in the IDE by just grabbing a corner and changing the size of a card. This worked for a customer mobile demo with 1 resize and no rotation enabled. Then I dropped all app development and started writing a Resolution Independent Control library. If I had the LC knowledge at the time to implement a UI like the one that Chip and Ken previewed I would have done it. Very impressive guys!!!!!!! And I may be using yours in the future. But alas I went a different direction. As Bob points out below a percent type approach was what I went with. I had these requirements: 1 card per screen 1 set of images, but the ability to use multiple images if needed for exceptions. All resolutions and aspect ratios. Ability to change control layout (or not) based on screen orientation, resolution or aspect ratio Align controls with pixel precision. Easy initial layout. Not only resize the control but the text as well. Resize text by.... best fit, scaling best fit, percent of IDE size, scaling percent of IDE size. Aspect ratio locking by X or Y. Vertical centering of text. Work for both mobile and desktop Be a library stack Images are of sufficient quality to be scaled. Handle controls.... Images Single line text Fields Multi line text fields Buttons Button labels Button icons with zoom in/out Menu and tabbed controls. With the same text resizing options Groups Stamping controls in a group n across by z down Stamping of any collection of controls n across by z down It is implemented with call(s) to my library from a switch statement structure cased by card name in the preopencard and resizestack handlers in the stack script. Each call places 1 or more controls on a card. There are several calls per card as you could imagine. Calls are a bit clunky but quite fast once I got used to it. The calls have some advantages also. This makes different layouts defined by orientation/resolution/stack aspect ratios easy, just a switch statement away. A controls position/size is defined by a percent to each side of the bounding box. The rect of the bounding box is the edge of the card or the inside/outside edges of other controls. This makes putting controls inside other controls easy. Seeing that this is just a bunch of calls, the initial layout of a card is just spit balling. The actual positions won't happen until the calls are tested from the message box or by grabbing the corner of the card and changing the size and watch everything click into position. This way if you set a control to align 10% from the left, then all controls with a 10% left margin from the same edge will align perfectly. Edges have infinite length. If you have radio buttons then all the options will be spaced out evenly (or not). We all seem to be doing a lot of work for something that could have been handled in the engine. It would be nice if the mother ship could tell us physical size of the device even if it was just phone/tablet/TV. I'm happy with my solution for now. It works and I never care about new resolutions. New resolutions to me are just a..... so you don't say. I am now changing PlaceControls from calls to a custom Property Set to keep the cards layout with the card and have no coding in the stack. I can then handle the preopencard and resizestack messages from the library stack. What a year! Ralph DiMola IT Director Evergreen Information Services rdim...@evergreeninfo.net -----Original Message----- From: use-livecode-boun...@lists.runrev.com [mailto:use-livecode-boun...@lists.runrev.com] On Behalf Of Bob Sneidar Sent: Monday, July 30, 2012 1:54 PM To: How to use LiveCode Subject: Re: Preview of Resolution Independent Control library for RevMobile Seems like the whole pixel coordinate system achilles heel is showing. Better would be a percentage system, so that theoretically I can set the topleft of a control to a percentage of the hv of the card. This really should be an engine change, but I suppose a library could be developed for this purpose. I'll have to think about it. Off the top of my head, it would seem to me to be better to start with the smallest res supported as the baseline layout, then scale up. Bob On Jul 28, 2012, at 1:49 PM, Monte Goulding wrote: > For layout to play nicely with scaling it will need to place controls relative to each other and window boundaries and not include any reference to physical pixels without multiplying by a scaling factor. So if you want a field to have 3 px padding from the edge of the card you need to use 3 * scale. So I think unfortunately the layout lib would need to be dependent on the scaling lib. It could just be a single global variable though. > > Cheers > > -- > M E R Goulding > Software development services > > mergExt - There's an external for that! > > On 29/07/2012, at 5:23 AM, Thomas McGrath III <mcgra...@mac.com> wrote: > >> I agree and would go as far as saying that these must remain separate libraries.They should play well together. > > _______________________________________________ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
