Thanks for reverting the xtr'itemlines logic... this works now.

I have a hopefully not too stupid question:

In reading the release notes, is it not true that if using altpos logic, that "individual" dialogs are now resizable, independent of the ashell/ate background? I know i am an outspoken opponent on altpos, but its just because we didnt begin the extreme makeover with it... but if the resizing is true, that is extemelely cool... Even so, resizing the ATE desktop does resize the child dialogs, which for us is still very cool.

Yes and no. It is now possible to maximize an individual altpos dialog, although doing so will indirectly change the size of any other dialogs that are present at the same time. (If they are under the dialog being maximized, you'll never know the difference, because un-maximizing or closing the maximized dialog will restore the original grid.)

It is (and has been, for some time now) also possible to change the altpos grid scale and font scale under program control, using MX_WINSETTINGS (or by changing them directly on the Dialog Sizing dialog), any of which will change the size of any existing altpos-based dialogs.

However, it is not (yet) possible to resize the dialogs with the mouse, nor is is possible to have different scaling values applied to different dialogs at the same time. (Those will be left as exercises for 5.1)

If you're wondering what the excuse for this enhancement being squeezed into 5.0, it's this:

Diversified Data Solutions (Carl Staff), who is also a proponent of the 5.0 stable release concept, but who wasn't quite as ready with his new release as he thought, back when we were trying to finalize it in January, is now doing installations in the field and is running into situations where his screen layouts aren't working as well as hoped for. The fundamental problem is one that just about everyone can appreciate: trying to get too much stuff on the screen at once. It all works well at 1024x768 with small fonts, but when you get to someone with larger fonts or a lower resolution, it's a struggle to squeeze things in, using the various font and dialog sizing techniques available. So in trying to help him come up with a quick workaround to re-designing the screens (or bundling a new monitor with each PC sale), the idea of just maximizing the dialog to get the maximum available real estate seemed like one that would both work, and avoid breaking existing programs.

Naturally, like just about every minor enhancement of this type, it got more complicated than originally envisioned, but I think the result is in line with the original goals. Unfortunately, it doesn't do anything for people using the main window grid rather than the altpos (or desktop font) grid, but it doesn't take anything away either. (And for what it's worth, I convinced him to convert to the altpos grid about a week ago, so he could take advantage of the Dialog Sizing options in order to try to come up with the best possible layout for each screen environment. I think he made that change in a few hours, so it isn't necessarily an "extreme makeover".)

Anyway, unless either all the users become convinced to upgrade to higher resolution screens, or all the developers decide to change their ways and design dialogs to fit on smaller screens, I think we are going to be tinkering with these scaling/resizing capabilities for a long time to come. But I'd like to push that off to 5.1 if at all possible. For anyone just now designing a new dialog, let me repeat: try to design it to work well in a space of, say 700x500 pixels. (Use tabs, or multiple dialogs, rather than just making the dialogs bigger.) That will save you a lot of grief when installing the software in the "real world".

Thanks for imparting your wisdom on this topic.

We also have a bit of a struggle with 800x600, and our new scheduler will "barely, if at all", fit at that resolution.

But, and correct me please, wont most older crt's, lcd's, support 1024x768 at some level? Or is it that the font is too small to be usable?

At the same time, hardware is so cheap now, grabbing a new 17" flatpanel is less than $200 most everywhere...

Its a tough catch-22 i suppose... lose the sale, or make a change... :rolleyes:

As the first altpos convert , I have to thank Jack for sticking with his gospel preaching on this topic. The key thing for me was that with Altpos, scaling to fit in different screen resolutions was so much easier to keep up with, though I'm not sure I've covered all the bases yet. As usual, Jack went the extra mile to be helpful...you are amazing, Jack!

I am curious though, how others handle the screen resolution issue without altpos? Do you require your users to use a specific resolution? There are users with screens from 800x600 to 1440x900 for whom I want a reasonably large window for all programs. Without alptos, I had added scaling factor to all the various labels and inputs in my programs and then set a "best guess" for this factor based on current resolution. I was close to getting there but it was messy.

With altpos, I start with an 800x600 window and make things look perfect there. For higher resolutions, I increase the Dialog Scale Facter slightly to make better use of screen space. I also set a scale factor for XTREE headers and row fonts to let them grow somewhat with higher resolutions. I'll be the first to admit a lot of ignorance here on windows "standards" ... but I like the results with Altpos so far.

Carl, to be honest, thats what i do, w/o altpos. I assume 800x600 is ok... i use a font scale of 90 at that resolution. At 1024x768 and greater, i use a font scale of 140, and that looks pretty good. A larger 19" monitor at full resolution can handle 160 scale. It is a bit "messy" as you say, but easy enough to adjust on a user by user basis. I guess then, i still don't see the value in altpos, if you are still making manual adjustments to "tweak" the display... if that is such, i will stick with our own tweaks that seem to work for us... Good luck out there.

On "Display Properties | Settings | Advanced" is the resolution. Click on "General" and is a Dots Per Inch setting. There is also a font size (Normal, Large, Extra Large) on "Display Properties | Appearance". Could your applications get at these properties to make a best guess effort at figuring out the scale to use at a particular resolution?

Mike,

I believe that this setting is used by altpos to determine "altpos units". But I not sure how might they help in determining what scaling factor to use. I will experiment with these font settings in the next day or two and perhaps report back.

Frank,

I agree that your approach works (obviously) but with altpos, I think there are fewer places in the program were you need a scaling facter. With altpos so far , it is only XTREE fonts that needs a scaling facter (Jack has made column widths adjust somewhat with Altpos). For everything else, all I set is the diaglog scale factor before the program runs and everything scales. I'm not trying to convince you to change, just clarifying what I've found.

Have a great day!

Carl.. i fully understand... i guess i don't get the complexity of your screens, because honestly, by just changing the font scale, my screens seem to come nicely into place... Perhaps Jack could shed some light as to why your situation was more complicated... or, as i suspect.. i am just missing the entire boat here?

Mike: Indeed, Carl is correct that the altpos grid unit is a direct result of the combination of the screen resolution and font size (aka "DPI") options in the Desktop Settings, although we also apply the dialog font scale factor from the Dialog Sizing dialog.

You can query the screen dimensions and the altpos unit using XCALL AUI, AUI_WINDOW,... as illustrated in the AUIWIN sample program in [908,28]. Here's an excerpt showing the call that retrieves both of those metrics:

As an example, I typically end up with a grid unit of 27 pixels high by 13 wide on my 1400x1050 monitor with normal sized fonts. By dividing the grid height into the screen height, I can figure that I'm going to be able to comfortably fit about 32 logical rows of information (at 100% font scaling) in the largest possible dialog (allowing space for the task bar, title bars, margins, etc.) Similarly, I can figure on about 107 logical columns. Note that the relationship between a logical column and a character is a bit fuzzy with proportional-spaced fonts, but the grid unit width is half way between the "average" and "maximum" character widths, and thus is usually pretty generous, unless you use all capital letters.

What isn't well understood, is whether you can get more effective space without sacrificing readability by increasing the resolution and increasing the font DPI at the same time. I suspect that you might be able to gain a little advantage there, since for a given physical character size, more pixels (higher resolution) will probably increase readability. But unfortunately, you have to reboot to change the font DPI, so it is a major pain to experiment with.

Frank: Regarding why Carl's scaling issues may have been more complicated than yours, I'm not sure there is any one answer, or whether complexity is really the issue. Both applications are visually complex and tightly packed and unique in their own way. I'm guessing that by luck or skill or good karma, you were able to get everything to fit at 800x600 without going below 90% font scaling, whereas, for whatever reason, Carl needed to go closer to 80%, at which point the fonts just become unreadable. (Probably because he wasn't starting from a 24x80 model, like you were, and because he did his initial design on a larger screen.)

