|
Add the following code
#pragma comment(lib, "opengl32.lib")
#pragma comment(lib, "glu32.lib")
Jonathan de Halleux.
|
|
|
|
|
Is there a way to make a program check for WM_TIMER message more frequently? I'm getting too much delay time between messages.
|
|
|
|
|
Dov Sherman wrote:
I'm getting too much delay time between messages
You should handle those messages in separate threads. Thus, the message treating time is low and the system can pass quickly to the next one in the queue.
rechi
|
|
|
|
|
But I don't want the work done by my WM_TIMER event to be done at the same time as other events such as mouse-interaction since that would affect the data those events manipulate. I need to make certain that only one event is being performed at a time. I just want the WM_TIMER events to be checked more frequently or to be given a higher priority in the message queue.
|
|
|
|
|
You are out of luck. The only way is to create you own timer by implementing a thread which does time measuring and raises events.
WM_TIMER messages are not guaranteed to be delivered (like WM_PAINT).
Holy Sh*t! I'm speechless. (hey, that's a first) Marc Clifton, The Lounge
|
|
|
|
|
Dov Sherman wrote:
...to be done at the same time as other events such as mouse-interaction...
This is impossible while using the message queue. The messages are serialized, so all you have to do is to make sure that WM_TIMER s are checked as soon as possible. On the other hand, if - let's say - WM_LBUTTONDOWN occurs and its handling will take so much time that it will block the immediate WM_TIMER checking then... there there is nothing to do. You should interrupt the WM_LBUTTONDOWN manipulation stuff and get to the timer but this is a classical multithreading scenario.
Maybe i didn't get the point, it's possible...
Anyway, check PeekMessage in MSDN, can be helpful.
rechi
|
|
|
|
|
I see. Maybe I misunderstood your reference to threads. Would I implement the second thread using CWinThread ?
|
|
|
|
|
Dov Sherman wrote:
Would I implement the second thread using CWinThread?
Only if you see some special reason for it.
Basically, you have to write a worker thread's function so it's pretty much the same thing to use AfxBeginThread , CreateThread or _beginthreadex .
rechi
|
|
|
|
|
Bogdan Rechi wrote:
it's pretty much the same thing to use AfxBeginThread, CreateThread or _beginthreadex
One of the biggest mistakes of MFC programmers. These functions basically do the same but you can not interchange them at will - the reason lies in the memory allocation routines.
See http://www.microsoft.com/msj/defaulttop.asp?page=/msj/archive/s39cd.htm[^] and the VC technotes.
Holy Sh*t! I'm speechless. (hey, that's a first) Marc Clifton, The Lounge
|
|
|
|
|
Good point, thanx.
Do you know any simple case of misusing the thread creation routines? The article doesn't provide one and would be very interesting to see what exactly is wrong with MFC when using _beginthreadex .
rechi
|
|
|
|
|
Problems arise when you allocate memory in the thread but free it outside and vice-versa.
As long as you dont use CRT memory allocation its pretty save (no new/delete, allocators, etc).
Somewhere in the VC Technotes (MSDN) is an article about this topic, I think.
Holy Sh*t! I'm speechless. (hey, that's a first) Marc Clifton, The Lounge
|
|
|
|
|
Use a multimedia timer. It creates a timer on another thread and calls your callback function when the timer should be activated.
The WM_TIMER message has a low resolution and is not guarenteed to be processed. WM_TIMER messages have lower priority than WM_PAINT messages, and both of these messages are never entered into the message queue. These messages are generated by ::GetMessage() / ::PeekMessage() when and if the message queue gets emptied.
Therefore if you have a high volume of messages, you will have difficulty getting your WM_TIMER messages in a timely manner.
Good Luck
Build a man a fire, and he will be warm for a day Light a man on fire, and he will be warm for the rest of his life!
|
|
|
|
|
Why I'm asking this ?, I want to have an HTML view and map the commands to my application, like in:
Integrating DHTML into MFC Views
By Norm Almond
And I found this comment...
C# or the Winforms doesn't qualify for RICH desktop user interfaces, so I how no plans at the moment to port this over to .Net
Does it means that C# and .net is only situable for Data/Bussiness layers, and for the desktop layer... is just better to use MFC 7.0 ?
Thanks in advance, Greetings
Braulio
|
|
|
|
|
Please don't crosspost, or post to irrelevant forums. This should be in the C# forum.
And I would not use C# for a desktop app at this stage.
Christian
No offense, but I don't really want to encourage the creation of another VB developer.
- Larry Antram 22 Oct 2002
C# will attract all comers, where VB is for IT Journalists and managers - Michael
P Butler 05-12-2002
It'd probably be fairly easy to make a bot that'd post random stupid VB questions, and nobody would probably ever notice - benjymous - 21-Jan-2003
|
|
|
|
|
Mr. Grauss ...
I think you should do the same, why did yous posted in the Visual C++ Forum, questions about STL, when there is a forum for that my friend ? ( ATL / WTL / STL Message Board...).
Well...
|
|
|
|
|
Questions about STL are often bound to C++ ( this is even more the case if you're coding your app in C++). So basically, nobody minds when someone asks a C++ questions concerning STL's in the C++ forum (even more true if it is Christian). Whereas asking a C# question in the C++ forum is a sin.
~RaGE();
|
|
|
|
|
Braulio Díez wrote:
Mr. Grauss ...
Who is he ?
Braulio Díez wrote:
why did yous posted in the Visual C++ Forum, questions about STL, when there is a forum for that my friend ? ( ATL / WTL / STL Message Board...).
You'll find that the ATL/WTL/STL forum contains few STL questions, most of them get asked here, in the forum for the language that STL is implimented in. It's not remotely the same, and it's not really the way to conduct yourself after both cross posting, and posting in a place where your question is not *remotely* relevant, to try the snappy comeback routine with a reply as weak as that one.
I don't recall asking any STL questions, to be honest. Are you sure I was not answering them ? I'm not claiming to know everything about STL, but I do think that my usage of the STL has been within my limited understanding....
Christian
No offense, but I don't really want to encourage the creation of another VB developer.
- Larry Antram 22 Oct 2002
C# will attract all comers, where VB is for IT Journalists and managers - Michael
P Butler 05-12-2002
It'd probably be fairly easy to make a bot that'd post random stupid VB questions, and nobody would probably ever notice - benjymous - 21-Jan-2003
|
|
|
|
|
Ok... Graus... whatever, I would like to hear you just saying my name in right spanish XDDDD
Whatever... PLEASE POST THIS ON THE LOUNGE XDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD
|
|
|
|
|
:-OI want my application to run as soon as the system starts and should always remain in the memory. Do I have to make it as a service ???
This application has to interact with user OS and I/O .
OS on which it will run: Win 98/NT/2000 and XP
|
|
|
|
|
You should create your application as service.
Note: Win9X does not support services! Only Windows NT based Operating Systems!
A. Riazi
|
|
|
|
|
Hello,
I'm making a server/client program, and i want to sent a message map from my connection thread towards my main program if data has been received. how can i do this?
thanks,
Willem
Visual C++ N00P
|
|
|
|
|
Sir, how is it possible to terminate a hanged application from another VC++ application ?
C.R.Naik
|
|
|
|
|
Use this employed technique from this article[^] to find your hanged process then use process API function to kill it.
|
|
|
|
|
Note that in some instances it's actually impossible to kill a process, even on NT!
Some kernel calls are implemented in a way that they can hang (around) in kernel mode almost indefinitely. Trying to kill such a process is futile - it simply won't die. Also note that this design (though I'd personally call it a very serious flaw) prohibits you from even logging out - Windows wants to kill the process, which can't be killed. The only way to get out of this mess (except for waiting 365 years or so) is, really, a hardware reset.
|
|
|
|
|
I'm trying to write some html help for my app and have got stuck with the table of contents.
2 files seem to get generated by the compiler, a CHM and a CHI. Opening the CHM requires the CHI to be present as well, otherwise the table of contents is missing.
But of course, most apps only distribute a CHM. Am I missing something? How do I merge the TOC into the CHM file?
he he he. I like it in the kitchen! - Marc Clifton (on taking the heat when being flamed)
NEW: Awasu v0.7[^]: A free RSS reader with support for Code Project.
|
|
|
|