Windows Messaging Timing and Threads
-
Allright, I have some major questions that maybe some one can help me with. First I am writing a Windows GUI that interfaces to an embedded system via RS232 messages. In order to transmit these messages, I was asked to create a three level OSI protocol stack (transport, network, and datalink.) This stack then communicates back to the application via windows messages (WM_COMM_SENT, WM_COMM_RETRY, and so on...) This uses two threads (send and recieve for each layer) but only the transport thread sends messages. I have a simple callback system where the transport talks only to the CMainFrame class. The mainframe class handles the messages, queries a messages manager, and then the message manager sends out a WM_COMM_CALLBACK message to each window that needs the data. The problem is, I am currently trying to interact with the box via the new GUI. The GUI handles a button press, issues the send command in the transport just fine and recieves the data back immediately. However I must release or terminate the current windows message before the messages that come back from the communications stack are processed. This works fine because most of the GUI message handlers are short..., but finally to my question? Is there a case where during a button press that sends out say 128 messages to handle some of the return messages before the button press message returns back to the message pump? Or is there better system for returning information from the transport... I guess after working 16 hours a day for three weeks to get a demo ready for a trade show and being the only one in a small company that can handle this, I am a little fried and need help walking through the Windows messaging world and threads... My only other ideas are to release control and wait for the callback before sending the next message, but that limits the functionality of placing a multi-message buffer in the comm stack... or to write a thread that GUI message starts up and then lets it ride until all the messages are sent, however I am already handling so many threads... In other words how many threads are too many threads :confused:. Any help is appreciated... Thanks, Brian Stop the hatred, free the Mallocs.
-
Allright, I have some major questions that maybe some one can help me with. First I am writing a Windows GUI that interfaces to an embedded system via RS232 messages. In order to transmit these messages, I was asked to create a three level OSI protocol stack (transport, network, and datalink.) This stack then communicates back to the application via windows messages (WM_COMM_SENT, WM_COMM_RETRY, and so on...) This uses two threads (send and recieve for each layer) but only the transport thread sends messages. I have a simple callback system where the transport talks only to the CMainFrame class. The mainframe class handles the messages, queries a messages manager, and then the message manager sends out a WM_COMM_CALLBACK message to each window that needs the data. The problem is, I am currently trying to interact with the box via the new GUI. The GUI handles a button press, issues the send command in the transport just fine and recieves the data back immediately. However I must release or terminate the current windows message before the messages that come back from the communications stack are processed. This works fine because most of the GUI message handlers are short..., but finally to my question? Is there a case where during a button press that sends out say 128 messages to handle some of the return messages before the button press message returns back to the message pump? Or is there better system for returning information from the transport... I guess after working 16 hours a day for three weeks to get a demo ready for a trade show and being the only one in a small company that can handle this, I am a little fried and need help walking through the Windows messaging world and threads... My only other ideas are to release control and wait for the callback before sending the next message, but that limits the functionality of placing a multi-message buffer in the comm stack... or to write a thread that GUI message starts up and then lets it ride until all the messages are sent, however I am already handling so many threads... In other words how many threads are too many threads :confused:. Any help is appreciated... Thanks, Brian Stop the hatred, free the Mallocs.
Any process which is syncronchous inside the GUI, should be seperated by implementing within a thread. I guess from your description. I would have a thread to process requests from the GUI. Eg. CProcessTread { AddRequest(...) ProcessQueue(...) etc. AddFeedBackDelegate(...) } This frees the GUI to get on with it's own business. "AddFeedBackDelegate" would take call back function to your GUI so that you can be notified of message receipt/delivery. Alternatively you could Send requests back to the GUI via custom WM_APP + 0x??? messages. I hope I make since, feel free to contact me with a more descriptive email. Normski. - Professional Windows Programmer