Windows messaging alternatives to Postmessage and Sendmessage
Posted on 2003-10-30
I am looking for an alternative to using PostMessage or SendMessage to notify a thread in my C++ OCX application to respond in more real time. My music application currently uses them to trigger the thread to run, fire and return from an event in a remote Visual Basic executable repeatedly. My application would like to fire the event in real time (less than one millisecond) without being interrupted by delays in the operating system and by other system and thread messaging queues. Works perfectly so far on my 500MHz Pentium III, but not if I start to click on things in any application.
The postmessage or sendmessage is subject to delays in the operating system and can respond slow when windows, objects on windows, and menus in windows are being moved, minimized, clicked, selected with mouse, etc. This is normal for windows messaging when dealing with queued and nonqueued messages. But it has made my real time music application worthless.
Alternatives I have tried:
- I would not be able to fire the event directly because OLE automation error occurs.
- I would not be able to fire the event in another thread with AfxBeginThread() because OLE automation error occurs. Most likely like firing the event directly.
- I would not be able to fire the event with a timer because it can also be delayed.
- I would not be able to fire the event with a timer because I would need less than 1 miillisecond intervals for real-time processing.
If you have a question about the the OLE automation and unhandled error, then go no further. It occurs whenever it reaches simple code in VB that it does not like. Like On Error Goto, Debug.Print, Left() and Trim() string functions, Sleep and other Windows API, Stop, stepping through code in debugger, and many others. No solution as of this date.
I am sure there is more information I can provide, but I can not think of it right now.
Thank you for your help.