>Hi,
>
>>>
>Why not? Overhead is lower - no SCX corruption - faster development times. Direct connect from brain to code. No property sheet ballets.
>>>
>
>How do you handle sizing/positioning of objects on a form ?
>Regards,
>Viv
Short answer - repetition!:-)

I did a lot work (really - a bunch of it) with text based dos/unix platforms. To save time and cut back on "experiment" time related to screen format, I developed a set of standardized coding procedures.

Those standards were extended to GUI development as my career moved that way. I also read articles about the "psychology" of screen/form design.

Some of the reading was helpful. Did you know that (according to screen design experts) that a work area on on the upper left side of a screen subconsciously pressures users to stay focused on the task at hand, while a "central" screen I/O area emphasizes a relaxed state.

Screen/control Symatries, after so manyyears, have become second nature. The relation of controls to each other and the for can be standardized.

For example, my textboxes are 20 pixels in height. The distance from the top of a textbox is two pixels below the bottom of the one above it. The first row of controls is begins at line 30 of a form, to make room for a 26 pixel (height) tool bar container. And so on.

In short, before I even begin coding the form layout, I pretty much know where everything will go. Sometimes I do dry layouts on paper, or a scratch form.

Another example - navigator classes are wlways on the left, command buttons tend towards the lower right screen. In the end - it is hoped - a combination of specificity, symetry and simplicity will make the software appealing to the buyer and second nature to the user.