Recent changes to support-requests

#9 CResizer issue on HighDPI-aware dialog

David — Thu, 08 Sep 2022 01:46:20 -0000

status: open --> closed

#10 CBitmap attached handle not deleted

David — Sun, 16 May 2021 06:32:25 -0000

status: open --> closed
assigned_to: David

#10 CBitmap attached handle not deleted

Claudio Nicora — Fri, 14 May 2021 06:40:18 -0000

I've patched it by adding a new Attach() overload that exposes an isManaged parameter.
Your solution is far better ;)

Thanks for it.

#10 CBitmap attached handle not deleted

David — Fri, 14 May 2021 03:47:21 -0000

Hi Claudio,

The Attach for CBitmap is working as it was intended. The Win32++ library automatically deletes or destroys only those resources it created when their object goes out of scope. Resources created by other means such as direct calls to Win32 API functions won't be deleted.

A CopyImage function has been added to CBitmap. This can create a new managed CBitmap from CopyImage.
Instead of bmp.Attach(::CopyImage(...)); , you can now use bmp.CopyImage(...);

You can download the latest snapshot of Win32++ from the Code Section on SourceForge

Best regards,
David

CBitmap attached handle not deleted

Claudio Nicora — Tue, 11 May 2021 22:48:52 -0000

I use a CBitmap object to "manage" a bitmap handle, initializing it with bmp.Attach(::CopyImage(...)); .

Now, when my CBitmap object goes out of scope, the GDI handle is not deleted, because the .Attach() method does not set the m_pData->isManagedObject field, which is tested by .Release() method to delete it.

As I can read here, MFC does delete GDI handles, even if set with .Attach()...

Deleting it manually makes CBitmap useless so... am I missing something?
How shall I manage a CBitmap handle obtained by a call to GDI function?

Thanks for your help

CBitmap attached handle not deleted

Claudio Nicora — Tue, 11 May 2021 22:48:52 -0000

Ticket 10 has been modified: CBitmap attached handle not deleted
Edited By: David (david_nash)
Status updated: 'open' => 'closed'
Owner updated: None => 'david_nash'

#9 CResizer issue on HighDPI-aware dialog

David — Fri, 30 Apr 2021 12:33:07 -0000

Hi Claudio,

The minimum version of the operating system that supports the gdiScaling element is Windows 10 version 1703.

I'd be happy to have a look at your CDpiAwareDialog when it is ready.

Best regards,
David

#9 CResizer issue on HighDPI-aware dialog

Claudio Nicora — Fri, 30 Apr 2021 06:45:28 -0000

Hi David, thanks for it.
Will check it out, but I suppose it'll be supported starting from some Win10 version (1809...?).

Anyway, meanwhile, I've subclassed CDialog to properly manage WM_DPICHANGED messages.
Once the message is received, I disable CResizer, let Windows properly resize the dialog (it only changes locations and sizes), then I scale fonts and reactivate CResizer with the new positions.
It works well and I'm satisfied ;)

I've also switched my graphics (icons, bitmaps, ...) to vectorial versions (EMF and SVG), but that's another story.

Once completed I could send you a cleaned up sample of my CDpiAwareDialog if you want to have a look.

Thanks

#9 CResizer issue on HighDPI-aware dialog

David — Thu, 29 Apr 2021 06:55:12 -0000

Hi Claudio,

Try the attached minifest file in place of your current one.

It utilises gdiScaling in place of PerMonitorV2-DPIAware. That should produce a much better result.

Best regards,
David

#9 CResizer issue on HighDPI-aware dialog

David — Thu, 29 Apr 2021 06:50:25 -0000

status: closed --> open