User-defined objects in Windows message parameters

[Atropus]

Hi everyone. I've made a working thread that interact with a window by user-defined messages (WM_USER + x). I would like use WPARAM and/or LPARAM to give to the window objects allocated in the working thread. In few words, I would like obtain the same result that the Windows achieve with message like WM_CREATE (LPARAM is a pointer to a structure). I know that the object I want pass through the message must be deallocated and I've tried to use the SendMessageCallback function, but the callback user-defined function is called only if GetMessage, PeekMessage or WaitMessage are called by the same thread (MSDN docet). Anyone can help me? Thanks a lot, Sergio

[Matthew Faithfull]

That's a tricky one. Maybe you can solve it by using PostMessage and having the message handling end do the delete but if the allocation was on a different thread this might be dangerous. Can you use two messages, one to tell the Window end to allocate a structure, write a pointer to it at a specified address and then set an Event and the second, triggered in the secondary thread by the event, to tell the Window that structure has been filled in. Kind of like:-

Window Thread Secondary Thread
Set up a pointer pStruct
Post a msg to the Window with pStruct
Wait on a shared event
Recieve msg with &pStruct
pStruct = new Struct
Set Shared Event
pStruct is now allocated so fill it
SendMessage to Window
Recieve msg<--------------------------
Process and delete pStruct----------->Secondary Thread continues

Perhaps that's over complicated and all you need is PostMessage but I've struggled with a few of these in the past.
Watch it when your controls are being destroyed that you don't leak allocations that havn't been used yet.

"The secret of happiness is freedom, and the secret of freedom, courage." Thucydides (B.C. 460-400)

[Rajasekharan Vengalil]

I might be missing something here, but what stops you from doing something like this:

//
// allocate & initialize FOOBAR
//
FOOBAR *pData = new FOOBAR();

//
// send the message and free pData
//
SendMessage( hWnd, WM_DO_FOOBAR_THING, (WPARAM)pData, NULL );
delete pData;

-- gleat http://blogorama.nerdworks.in[^] --

Number Two's eyes narrowed and became what are known in the Shouting and Killing People trade as cold slits, the idea presumably being to give your opponent the impression that you have lost your glasses or are having difficulty keeping awake. Why this is frightening is an, as yet, unresolved problem. -- HHGTG

[Roger Stoltz]

Ummm, I don't see what the problem is.... :confused: You don't say anything about what you've tried so far and how it fails, it looks to be more of a design question...

Atropus wrote:

I've made a working thread that interact with a window by user-defined messages (WM_USER + x)

Quite all right, as long as you use PostMessage() and not SendMessage() to avoid a deadlock situation. But you should not use WM_USER; at least use WM_APP. What you really should do is use registered messages. Read this[^].

Atropus wrote:

I would like use WPARAM and/or LPARAM to give to the window objects allocated in the working thread.

This should in most cases be fine as well, depending on what type of object you're allocating. Read the article linked to above. It could be dangerous if it's an MFC object since MFC classes wraps objects like e.g. windows and sockets that are referred to through a handle and the MFC object handle map is on per thread basis. But if it really is an MFC object your trying to pass you should re-evaluate your design because you'll get into troubles sooner or later.

Atropus wrote:

I know that the object I want pass through the message must be deallocated and I've tried to use the SendMessageCallback function

Deallocate the object in the message handler. The only danger you'll expose yourself to is a memory leak if the message for some reason should not be handled. But if that happens the memory leak would be the least of your problems. You should really read this article[^] before continuing with your worker thread. It's the best introduction to worker threads I've come across.

"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown