I create my programs on Ubuntu 12.04 and compile them on Windows (when necessary).
Recently I noticed that my Lazarus projects look different on Ubuntu and Windows. The problem is on Windows XP, 7 and 8. I'm not sure if Vista looks the same.
For example, group boxes containing radio buttons look shrunk in height, thus hiding parts of the components.
Now I have to edit this forms on Windows before compiling for those platforms. What's worse is that when I bring these project back to Ubuntu, the forms looks unnecessarily stretched out (in height).
Is there a solution to this?
Thanks!
It is easily to check if the controls themselves have the same height(just query their left and top properties and dump it in a memo or log for verification)
If that is ok, it is probably the font. Default fonts are subject to themes, and sometimes readability/disability settings.
Consistent cross-platform look is not a trivial task and does not come at no-cost.
Read http://wiki.freepascal.org/Autosize_/_Layout, especially the part that can scale controls on your form depending on the font size that the end user has configured in the Control Panels
Read few chapters from Google: "windows dpi aware applications"
Related
Image of example software here
Is there a particular name by which this style is known in UI design circles?
Your screenshot looks more like XP/Vista.
I don't know if it had a specific name at the time, it was just how most 32-bit applications looked. All common controls and common dialogs had this look and any custom controls using GetSysColor would mimic it.
Going even further back, in 16-bit Windows version 1 and 2 were flat and in version 3 this "3D" look started to take over. The dialog box API for example gained the DS_3DLOOK flag. See this blog post for more.
These days the Windows 95 look without Visual Styles is often called "Windows Classic"/"Classic Theme".
I'm migrating an application from PowerBuilder 9 to PowerBuilder 12 Classic. In the course of this, I've noticed that PB now renders some of the controls differently: for example, on one window, some of the dropdown data windows are marked to render with a box around them, while others aren't -- but they all render with the box. PB12 fixes this, rendering each control as actually specified.
So, as long as I'm going through here and making things consistent, I might as well make everything consistent, as far as possible. We'll be deploying this on Windows 7 machines for the next couple of years, at least, so Aero is the theme I want to aim for, either with the PB defaults or by setting the controls to look like they should. I tried looking at the MS UX guidelines, but either I didn't find the right page, or it doesn't actually say. So, what should the controls look like? Boxes? Lowered? NoBorder?
Thanks.
Much has to do with the user theme as well as the icon size they have chosen to use on their desktops. One thing to make sure of, however, is that you do not have the 'Windows classic style' option checked on the project from which you build your executable.
I've learn how to manage different DPI settings the hard way, so that at runtime my applications are properly displayed.
But there is still a big issue with Design time Visual Studio.
Say I build an application at 96 dpi and I switch my display to 120 dpi for testing purposes.
Now IF I open a form designer at 120 dpi, the form is resized according to 125%, the controls moved aso! :-(((
So I try to avoid reopening forms, but that's NOT a nice solution, isn't it?
Is there by any chance a design time setting to prevent form to resize?
Not a solution but possibly a workaround: do not test on your computer but on a VM or other computer and do not open the solution on a computer with big fonts.
And we found that we cannot use the AutoScaleMode = Dpi.Font setting. That will randomly resize forms when we open them in the designer. Dpi or None seem to work.
Although this question is already old, I want to share my workaround.
Keep the Form’s AutoScaleMode = Font. This works fine, if you control the rest correctly.
Set in your Forms Designer: Font = MS Sans; 11px. Basically, specify your Fonts in Pixel, instead of Points. So Visual Studio won't re-scale anything if the system's DPI change.
In the Forms Ctor, after InitializeComponent, re-set: Font = SystemFonts.DefaultFont. Now, at run time, Fonts will use Point-based sizes again, and you get nice high-DPI GUI.
Enable DPI-Awareness, either through a manifest or by API function SetProcessDPIAwareness
You can find the details of my (hard) learning trail on my Blog: http://www.sgrottel.de/?p=1581&lang=en
Assume a GUI application is opened on three machines running Windows XP, Windows Vista and Windows7. In all the three machines, the screen resolution and the DPI settings are set to be the same value. Will there be a difference in the way the application is displayed on the screen in terms of number of pixels used and their position on the screen?
The reason for asking this question is:
I am using position based record-and-play method for GUI automation. Any change in the position of a control can impact the playback of the GUI recording. I want to be sure that a recording captured on Windowx XP platform works on Vista and Windows7 platforms.
Yes. The OS chrome (starting with window borders and titles) have different styles (e.g. Vista and Win7 will likely have Aero on and thus translucent title).
And that's before considering any OS dependent code in the application.
The menu bars will probably all be different sizes, so you'll probably need to record separately on all three machines.
Bearing in mind, that each user could have any number of accessibility settings on/off, any DPI setting, and also that features such as button sizes and window border sizes are different on each of these OS's...
No one here could possibly guarantee you'll be fine - the only way is to test.
A side note: there MUST be a better way than position based playback? I've used tools previously that can read screen text and base the automated navigation on that, which seems far more sensible, but still horribly flawed.
Previously I used to piddle around with VB6 to develop a couple of personal projects. Following my upgrade to Windows 7, I've decided to piddle about with vb.net Express Edition 2010.
If I wanted my VB6 application to blend in with the visual style of Windows, I would use the code and techniques described here. In short, I would use a Manifest file and a couple of calls within the application and most of the elements would look similar to the XP theme applied. If it was run on 2000, 95 or 98 then it would look like a standard Windows app. All was good.
Now I've moved onto vb.net, I've written a simple "Hello, world" application but I have absolutely no idea on how to make it look like the Windows 7 theme (eg. the font matches the system font and the widgets are styled correctly).
Just changing the font is a hack and will look out of place on machines that are set-up differently or run a different version of Windows where the default font is different.
How do I ensure my application matches the applied Windows theme irrespective of the version of Windows?
A lot of this is automatic if you create a Windows Forms app. They will (mostly) use the standard native Windows controls which draw themselves with the theme colors. But there are exceptions:
the Form item template uses a default Font named Microsoft Sans Serif. You'll have to change it to Segoe UI to match the Vista/Win7 default. This is only necessary for the Form class, all controls you put on it will automatically inherit that font. On an XP machine, the Windows font mapper will notice that the font is missing and automatically fall back to MSS.
the MenuStrip class uses custom rendering to draw the menu items. It tries to match the Windows style when you change the RenderMode property to System but the way it draws doesn't match the Win7 style. Right-click the toolbox, Choose Items and select MainMenu. That's a legacy version that does use Windows to draw menus so it produces the proper theme appearance.
A very similar problem for ToolStrip. It's legacy version is ToolBar. This is a hard one to swallow, it doesn't use a rebar which make the tool bar look flat and ugly.
There are similar problems in WPF but with the added problem that WPF doesn't use any of the standard Windows controls. And gets it wrong in subtle places.