WM_NCDESTROY

[srod]

Hi,

here's a strange one.

My main window procedure (subclassed) receives WM_NCDESTROY messages no problem.

I also have a subclassed listview control, whose subclassed procedure receives WM_DESTROY messages, but not WM_NCDESTROY !!! It is this latter message which I am in need of!

Any idea why this should be?  I can see nothing in my code which would remove this message from the message queue etc. I don't know if there is some style flag somewhere which EMBasic has set or cleared which is to blame?

Thanks for any help.

Stephen.

[Ionic Wind Support Team]

Perhaps ListView controls don't generate that message?  Have you checked MSDN docs to verify?

Paul.

[srod]

I have some Purebasic code running here which certainly generates WM_NCDESTROY in the subclassed listview proc.  I presume DestroyWindow() is responsible for sending these messages.

I've tried tinkering with WS_EX_NOPARENTNOTIFY to no avail.

I will have a look on MSDN however.

Actually it is possible that PB, in conjuction with WM_PARENTNOTIFY, are colluding to send this message without assistance from Windows. Worth checking out!  A simple test will confirm this!

Thanks.

[srod]

Looking on MSDN:

http://msdn2.microsoft.com/en-us/library/ms670557.aspx

Quote regarding the listview's default handler for WM_NCDESTROY:

Frees resources allocated by the list-view control. Unless the LVS_SHAREIMAGELISTS style is used, this includes deleting the full-sized and small image lists.

It means that the message is being sent, but is being swallowed somehow.  I can see nothing in my code which might be at fault here.

[Ionic Wind Support Team]

Are you calling the original handler in your subclass?, it is a requirement to save off the original pointer when creating a windows subclass and using CallWindowProc with that pointer when you exit.  Without seeing code I can only guess

[srod]

Are you calling the original handler in your subclass?, it is a requirement to save off the original pointer when creating a windows subclass and using CallWindowProc with that pointer when you exit.  Without seeing code I can only guess

Certainly am.  The address of the old proc is stored in a Windows property.  This is why I wanted to catch the WM_NCDESTROY message as this is the safest place to remove the property (and to also free up some other memory!)

[Ionic Wind Support Team]

Are you calling it last or first?

[Ionic Wind Support Team]

Certainly am.  The address of the old proc is stored in a Windows property. ...

That's how I am doing it as well.  Except I remove the subclass in WM_DESTROY.  Every Emergence BASIC created control is subclassed once by default to handle color properties.  Emergence uses the windows property name "LPFN" to store the original function pointer for passing to CallWindowProcA.

Paul.

[srod]

That's the problem - confirmed!

EMBasic's listview proc is removing my subclass procedure when WM_DESTROY is being processed.  This of course means that my subclass proc never sees  the WM_NCDESTROY message!  If I prevent my WM_DESTROY handler calling yours then I get to see WM_NCDESTROY! 

Thank god for that, I was going nuts for a time trying to figure this out!   

It is of course not a good idea that my proc prevents your WM_DESTROY handler from executing and thus I will place all of my cleanup code in my WM_DESTROY handler. I usually prefer WM_NCDESTROY as it is the absolute last message to be sent for the common controls, but now that I understand how you've set this up I can proceed quite safely.

Thanks.

Stephen.