|
Hi,
Rajesh already pointed out to my chart control article, but just to let you know that I think it will fit perfectly with your case: it was originaly developed for medical applications (one of the use was for ECG).
|
|
|
|
|
I have a console application that is using a DLL that uses a SetTimer() call to create a timer and fire a function within itself. The call is below...
SetTimer((HWND)NULL, 0, timer_num, (TIMERPROC)UnSyncMsgTimer)) == 0)
It is expecting to receive timer messages but this never happens, I assume because mine is a console application and not a standard Windows GUI application (like where the DLL was originally used). This stops a key part of the DLLs functionality from working.
My application needs to stay a console application and I cannot change the DLL.
Does anybody know of a work around to make this work?
Thanks, Joseph
|
|
|
|
|
The following console program works. It sets a timer using SetTimer
then loops in a message loop. The message loop receives and processes WM_TIMER messages
and the timer callback also is called for each time interval.
#define STRICT 1
#include <windows.h>
#include <iostream.h>
VOID CALLBACK TimerProc(HWND hWnd, UINT nMsg, UINT nIDEvent, DWORD dwTime)
{
cout << "Time: " << dwTime << '\n';
cout.flush();
}
int main(int argc, char *argv[], char *envp[])
{
int Counter=0;
MSG Msg;
UINT TimerId = SetTimer(NULL, 0, 500, &TimerProc);
cout << "TimerId: " << TimerId << '\n';
if (!TimerId)
return 16;
while (GetMessage(&Msg, NULL, 0, 0))
{
++Counter;
if (Msg.message == WM_TIMER)
cout << "Counter: " << Counter << "; timer message\n";
else
cout << "Counter: " << Counter << "; message: " << Msg.message << '\n';
DispatchMessage(&Msg);
}
KillTimer(NULL, TimerId);
return 0;
}
|
|
|
|
|
I think he means the SetTimer() call is within the DLL and he can't change that... doesn't he...
...so he just needs to be able to catch the message and make sure the timer ID matches whatever he set...
|
|
|
|
|
Ah ,ok .
|
|
|
|
|
Is the timer function UnSyncMsgTimer exposed by the dll?
If it is you might start your own timer and call it.
0100000101101110011001000111001011101001
|
|
|
|
|
SetTimer((HWND)NULL, 0, timer_num, (TIMERPROC)UnSyncMsgTimer)) == 0)
How do you know the line of code inside the DLL that sets the timer? Do you have the DLL source code?
Best Wishes,
-David Delaune
|
|
|
|
|
That will not work without a message loop.
--
Kein Mitleid Für Die Mehrheit
|
|
|
|
|
Hi,
What won't work? I am properly formatting and quoting the code posted by the original poster and asking if he has the source code to the DLL in question.
Best Wishes,
-David Delaune
|
|
|
|
|
Woops, sorry. I guess the DLL won't work unless he implements a message pump.
--
Kein Mitleid Für Die Mehrheit
|
|
|
|
|
Hi,
I am using PostThreadMessage & PostMessage to post messages on Thread and Windows respectively. It works fine in most of cases but when there is a high frequency of posting messages then sometimes it misses some messages. I mean message posts successfully but MessageHandler is not called. If I sent 1000 messages then message handler gets call only 990 or 980 times. Can anyone suggest something for this problem? I am too tired now
Thanks,
Rahul Kulshreshtha
|
|
|
|
|
Are you sure that PostThreadMessage() succeeded? If the return value was false, and GetLastError() returned ERROR_NOT_ENOUGH_QUOTA , then your message posting failed because the recipient message queue was full. In this case, you may want to try and post the message after a short delay. The doc is here: http://msdn.microsoft.com/en-us/library/windows/desktop/ms644946(v=vs.85).aspx[^]
The more pressing question is: Why are you posting such large number of messages in a short time, anyways?
"Real men drive manual transmission" - Rajesh.
modified 24-Sep-11 1:16am.
|
|
|
|
|
Rajesh R Subramanian wrote: Why are you posting such large number of messages in a short time, anyways?
Why not? ...good answer but invalid follow-up question...
|
|
|
|
|
I don't see what's so "invalid" about it. It would be polite if you leave it for the OP to answer my questions, will you?
"Real men drive manual transmission" - Rajesh.
|
|
|
|
|
Its an open thread, nothing impolite about answering a question you posted.
|
|
|
|
|
Except for the fact that you didn't answer the question, but you said that the question itself is "invalid" (whatever that could mean). Especially when you did not post the original question and neither did you answer it. Open thread doesn't mean you are allowed to make rude remarks without any sane reasoning. Not to mention you have absolutely no idea why I asked that question to the OP.
"Real men drive manual transmission" - Rajesh.
|
|
|
|
|
It's not rude at all, if you can't take the feedback then you probably shouldn't post. As far as why its invalid, have you ever done anything with gdi? Windows does a lot with high frequency messages, its nothing unusual.
|
|
|
|
|
I'll take feedback as long as it's sensible. Yours wasn't.
Whether or not I've done anything with GDI is unimportant. My question to the OP is important, because you don't know if he's using GDI, or he's stuck with a botched design. Others seem to agree with me as well, so how about you stop being pompous?
"Real men drive manual transmission" - Rajesh.
|
|
|
|
|
How about you take the feedback more gracefully?
|
|
|
|
|
What EXACTLY is the feedback you're talking about?
The OP asks a question, and I suspect a design flaw has lead him to ask it. I answer his original query, and then ask him a followup question which will help me understand if his design is flawed. And then you show out of nowhere to tell me that I'm asking an "invalid question", which serves absolutely no purpose. But you seem to be thinking that you've given me "graceful feedback".
"Real men drive manual transmission" - Rajesh.
|
|
|
|
|
Thanks Rajesh & Randor for the answer,
Ops!! I am a bit late in answering. I will surely check for that quota limit error ERROR_NOT_ENOUGH_QUOTA, not sure if that is the problem.
My application is a trading application and each millisecond is important in that. The problem happens while I postmessage on a window to add/update the value in that. PostMessage happens on every status change of an order. There are multiple orders and status change happens in approx every 200 milliseconds. Most of time everything works fine but sometimes it misses messages.
Thanks for the follow-up question. Thank albert for participating.
|
|
|
|
|
Nothing wrong with posting a lot of messages, windows posts a ridiculous number of messages for handling window drawing. Video games do the same for drawing smoothly. Good luck!
|
|
|
|
|
Thanks Albert,
That's what I was doing till now but it could not work. To confirm this issue, I made one test project. I had posted 10005 messages on a dialog with different scenarios.
Scenario 1: I sent all the messages using a "for" loop
for(....)
{
::PostMessage(.....);
Or
::PostThreadMessage(....);
}
Scenario 2: I added a Sleep statement after Posting message. (I am not using Sleep in my project, it was just for testing purpose)
I run both the scenarios 10 times. Messages were missed only once. MessageCount was 9993 instead of 10000. I know last 5 will miss for sure. This does not happen frequently so it's difficult to reproduce.
My live project is still under testing so waiting for it's test result.
|
|
|
|
|
Are you processing these on the main GUI thread? ...if so, try just posting between two threads that do nothing except for catching/sending messages. The main GUI thread gets a lot of overhead messages from Windows (specially when drawing).
|
|
|
|
|
I can't think of any other reason for why some messages should go missing, except for if the queue is full. You can try increasing the message queue size (Google for this - a registry key can be modified to achieve this). If performance is of so much importance, I'd think of dropping MFC and switching to something lower (like STL) because you're now having the added overhead of MFC.
I hope you're using multiple threads (if not, it's about time you did). I could even think of using a thread pool in a scenario like this. If nothing, you could accept all messages and put it into data structure (so that the message is popped off the queue immediately), and then process messages from that data structure.
I think some redesigning may be required, based on your application's requirements.
Another person is telling you to go ahead and post messages like crazy, but that sounds like bad advice to me because that clearly is not working (the very reason why you started this thread).
"Real men drive manual transmission" - Rajesh.
|
|
|
|