gobrad

I did some work regarding better High-DPI Support in my application, and was wondering if that would be the way to go for other users too. As discussed in this thread: https://sourceforge.net/p/owlnext/discussion/97175/thread/3cab21ed47/ , my biggest problem was TButtonGadget (i.e. Toolbar) resizing. Maintaining multiple bitmap sets in different sizes was not really an option. I've implemented now a solution based on my own TButtonGadget subclass TResizableButtonGadget (similar also for TResizablePopupMenuGadget...

Thank you Vidar, I've missed that feature request. It describes my problem very well. I will try to find some time to tackle the toolbar problem in the next months. Before I implement the solution recommended from Luigi, I will investigate some more generic solutions first. If I come up with a solution which can be integrated in OWLNext, I will let you know. Best regards Goran

Dear Luigi Thank you for a fast response! Yes, I was afraid that it is the only option. I have >100 24x24px bitmaps in the software, and have to find a way to resize them in acceptable quality first. The idea with the offset between bitmaps and your GetDPI functions are very helpfull! Best regards Goran

Hi I am trying to adapt my OWLNext (6.44) application better to High DPI displays. Automatic Windows scaling ("scaling performed by system") results in a blurry UI, and without it, my UI elements are sometimes too small. Are there any experiences or best practices about handling High-DPI subject with OWLNext? I've already added various functions enabling user to adjust the size of the graphical output of the application, but still have the problem that toolbar and its buttons are sometimes too small....

Thanks Vidar! I investigated the problem a bit further: The most important difference was that my project uses: #define _WIN32_WINNT _WIN32_WINNT_VISTA and OWLNext uses (in wsysinc.h): #define _WIN32_WINNT _WIN32_WINNT_WINXP I am not sure if the logic in wsysinc.h is compatible with the way Windows SDK defines _WIN32_WINNT: If you just install the latest SDK and compile OWLNext and a simple application without setting _WIN32_WINNT explicitly, OWLNExt will default to _WIN32_WINNT_WINXP and the application...

Vidar, thank you for your hints. I've tried adding a destructor in TLvColumn, and it really fixed the problem. So, your assumption was correct. All my builds use static linking, and after checking several time all compiler/linker settings, I could not find any significant differences between my project and the examples. OWLNext libraries are up-to-date, and all projects are using the same libraries in a same way. One more interesting obervation: After turning on aditional compiler/linker checks (SDL...

Hello Ognyan Thank you for looking into this. Since my source code was actually copy/paste from examples, I thought that minimal example would not make much sense. Now I've managed to narrow the problem to this ~~~ { TLvColumn("Column 1", 80); } ~~~ anywhere in my application causes a crash in TLvColumn destructor (presumably) during destruction of the "Buffer" member (std::vector<tchar>). So, even without any dialogs, resources, TListViewCtrl etc. So, I presume that it must be some compiler/linker...

Hello Ognyan Thank you for looking into this. Since my source code was actually copy/paste from examples, I thought that minimal example would not make much sense. Now I've managed to narrow the problem to this ~~~ { TLvColumn("Column 1", 80); } ~~~ anywhere in my application causes a crash in TLvColumn destructor (presumably) during destruction of the "Buffer" member (std::vector<tchar>). So, even without any dialogs, resources, TListViewCtrl etc. So, I presume that it must be some compiler/linker...