C / C++ / MFC

Re: AfxBeginThread() with a function in the main class

3-Aug-07 8:14

Johpoke wrote:
How does one make that dude anyway? i cant find him...

It's right next to the Beer | [beer]

one.

With a little ingenuity, you'll find it Smile | :)

Mark Salsbery
Microsoft MVP - Visual C++
Java | [Coffee]

Johpoke3-Aug-07 8:27

Johpoke

3-Aug-07 8:27

Maybe its like a gold-member only emotion. or maybe it doesnt like me...

Ah well doesnt matter im happy anyway Smile | :)

//Johannes

Re: AfxBeginThread() with a function in the main class

Mark Salsbery3-Aug-07 8:34

Re: AfxBeginThread() with a function in the main class

3-Aug-07 8:34

Johpoke wrote:
Maybe its like a gold-member only emotion.

Nope. I was so proud when I found it all by myself, since I know nothing about web programming Smile | :)

Mark Salsbery
Microsoft MVP - Visual C++
Java | [Coffee]

Johpoke3-Aug-07 8:40

Johpoke

3-Aug-07 8:40

//Johannes

Re: AfxBeginThread() with a function in the main class

Mark Salsbery3-Aug-07 8:57

Re: AfxBeginThread() with a function in the main class

3-Aug-07 8:57

Mark Salsbery
Microsoft MVP - Visual C++
Java | [Coffee]

Mark Salsbery3-Aug-07 8:13

PostThreadMessages lost in DLL

3-Aug-07 8:13

Mark Salsbery
Microsoft MVP - Visual C++
Java | [Coffee]

PaulCammy3-Aug-07 5:54

PaulCammy

3-Aug-07 5:54

I have a DLL that has a class derived from CWinApp.

I have another class in the DLL that needs to trigger an asynchronous process within that same DLL. Since the DLL has no window I use PostThreadMessage to trigger the process as follows:

<code>void CMyClass::TriggerAsyncProc() const
{
AfxGetApp()->PostThreadMessage(WMU_MYMSG, 0, 0L) ;
}</code>

In my class derived from CWinApp, I have tried two different methods to trap WMU_MYMSG. The first was to override PreTranslateMessage, and the second was to try to use the CWinApp message map (via ON_THREAD_MESSAGE).

The DLL is being used by a dialog application, and the TriggerAsyncProc is definately sending the message because PostThreadMessage(WMU_MYMSG, 0, 0L) returns non-zero.

The only thing I can think of is that my message is going through the message map of the dialog application instead of my class derived from CWinApp in the DLL.

Please can someone tell me why I'm losing the message, and suggest either how I correct this or an alternative method?

Thanks.
Confused | :confused:

Mark Salsbery3-Aug-07 6:07

3-Aug-07 6:07

This doesn't sound like it would work.

A DLL that has a CWinApp object is supported, but that CWinApp object doesn't have its own message pump.
I wouldn't expect any messages to be processed in the DLL's CWinApp object unless you've tweaked something
to do so.

Here's what the docs state about this situation:

"Note that the CWinApp::Run mechanism does not apply to a DLL, because the application owns the main message pump.
If your DLL brings up modeless dialogs or has a main frame window of its own, your application's main message pump must
call a DLL-exported routine that calls CWinApp::PreTranslateMessage."

Mark

Mark Salsbery
Microsoft MVP - Visual C++
Java | [Coffee]

PaulCammy4-Aug-07 1:52

PaulCammy

4-Aug-07 1:52

Thanks for that. It's a pity that the DLL Wizard created a CWinApp derived class that includes Message Map macro declarations.

There is a possiblity that the main applications using my DLL will not have a main frame window - they may also be ATL applications. Please could you advise what I could do in these cases?

Thanks

Mark Salsbery4-Aug-07 6:42

4-Aug-07 6:42

I would suggest reading this: Kinds of DLLs[^]

It outlines the methods and requirements of different MFC DLL scenarios.

Maybe it'll help choose an appropriate method for your needs.

Mark

Mark Salsbery
Microsoft MVP - Visual C++
Java | [Coffee]

PaulCammy5-Aug-07 22:23

PaulCammy

5-Aug-07 22:23

Thanks again.

Not a lot of help there about this particular situation, but some useful info. none the less.

Cheers.

Blake Miller6-Aug-07 5:06

Blake Miller

6-Aug-07 5:06

What I have done within a DLL 'init' function that the client must call - AFTER the client has already loaded all its dll and such, is to create a new thread. All the work within the DLL I wrote was done from within this thread internal to the DLL.
At the top of this thread place a PeekMessage call, so the thread will get a message queue. Then you can process 'posted thread messages' fromt this thread and it has its own independent message pump.

