Win32 API Comm sample TTY - Porting to MFC format 2

[BM]

I am trying to port the TTY sample program to the MFC environment(having given up on the VCTERM sample) and am getting a type cast fault in the CreateThread statement.<br>Has anyone out there tried this port or can throw any light on the fault.&nbsp;&nbsp;I would be happy to send more details of the fault if anyone out there thinks they can help<br><br>Thanks<br><br>Barry

 

[palbano]

Dear Barry,<br><br>&gt; I am trying to port the TTY sample program to the MFC environment<br><br>I don't understand 'port'. You are building a 'terminal' application in MFC so you are trying to 'port' TTY into an MFC project?<br><br>-pete<br>

 

[BM]

Hi Pete,<br>I am indeed building a terminal application into an MFC project.&nbsp;&nbsp;I am doing this in order to get an insight into how the WIN32 COMM API works with a view to using it to interface to a GPS unit.<br><br>Barry<br>

 

[palbano]

Barry,<br><br>&gt; with a view to using it to interface to a GPS unit.<br><br>It would appear that code reuse would be a benefit to you then. <br><br>I have an old class that encapsulates the Win32 COMM API. If I remember correctly it handles the thread creation and event notification for you and implements blocking IO. It would need to be extended to handle overlapped IO.<br><br>If you would be interested in looking at it or using it I can try and find it. I don't have access to it on this machine but would by tomorrow.<br><br>-pete

 

[BM]

Hi Pete,<br>Thanks for your reply, I would indeed be interested in your Win32 API class.&nbsp;&nbsp;I would like a copy of it whenever it is convenient for you to transfer it, it appears to do everything that I want to do.<br><br>Thanks very much<br><br>Barry<br>

 

[Shadow4269]

Pete<br>I know I just jumped into this, but I would also be interested in that class, If you could please sent that to me when you get a chance, I would really appreciate it.

 

[palbano]

Dear Barry,

Well my memory failed again. The class does not handle thread creation. After looking at it last night I remember that at the time I decided that the responsibility of creating the thread did not belong to the base class as it seemed a separate issue from port functionality.

Indeed the need for a worker thread to capture port events is an application to application issue and my not always be required. So the class can be utilized in an applications main thread or in a worker thread or even in more than one thread if so desired. A single instance of the class can be used in different threads so as to break apart the event handling from the other operations like open/close/read/write.

http://saberco.com/devCorner/cpp/SerialDevice.htm

If your project requires a 'worker' thread for event handling I would gladly assist in your efforts to achieve your goal.

Hope this helps
-pete

 

[BM]

Hi Pete,
Thanks for the reply, I think that I could handle the thread
activity provided it is in the 'AfxBeginThread category, so I would be very glad to get a copy of your class and any help you can give. I will try the htm file that you have listed and get back to you.

Thanks

Barry

 

[BM]

Hi Pete,
I have had a brief look at your code and it looks good. I have done a quick build, sorted out some comment 'errors'(they had somehow lost their // I think!).
I will make my own class for the link info, baud rate etc and give it a whirl!!

Thanks a million

Barry

 

[BM]

Hi again Pete,
I have tried to do the threads on my own but have failed miserably.
I have taken a standard MFC SDI application and tried to follow the TTY layout, Open Setup etc, inside the MainFrame Class, allowing Documents to access the input. Is this the best way to do it or is there a neater way? I would appreciate any help that you can give.

Barry

 

[palbano]

Hi Barry,

The only thing you said that I would find questionable is using your 'CMainFrm' derived class for any message handling.

The typical design is to handle most of the messages in the document class since it normally has access to all the pertinent data. Then if a UI update is required call the document class's UpdateAllViews() member with information pertaining to how the UI needs to be updated.

However, even though there is a normal that doesn't mean any specific application needs to follow the normal design.

In the case of a worker thread design, you could have the document class handle all the thread communications as well. The thread communications is relatively simple if you use CWinThread as the base class for the worker thread class behavior.

-pete

 

[BM]

Hi Pete,
Thanks for the reply, my first efforts were indeed in a Document but I had problems getting the thread class to accept the CommWatch function.
Does this routine have to be global? I would appreciate any pointers as to how the CWinThread functions might be implemented.

Thanks again

Barry