In suggesting the switch to altpos for Carl, I was thinking mainly of the following advantages:

1) The altpos system is more self-adjusting, in the sense that changes to the desktop settings (as Mike referred to) are automatically taken into account. With the window-based grid system, the fonts will get bigger or smaller, but your grid will not adjust. (On the other hand, if you're already using every available pixel on the screen, it may be a moot point since neither option -- having the dialog larger than the screen, or having the characters and controls within the dialog overlapping each other -- is accceptable.)

2) The altpos scheme offers an additional scaling option, in which you can independently scale the horizontal and vertical dimensions, and both of them independent of the font size. This is what allowed us to maximize the dialog. (A-Shell just recomputes the horizontal and vertical grid scale factors to spread the controls out accordingly.) In the window-based grid system, you can do something similar, by changing the number of rows and columns that the main window is divided into, or by resizing the main window. But resizing the main window with the mouse is not easy when your dialog already covers much or all of the screen. Note that merely changing the font scale factor changes the horizontal and vertical scale at the same time, so you might end up in situations where you can't use all of the screen real estate because one dimension would over-extend the monitor. Also note that the granularity (or precision) of font scaling is not very good, since we are rounding the grid unit to the nearest integer pixels. But the altpos dialog horizontal and vertical scale factors are more precise because they aren't tied to the font and thus can be applied to overall control size. (Rounding the control or dialog to the nearest pixel is better than rounding the cell grid units to the nearest pixel.)

But, as you say, the advantages are not so overwhelming that it necessarily makes sense to switch, particularly once you have your app working the way you want it.

I submit that we need another ashell GUI conference, this time in Portugal!

Thanks, Jack for the reply... and Carl... i'm right behind you... (now, just to get the boss to foot the bill... )

Welcome to the world of altpos Carl. I switched to it before the conference and afterwards Jack added a few more scaling and adjustments that helped alot, though we have not deployed to a customer yet, we have been testing/developing on many different PC/Monitor combinations. I very much like altpos.

Again if you are not using the Ashell Editor, you need to jump on it, it is absolutely great.

Now for that conference in Portugal, let's go.

You all have a nice evening.