Windows 10 Theming for forms in a dll

[danlehmann]

Hi!

I built a Lazarus dll that has a bunch of forms. It exposes a C interface and is in turn used by a main application that is itself written in MSVC.

Things work well, except I have not been able to set a modern look and feel on my forms. TSpeedButton for example looks pretty ancient.

My main application itself has some UI as well and it itself looks modern.

Side-note: Going to system settings and changing the screen scaling several times (while the app is running) eventually fixes it. I guess that triggers some sort of Settings-changed event that maybe can be invoked manually at startup?

I'd be super grateful for any pointers. I can also make a minimal repro, but it does involve both a Lazarus dll and a MSVC main binary, so I was hoping to avoid doing that. Maybe this is a well-known issue after all (though I couldn't find anything in the forums).

Any help is appreciated!

[danlehmann]

Oh one more thing: I toggled Project Options / manifest, but I think this setting only affects applications, not libraries. In any case, it didn't make any difference.

[jamie]

You are going to find It very troubling getting LCL controls to work smoothly in a DLL..

I am currently poking around with subclassing (SuperClassing) controls not registering in a DLL if they are already registered in the Host app

This isn't for me cause I really thing it's a bad idea.. One should use raw windows classes and controls if they want something like that in a DLL and keep it to a min.

[danlehmann]

Thanks for the feedback. Though from experience apart from theming (ok and screen scaling, but I'm hoping that's the same issue underneath) things work pretty well with my codebase.

It's a lot of code I wrote ages ago in Delphi and I've been very impressed with ow Lazarus is breathing new life into it and how I'm able to modernize it now So I'm willing to do a workaround here or there, given how much works out of the box with Lazarus.

[danlehmann]

Found a workaround:

After Application.Initialize, I added the following line:

Code: Pascal  [Select][+][-]

1. WidgetSet.ThemeServices.UpdateThemes;

Now things are pretty.

[jamie]

Well I am glad you found a work around, I am sure others will appreciate your efforts .

you may want to experiment a bit using controls in your DLL that also exist in the Host app using the same controls and see what effects you find..
 
 You may see issues with some events not firing in one where they work in the other.

[danlehmann]

Thanks, will keep that in mind! Though isn't that more of an issue if the host app is Lazarus as well?

Also FYI, the scaling issue I mentioned was easily fixed through

Code: Pascal  [Select][+][-]

1. Application.Scaled := True;

The Delphi import didn't add that line automatically.

So with this, things are working really well. I was even able to remove some ugly Delphi focus hacks that were needed back in the days

[jamie]

Curious where you are getting the "widgetSet" property ?

I had to include the Themes and use the ThemesService.UpdateThemes;

IS that what you did somewhere else in the unit ?

In any case, I notice I don't even have to do that. It seems the themes are working well without any twitting around ?

[danlehmann]

I am getting WidgetSet from InterfaceBase.

Also, I do see the issue you prepared me for: Certain controls cause trouble. For example putting a TCheckListBox on a form causes an access violation when the form is brought up. But it seems that as long as you stay away from those, you are in the clear. I used a multi-select ListBox as a replacement - a little less pretty but it will do.

[danlehmann]

Oh and on another note: I ported this all to macOS and things work very well there as well, which is quite a nice surprise. So now I have cross-platform UI code, nicely wrapped in a dll/dylib.

[jamie]

I am getting WidgetSet from InterfaceBase.

Also, I do see the issue you prepared me for: Certain controls cause trouble. For example putting a TCheckListBox on a form causes an access violation when the form is brought up. But it seems that as long as you stay away from those, you are in the clear. I used a multi-select ListBox as a replacement - a little less pretty but it will do.

 The issue you are seeing might be fixed now, that is, if you are using the TRUNK IDE 2.1SNV

 There are three super classes, LCLCOmboBox, LCLCheckListBox and I can't remember the third now, but the problem was that if your main app happen to also have these same controls initiated the ones in the DLL would send some of its messages to your host app window procedure instead of the Window procedure in the DLL. Of course things get a little mixed up when that happens.

 So what was done was to append the Module handle as a Hex string on the end of those class names so those super classes were uniquely created per module..

 The main module still uses the original names.