64-bit version of CTL3D32.DLL? - windows

I've been tasked with producing a 64-bit version of an old-style Win32 Windows application, written in C/C++ and packaged as a DLL. The 64-bit app now runs but the controls in the dialog boxes don't look the same on Win64 as Win32. The reason is that the program performs a LoadLibrary("ctl3d32.dll") and if successful, GetProcAddress() is used to collect library entry points like Ctl3dSubclassCtl(), and those entry points are then used to subclass each class of control.
However, the LoadLibrary() fails in _WIN64 because there is no 64-bit version of this DLL. This causes the controls to be rendered using the default (this is on Windows 10 -- top is Win32, bottom is Win64):
Button controls look similar enough to pass, but static controls that are used like group boxes (they look like raised pads) are drawn as plain white rectangles and edit windows don't have that inset look.
I know the right way to do this is to move the app to visual styles but for right now, it needs to look the same in Win64 and Win32. I searched in vain for a style or flag that might turn on this behavior without referencing CTL3D32.DLL.
Has anyone else encountered this problem and come up with a solution other than replicating this functionality in 64-bit GDI code or moving to Visual Styles?

Related

GetWindowRect on Windows 10 is too big [duplicate]

I'm trying to position my form precisely above the taskbar. Unfortunately my efforts are hampered by the fact that this.Height on my form returns a value which is 10 pixels smaller than the actual form (with all the borders, title bar, etc). I'm running Windows 7 with Aero. When Aero is turned off (and the borders are thinner), all works as expected. The form border style is FixedSingle. I don't want to implement Aero-specific hacks. What can I do to get the correct height?
Yes, Aero lies about the window size returned by GetWindowRect(). It is a rather important appcompat hack, without it far too many programs would have a client area that's too small. Unfortunately there's neither an API call nor a manifest entry that can be used to turn off the lie. The only way is to set the Windows version in the EXE header and mark it Vista compatible.
You can do so with Editbin.exe in a postbuild event:
set pathsave=%path%
set path=$(devenvdir);$(devenvdir)..\..\vc\bin
editbin.exe /subsystem:windows,6.0 "$(targetfilename)"
set path=%pathsave%
Beware that your program will not run in XP anymore after this.
UPDATE: this is now done by default in VS2012 and up when you target .NET 4.5

Why does a Lazarus form look 'incorrectly different' on Windows

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"

Can the docking components in the JEDI Visual Component Library be used to help program 10 scrolling text windows

I would like add 10 dockable windows to a Delphi XE2 application. Each window will display lines of text received from a network of external sensors, with a different window for each sensor.
Information on these pages and elsewhere indicates that the JEDI Visual Component Library may have some nice components to help with this.
Specifically, I found this documentation:
Jv Docking
Docking Server and DockingStyle components. Docking looks identical to standard delphi docking (no docking indicators while dragging), only the captions of the docked windows are changed according to the styles.
Does the JEDI Visual Component Library have components that could ease the job of programming 10 dockable scrolling text windows?
The JvDocking controls allow easy docking of windows; those windows can contain anything you'd like them to, including Delphi's standard TScrollBox. The JVCL has some scrollable panels as well.
If you have questions about what's in the JVCL library, the best thing to do is download it and look at the files it contains. You can do that without installing it if you download the manual installation (zip) file.
Note that the main problem with the JEDI libraries are that they lack documentation for most components (or functions, in the JEDI code library), so you'll need to be good at reading component and (limited) demo source files. There are also a lot of components included, including many that duplicate functionality; it's often hard to find the minor differences between them, and many come with no documentation or demo.

Making a vb.net application blend in with the Windows theme

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.

COMCTL Common Controls Progressbar displays ugly blue bars

I have a VB6 program which uses comctrl32.ocx to display a progress bar. I've also had programs using mscomctl.ocx. However, it is displaying it using the ugly, old-style blue boxes progress bar instead of using the new-style progressbar (which presumably varies depending on the OS). Other programs which reference that same ocx file display the new-style progressbar (unless I run them VB6, in which case they still use the ugly one). All of the properties of the control are the same. Any suggestions on what I'm doing wrong?
Most likely, your application doesn't have a manifest and therefore uses the old pre-Windows XP style common controls. vbAccelerator has a great article on how to add one

Resources