Just because an app stared as a dialog app, or some other type of app, does not mean it can't have a DLL containing its own thread and its own message queue.

Mark Salsbery6-Aug-07 5:06

differentiating between literal strings and char pointers [modified]

6-Aug-07 5:06

Yeah. The main point is...

when using MFC in a "regular DLL" (that can be used by an MFC or non-MFC app) then
you have to provide the message pump.

There's also subtle differences in MFC initialization, but if you use the wizards, that code
is created for you.

Mark

Mark Salsbery
Microsoft MVP - Visual C++
Java | [Coffee]

dburns3-Aug-07 4:48

Re: differentiating between literal strings and char pointers

3-Aug-07 4:48

Hi,

Suppose I have a method foo that takes a const char* param. I have a case where I can be more efficient if the caller passes in a "quoted literal string" vs the contents of some arbitrary buffer (because I don't have to copy the string data in the first case).

((UPDATE: To be clear, the class with method foo needs to store the supplied string away for later access, internally. For a literal string, it's safe to store the pointer only. For a non-literal, it's necessary to copy the data in case the original caller's buffer goes away or is modified before the class instance goes away.))

Pretty sure the answer is "you can't", but I thought I'd check if anyone can think of a way to overload the method foo such that one version is invoked for

char buff[100];<br />
...<br />
const char* p_buff = buff;<br />
myclass.foo(p_buff)

and the second version is invoked for

myclass.foo("literal string")

?

I can't change the name of foo or have the caller specify explicitly which one they want. This sample is just an illustration.

Thanks!
DB

-- modified at 12:11 Friday 3rd August, 2007

CPallini3-Aug-07 4:59

CPallini

3-Aug-07 4:59

dburns wrote:
Hi,

Suppose I have a method foo that takes a const char* param. I have a case where I can be more efficient if the caller passes in a "quoted literal string" vs the contents of some arbitrary buffer (because I don't have to copy the string data in the first case).

IMHO, You completely miss the efficience target...
i.e. don't bother about.
Smile | :)

If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.

Re: differentiating between literal strings and char pointers

dburns3-Aug-07 5:03

Re: differentiating between literal strings and char pointers

3-Aug-07 5:03

CPallini wrote:
IMHO, You completely miss the efficience target...

Actually we've done profiling on this code and it really does matter.

You may be picturing one or two invocations but picture 10s of millions Smile | :)

CPallini3-Aug-07 5:07

CPallini

3-Aug-07 5:07

But you don't need to copy anything,
simply cast the pointer!
Smile | :)

If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.

Re: differentiating between literal strings and char pointers

dburns3-Aug-07 5:13

Re: differentiating between literal strings and char pointers

3-Aug-07 5:13

We really DO need to copy the data because the C++ object that I called "myclass" may outlive the buffer that contained the original data. If we just stored the supplied pointer, then it would be pointing to a buffer on the stack, which would be wiped out when the function returned. Then the "myclass" object would have a pointer to garbage.

If the pointer is truly a "literal string" then that's not an issue. That's why I'm trying to detect that case to be more efficient.

CPallini3-Aug-07 5:19

CPallini

3-Aug-07 5:19

But (in the OP) you're not copying data, you're just copying the address. ...is there a mistake in the air?
Smile | :)

MODIFIED:
Or are you're talking about an internal copy done by you're class?
in that case you've simply to differentiate calls to foo() member, for instance:

foo(const char * pBuffer)
{
  // perform a copy of the given buffer
  ...
  // call the copy-free member
  foo_without_copy(pCopiedBuffer);
}
foo_without_copy( const char * pBuffer)
{
...
}

If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.

Re: differentiating between literal strings and char pointers

dburns3-Aug-07 5:48

Re: differentiating between literal strings and char pointers

3-Aug-07 5:48

CPallini wrote:
Or are you're talking about an internal copy done by you're class?

Yes, that's exactly right. Perhaps you've illustrated it better than I did in the original post.

However, I can't use foo and foo_without_copy. In the OP I indicated that I can't have the caller make the explicit choice. I need the compiler to differentiate, if it's possible. I doubt it is.

Maybe I'm just lazy but we're talking a million lines of code here and I'd rather the compiler did the work rather than me searching and changing each one Smile | :)

David Crow3-Aug-07 6:11

David Crow

3-Aug-07 6:11

dburns wrote:
I need the compiler to differentiate, if it's possible. I doubt it is.

It makes me wonder if the two addresses would be in different areas. String literals would be in the stack area, whereas dynamically-allocated memory would be in the heap. Hmmm...

"A good athlete is the result of a good and worthy opponent." - David Crow

"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne

Re: differentiating between literal strings and char pointers

dburns3-Aug-07 6:22