Recent changes to support-requests

#9 CResizer issue on HighDPI-aware dialog

2022-09-08T01:46:20.230000Z

status: open --> closed

#10 CBitmap attached handle not deleted

2021-05-16T06:32:25.758000Z

status: open --> closed
assigned_to: David

#10 CBitmap attached handle not deleted

2021-05-14T06:40:18.857000Z

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

2021-05-14T03:47:21.764000Z

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

2021-05-11T22:48:52.299000Z

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

2021-05-11T22:48:52.299000Z

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

2021-04-30T12:33:07.494000Z

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

2021-04-30T06:45:28.224000Z

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

2021-04-29T06:55:12.613000Z

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

2021-04-29T06:50:25.569000Z

status: closed --> open