Control positioning %bt vs %tt

I am getting some odd behavior within a %ob using %tt versus %bt.

In this image, the %tt is associated with the %ls (Quad) and the %bt is associated with a %rd (Log ID) https://www.dropbox.com/s/3hqlhvl274qh80x/dialog_image1.png?dl=0. I have another test case where the Log ID %rd control when used with %tt shifts the %rd down, clipping the border on the %rd.

This was an unexpected behavior, based on the description in the help file.

The down shift could be caused by white-space characters in the format string. If not then you could use %dy (for example) to make a local adjustment.

Bill,

I think I'd reinforce Paul's comments. Each format code generated entity has its own vertical spacing, and that's why there are various forms of %dy. %dy does have issues, and one of them is that it depends on the system font, so may be different with different Windows versions, and/or a user-configured setup. %ap is also available, as is %rp..

There's also another issue, and that is of using command buttons inside a dialog. Take for example 'Add New Quadrangle'. This is implied by the drop down list that the user must select one that is presented to them. It's not really the right approach to combine it with a list, as in 'Add unlisted quadrangle'

Certainly, %bt has a different vertical height compared to %tt. %tt is more in line with button heights in new versions of Windows, and it also changes width in multi-character steps unlike %bt which scales by average width characters. %tt wasn't originally intended as a replacement %bt (I think), and its name, 'textual toolbar' gives that away. It's a bit of a mistake to mix %tt and %bt anyway, and also not to mix with %bb - not for any other reason than the different heights.

I think I'd make both buttons in your example plain text, and even perhaps supplement them with pop-up balloon help, and finally combine them with an action button 'Select' and a 'Discard' fallback. It should be obvious to a user that all data input boxes need to be complete, especially in a small dialog, and you may need to make this clear. For example, you have a caption, or more explanatory text, or balloon help, or even greying out the 'Select' button until all selections are made.

I think I'd also beware of scales. I had to update a program for student surveyors where the scale was selectable. One student chose 1:1 before attempting to print an area of 2 square km. Quite a lot of paper was ejected from the printer before we resolved the issue. Fortunately, most of it was blank and could be reused! This is where you probably want the 'Scale 1:' to precede the single input box. A drop-down list is good, because it can include 'Fit to page', whereas a number typed in needs %il. You make it obvious that data has to be entered by selecting something as the initial value.

Then, assuming 'State' means US state, you could start with AZ. The Z makes the state name more obvious than, say, AL. Then, you could save the last used state abbreviation in an INI file, so that this is the default presented to the user the next time they use the app. Those two-letter abbreviations will be obvious to a US user, but wouldn't, necessarily, be to me - for example, KY doesn't immediately make me think of Kentucky!

There are also techniques to make the vertical alignment not so much of an issue. One is to use visible boxes much more sparingly, and to give them captions. It makes the dialogs larger, but that is a side issue.

%bx is also handy, because with it you can divide any dialog into two rather different areas, with one containing the inputs, the other containing help info and/or the action buttons.

In the end, however, you have to make do with what Clearwin+ gives you.

Hope this is of some use.

Eddie

Eddie, I appreciate your comments. Some of them are not based on the reality of the product. That said, there is value in here.

Specifically, the text 'Add Unlisted Quadrangle'. Interesting choice of words. More on that later.

This example asks for the user to select one of the map identifiers that they have already used. Add Unlisted Quadrangle allows them to add a new definition at that specific time. Then they select the new one from the pull-down list.

Scale refers to a map scale. In the USA, the basic standard (US Geological Survey) most widely used is 1:24000, AKA the 7.5' quadrangle. Other standard sizes from the USGS are 1:62500 and 1:125000. I allow an option '9' in the case of a user who has their own map (i.e. company map), and at a non-standard scaling. I provide the entire listing (54,026 of them at 1:24000 scale) for the US (including all territories) as part of the software. There is a different selection dialog for selecting from that list.

So, the State names are US standard abbreviations as well.

That said, while the software asks for State and Quadrangle, the user could put 'XX' for the state and 'JOES BAR' for the quadrangle. The software really doesn't care. For US users, it makes sense to use standard state and quadrangle names. For foreign users (of which there are not currently any) or a US user who just wants to get crazy, they can do whatever they'd like.

I have bypassed the button size/shift issue by using %ob and separating the various controls into their respective spaces in a different visual manner. The buttons are all %bt and in their own box separated from the rest. It works visually.

I'm not going to tweak controls using %dy. Since I cannot verify its effect on the end-user display, it is too risky.

What has really been awesome (thanks again, Paul) is using %ud for the %ls (and other) controls. With this feature, I am able to create callbacks that don't require specific references to common blocks. I use TYPE's, and access the data directly from the TYPE. In this way, I have been able to separate the code from the physical data. This layer of abstraction will allow me to use any variable names I wish when I create the dialog without having to debug or maintain separate code for different usages.

So, thanks again for your comments! Bill

Hi Bill,

The comments are always intended to be helpfu - or if not, then at least to be thought provoking!

I have an issue over here with authors of papers being Britocentric. For example, they mention a road number - say A605 - and I would know what sort of a road it was (probably) and where it was in the country. Very few people out of the remaining X billions would know that. Other countries have their own foibles.

As far as scales go, we Brits traditionally had 1:63360 (one inch per mile), 1:10560 (6 inches to a mile) and so on. It makes using old maps difficult, as the newer issues have been metricated properly to 1:50000 and 1:10000. The problem is compounded by the combination of units, as in still keeping 50 ft contours but labelling them in metres!

Can I recomment using %bb buttons with an icon? Then you can match those icons with what appears on toolbars (if there is a match).

Eddie

Eddie, again, thanks for the suggestions. Once I get all the changes incorporated, I'll go back and look at using icons.

As to map scales and oddities thereof, we're visiting friends, one of whom is an engineer originally from near London, with whom I can commiserate about arcane scales! He loves this kind of stuff! He spent time in Africa and India, so I'm sure scales and conventions gets weirder and weirder.

Speaking of weird, the maps that I reference were (originally) produced using the Clark 1866 spheroid. In the USA, this equates to the coordinate system NAD27 (for North American Datum of 1927). The newest coordinate system is NAD83 (for 1983) with periodic revisions, but is equivalent (for practical purposes) to WGS84, the coordinate system used by your GPS and Google Earth. If you just have coordinates and don't know the coordinate system to which they are referenced, you can make big mistakes. One of my customers did just that, using the NAD27 coordinates, yet drilling the hole using GPS coordinates as a reference. He was about 30 meters off. This was an expensive error!

So, as always, the trick is to figure the units (and to read the documentation thoroughly)...... As a result of his faux pas, I have implemented a coordinate conversion system that uses proj.4, a coordinate conversion system written in 'C' that links as a DLL compiled with MINGW into my FTN95 code to provide coordinate conversions for my customers in any combination of systems they wish (i.e. enter as WGS84, but display as NAD27).

I mention this because things are constantly evolving, and we all struggle to keep up sometimes. Having a place like this forum to discuss problems, solutions, and 'what if's' is exceptionally beneficial to me, and I hope to others.

Bill