It so happens following Christian’s suggestion in another thread, I :
created a picture the size of a toolbar icon,
wrote the icon to it, and
drew the badge.
After which I assigned the new picture to the toolbar icon.
It worked perfectly.
Until I made the app high Dpi aware, and replace the picture by an image with all resolution.
As soon as I try to replace the image by a picture in the toolbar icon, the Windows app simply quits. No error, no message, no unhandled exception. The app terminates.
I have been fighting that hopelessly all yesterday.
The Mac app works just fine, but the Windows one is badly broken.
it will not help you but I have also an app under linux that terminates without error or exception, I can’t trace it to the point it simply quits when I clic on a listbox. the same app works perfectly under macos or windows ! I simply gave up for now.
OK. I was never able to set the toolbar icon with a picture when the app is in highDPI mode. For some reason, it shows an empty space.
For some reason, it seems the toolbar in highDPI mode expects an image with multiple resolutions. I was never able to find any information about how to create such thing in code.
As a stopgap measure, I have reverted to non highDpi mode. At least, the icon badge works again, now.
If you share a simple demo project showing the problem I’ll take a look. I just tried a simple test with one of the examples and I drew a toolbar icon using a picture without issue in HIDPI. I’m probably doing something different/wrong, the demo project would help.
Note: In 2016r3, the Toolbar on TargetWindows has always used the “next higher resolution-representation”. So if you’ve assigned an ImageSet containing 1x and 2x resolutions, and the user would be running on a 125% scale screen, then 2016r3 would use the 2x image out of it (and that would be too big).
Here is how. And that’s what we basically used to do with 2016r3 on Windows to dynamically create the Toolbar-Icons:
Dim pa() As Picture
pa.Append(anIcon-100)
pa.Append(anIcon-125) 'use a method to scale existing 1x or 2x images
pa.Append(anIcon-150) 'use a method to scale existing 1x or 2x images
pa.Append(anIcon-175) 'use a method to scale existing 1x or 2x images
pa.Append(anIcon-200)
theToolbarIcon = New Picture(24, 24, pa)
I can’t remember such a situation, even with 2016r3. A workaround might be: remove all ToolButtons, and append them all again.
I’m glad I could help, but I hope it wasn’t really about your life
Just one more thing I’d like you to be aware of… HiDPI support for Windows in 2016r3 was still in an early stage. As far as I remember, things got really ugly when it comes to 2 Monitors that have different Scaling. Xojo wasn’t capable of handling HiDPI on a “per monitor” basis. Ah right: <https://xojo.com/issue/47753> (fixed in 2017r2).
Some users will run into this if you enable HiDPI support with 2016r3. E.g. when moving your application to another Monitor (with different scaling), changing the current Monitor’s scale (e.g. when doing a presentation on a beamer), …
So, just please think about this and see how your application is behaving with multiple monitors. At least if you expect that some of your customers will need that.
In our experience, we’ve been mostly happy with Windows/HiDPI since 2018r3/4. But I know, that’s another story to get a Windows application from 2017r3 to 2018r4…
The highDPI aware IDE and its crisp display is great.
But the lack of true transparency would require so much refactoring, it does not seem worth it.
Some level of transparency could be attained for canvas by grabbing what is underneath with MBS plugins, but all other controls are at issue. Labels could be replaced by canvas, but custom controls I had created with containercontrols may not easily be made transparent.
On Mac, I can use 2019R2 and probably soon 2019R3.1. For Windows, unless I build a new project from the ground up, and take into account pseudo transparency into the design, Direct2D would break so much of Check Writer, it would not be reasonable.
I’m sure aware Michel, but it’s worth repeating that 2019r2 is the version where the Event names where changed, e.g., Open → Opening.
If you’re going to migrate to API 2.0 or simply use the newer IDE for building, at minimum use 2019r2.1. Just in case anything goes side-ways, plus 2.1 (& r3.0, r3.1) had several API 2.0 related bug fixes.
