I have a droplet app where I reposition and resize text fields, checkboxes, etc. based on the contents of the file dropped onto it. (I’m moving and resizing because I’ve been asked to display only the controls necessary for what the input needs and to use all the rest of the area to fit as large a text field as possible.)
Since I don’t know the contents until after the “awake from nib” handler is completed, I have to do the rearranging in a subsequent handler before making the main window visible. This works okay, unless it runs on a machine whose screen is set to a different resolution, in which case everything is whacked out.
I don’t understand the way Xcode apps are expected to adapt to different screen resolutions when control positions are based on window coordinates. Am I correct in assuming that I have to take into account relative screen res when I shift dozens of controls around the window? (I hope not because that’s what I’m trying to do now unsuccessfully.) Or is there some way scale this all at once? Or some other way to accurately and dynamically set up a window that handles any screen res? Is the fact that I’m repositioning stuff after “awake from nib” a problem?
How else would you do it? If you can propose a better way to control layout of objects in a window I’d be interested to see what that was.
Without any idea of what code you’re using, this doesn’t make any sense to me, because view position is set in a pixel-based, 0-index coordinate system. It shouldn’t make any difference what resolution you’re on. The coordiniate system starts at (0,0) and draws outward from that… I don’t understand where the complexity begins. Perhaps if you post your code, so we can have even a remote idea of a) what exactly your trying to do, and b) what method you’re using, we could give you some advice. Just from my own experience, I don’t see any reason why you shouldn’t be able to set sizes of controls and then have them be rendered properly regardless of the screen res. The only conflict I can see is perhaps in what happens when the size of the window becomes smaller than the minimum size required to fit the controls in the window. If this is the case, you’ll have to establish that minimum size, and then restrict the window from shrinking beneath it.
The trick to programmatically controlling view frames is to make sure you cover all of your bases. Individually setting and configuring “dozens of controls” sounds complicated. While it of course can be done, the amount of different configurations and the complexity of the repositioning can make things significantly difficult.
There are a variety of solutions I can recommend, some or all of which may or may not work in your application.
Consider redesigning the interface. While necessity breeds innovation, apple has nonetheless provided you with most of the controls you would need to handle 95% of situations. Consider instead using tab views, popup menus, or maybe an editable table view to provide a lot of options in predefined layouts or data sources. If you only have a half dozen different primary configurations, laying out those in separate tabs or subviews and then toggling the whole group would be preferred to individually configuring individual controls.
Reuse. Rather than having one big window with a hundred individual controls that you toggle on and off, consider making only the fewest possible number of controls and then setting their titles and toggling disabled/hidden ones out of use when not needed.
If you must move around lots of controls programmatically, try to minimize the amount of objects and code you’ll need to get the job done. Along with reusing objects as much as possible, try to create portable code that you can program a simple record list into that handles the whole event in one subroutine call. This gets tricky, and will require a LOT of time and effort.
Consider, too, that users value consistency. While whomever is in charge of your project ultimately dictates what the thing should look like, it is often better for the sake of consistency to simply disable a control rather than remove it from the screen and rearrange everything around the hole it’s absence left. You’ve got my curiosity up, so I’d be happy to help you out on this. I’m a GUI neurotic, so if you’d be open to sending me a copy I’d like to take a look and offer my input.
Can’t thank you enough for that well-considered response.
I think what got me going on this was that I’d never before had anyone come back to me saying that it’s whacked out (should have been more specific - controls were scattered or overlapping) and also I’d never before had a project where I had to examine the dropped XML file before moving things around according to that, and hence doing the rearranging after “awake from nib”. So putting 2 and 2 together I figured the latter was causing the former.
I am simplifying things a little by combining what I can into custom views and moving them en masse, and then hiding those controls I don’t want to use. I think to some small degree I’ve already heeded your suggestions (maybe not so much number 2). I’ll e-mail you separately a .jpg of the window plus comments just for your interest - I’m not expecting you to devote any time to it, just wanted you to see what I’m talking about.
Incidentally, this is one of those projects where a small group of people - half a dozen or so - asked for a simple straightforward app, then without my knowledge it’s spread around the department and is now being used in India by a few dozen outsourcers, and suddenly it’s “why can’t it do this?” and “please make the comments field big as big as possible so we can print these things” and so on.
I think your initial comments have convinced me that I’m on the one and only track that will get me there so I’ll keeping slogging in that direction.