Re: sending user defined msg to MFC dll - using serial writer/read

Tech-Archive recommends: Fix windows errors by optimizing your registry



"Joseph M. Newcomer" wrote:

You seem to keep trying to rewrite the code to do something different. You can't use the
dialog because the read thread blocks waiting for input, which is why I do it as a
separate thread. Why do you feel compelled to change this? You can't do it in the dialog
because you don't want to block the main GUI thread, and the dialog runs in the main GUI
thread.

sorry, I should have been more clear. I am definitely going to use your
code, with the reader and writer thread. The below does work (somewhat):

[in dll]
openmonitor()
{
create modeless dialog
}

opencommport
{
open comm port

create writer thread
assign dialog as notifyee in SerialParameters
resume writer thread
theApp->dlg->PostMessage(WM_DLG_SEND_DATA); //for testing
//reader thread omitted for now
}


[in modeless dialog]

onDlgSendData
{
allocate hello string
AfxGetApp()->writer->PostThreadMessage(WM_SEND_DATA, string...)
}

this actually works, i.e. I could see the data appear on the port.
funny thing is that I can't call
writer->PostThreadMessage(WM_SEND_DATA,...) directly from the dll - why?



You seem to keep thinking that the DLL is running in a different thread. The DLL is just
a set of subroutines that execute in the context of whatever thread calls them. The UI
thread that is handling the writing, or the worker thread that is handling the reading,
are separate threads. They are separate threads because they represent asynchronous I/O
events.

The dialog simply responds to the message posted by the reader thread, and yes, that
dialog can route the notification message any way it wants to, but this does not eliminate
the need to have two separate threads to handle the communication. And these threads can
be hidden inside the DLL fairly easily.
joe
On Thu, 7 Dec 2006 15:28:02 -0800, Andreesje <Andreesje@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:


Try to keep these in the same thread so replies make sense. Don't change the subject.

was I replying incorrectly?


See below...
On Thu, 7 Dec 2006 09:20:00 -0800, Andreesje <Andreesje@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:

DLLs don't have message maps. Threads have message maps. So if you don't
instantiate a
UI thread it won't work. A DLL is not a thread, so it cannot possibly work. Note that in
my code, I instantiate a UI thread to handle the notifications, and PostThreadMessage to
that UI thread. The code below is attempting to PostThreadMessage to a DLL, specifically
to the CWinApp-derived class, which won't work. There's a reason I used AfxBeginThread on
a UI thread in that example

thanks for replying so quickly.

I suspected it to be due to the dll not having a message map. The situation
with my code is somewhat convoluted. I have a MS access database that calls
the dll, which in turn interfaces to a device through the serial port. There
is a modeless dialog box which gets created by the dll that monitors a log
file.
****
You have to create a UI thread. To "call" the DLL would be to call a method that posts a
message to the UI thread. What you have to do is take my code and wrap it in an interface
of your choice.

Because you can't launch a thread in DllMain/InitInstance of a DLL, you have to have a
flag that says whether or not the thread exists (e.g., the CWinThread * is NULL), and if
it doesn't exist, you would do an AfxBeginThread at that point to instantiate the thread.

The modeless dialog could also do this in its OnInitDialog handler.

can't I use the dialog for routing those messages? I know it seems a bit
cumbersome but the individual message handlers could then call the dll's
member functions.

****
The serial device usually only replies if talked to and the responses are
fixed length for each command. Only occasionally it will send a reply by
itself and that one is also fixed length. The data rate is quite low so I am
wondering if I can't get away with non-overlapped and just a reader thread.
***
No, you can't use non-overlapped I/O on a bidirectional serial port; if you are waiting
for a read, you will be unable to do a write.

The code I showed is straightforward; you just have to wrap it up in the DLL so that the
interfaces you present to the caller are simple (e.g., SendText, or get a message that
text has been received), and you're there. By trying to make this something in a
CWinApp-derived class, you are doing something other than what I showed in my code sample.
joe
****
Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm

Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm

.

Relevant Pages

  • Re: sending user defined msg to MFC dll - using serial writer/read
    ... create modeless dialog ... I have to put in the CWinApp-derived class is vanishingly small, and they are only used by ... You seem to keep thinking that the DLL is running in a different thread. ... They are separate threads because they represent asynchronous I/O ...
    (microsoft.public.vc.mfc)
  • Re: sending user defined msg to MFC dll - using serial writer/read
    ... You seem to keep thinking that the DLL is running in a different thread. ... They are separate threads because they represent asynchronous I/O ... MVP Tips: http://www.flounder.com/mvp_tips.htm ...
    (microsoft.public.vc.mfc)
  • Re: ActiveX.exe more problems
    ... Schmidt wrote: ... NET but the marshalling took too much time. ... separate threads - all inside one single VB6-ActiveX-Dll. ... For some reason I had thought that DLL objects only ran in the caller's thread. ...
    (microsoft.public.vb.general.discussion)
  • Re: ActiveX.exe more problems
    ... NET but the marshalling took too much time. ... I planned to use this Dll on ... separate threads - all inside one single VB6-ActiveX-Dll. ...
    (microsoft.public.vb.general.discussion)
  • Re: Multiple DLL, multiple THREADS, multiple applications or something else?
    ... Once DLL is loaded and serial port opened and DLL left in its own ... especially if you re-use the buffers by ... > respond to query from devices on serial port) on a notify base ... ...
    (borland.public.delphi.language.objectpascal)