xsharp.eu

Hi Joe,
unfortunately I'm away this weekend and have no development notebook with me.
I will look at this on Sunday evening or Monday when I'm back.
What I can say: WPF is entirely vector graphics based and therefore WPF applications can be scaled without loss of quality (excluding some bitmap grahics when they are included).
Wolfgang

Thank you, Terry and Wolfgang.
I need to solve this "tiny text" problem but fortunately the VO app is largely the same as X#. Less than an hour to convert it and make all the necessary changes in XIDE. So I will go through the VO applications and make everything larger. Change the 8-point text to at least 10 or even 12 where possible. Enlarge all the windows. Use a minimum window size of 1080 x 720 instead of 800 x 600, which is the current default.
This will take probably a week. (Might only be a couple of days.) At least then I've met, at least temporarily, the requests (dare I say complaints) of users with high-resolution monitors.
Then I'll tackle WPF, which obviously is where this should go. Call me crazy but I think the code from the constructor methods of the GUIs can be converted to XAML. (At least that was my thinking when I started reading about WPF/XAML.)
Terry: moving from DBF to SQL (ADO) isn't so hard. Think about it:
Every "while !oServer:Eof"
becomes
"while rdr:read()"
Resolving the loop logic is 80 percent of it, at least in my experience.
Thanks for the help and advice. When this is done, I'm hoping to publish a some sort of how-to for all those DBF people out there who know they need to switch but just can't seem to pull the trigger.

Hi Joe,
I have now looked at my sample.
It has font sizes hard coded in the source code, but with WPFs databinding it is really easy to make that configurable with an input control in the GUI (and of course these sizes can be read from any configuration file).
You can look at the source code in BrowseForm.prg file and see the hard coded sizes: Wolfgang
P.S. a transformation from DBF to SQL may seem easy, but only as long as you have small database sizes and it is no problem to keep the entire table in memory. With a DBF, you have only the current record in memory, whereas SQL keeps the entire select result in memory.

Hi Joe,
I have now added a bit of databinding to my sample: Please try to play a bit with it changing the values of the size textbox.
And here is the XIDE export file: Wolfgang

Thank you, Wolfgang. If I see a way forward here, it would be to calculate variables such as font and grid sizes on the basis of screen resolution. Similar to what is done in CSS. That doesn't readily help with actual screen coordinates in complex data windows but I can see a say of calculating coordinates in simpler windows.

Not exactly "vector based" but it does go a long way toward solving the high-screen-resolution problem.

Joe,

Forgive my ignorance, but why don't you "simply" tell your customers to change the scaling on the display settings ?
Or change the font size in the "Accessibility settings" ?
Is that not enough ?

Robert

Hi Joe,
how shoud the program understand if your customer is using 1920x1080 on a 17" screen (and needing small characters) or using 1920x1080 on a 10" screen (and needing large characters)?
All what you can do (and what Robert also wrote) to be confident that your customers are setting the right font size for their monitor size (normal = 100%, large = 150%, or even 200%).
If you are using VO application and your users are using larger fonts than normal, your windows may be distorted if you are using "pixel positions" on "yes".
CSS works a bit differently because the browsers often transmit the device type, but even this does not works always.
Windows does not transmits the screen size, only the resolution.
Wolfgang

Robert: No one's ignorant here. (Except perhaps me.)

Wolfgang: As long as you can get the screen resolution, then you can get along without the exact size. Just assume 16:9 or 4:3. Then at least you can determine the likely most readable dimensions for grids. Windows are harder, obviously, because they involve screen coordinates. (I'm already doing something like this in one of my apps.)

Here's the problem: many of my users have laptops with vertical resolutions of 1440 pixels or more. (2500 or more horizontally). Which makes pixel-based windows too small and therefore difficult to read. In my case I've found that the problem is mitigated by changing to 12-point the default fonts of SLEs and textboxes. This will at least keep me in business with these users until I can complete a "vector-based" solution.

With all due respect, changing Windows settings is out of the question.

Take my word for it, based on three decades of end-user support: Change their settings and then all of a sudden you will own their desktops and any subsequent problems ("Everything worked until you made me make that change.") Plus there's the problem of users in large organizations where Windows changes are blocked by group policy.

So it's either a vector-based solution or something in between.

I'm beginning to think that to reach the widest possible customer base the proper solution would be to develop both windows- and browser-based GUI solutions for the same app.

Hi Joe,

Since the users do not want to change the window settings for font size, then if they are not comfortable with the size of the menus in your app, don't they have same problem in (almost) all other apps as well? What do they do about them?

Chris,
The major accounting applications and MS Office seem to have solved this problem. So that would account for a majority of software that users have installed on their PCs and Macs.
Other than that, I'd have to say that most are logging into web apps. Most of my competitors are on the web.
I'm now seeing users discard their PCs altogether and doing everything from an iPad. They log into remote desktop to use our app.