|
My whole horror with the Class CException is, that at the Understandable levels, it throws an exception, with a DWORD (QWORD?)number. That's quite simple, a Switch statement will sort what's going on. I can understand that concept. I also understand, that Different people writing different programs, will arrive at the Same exception numbers for different exceptions. I understand that this will be a problem when DLL's Meet.
Somehow, Microsoft devised a scheme which involved development time for derriving a new class from CException, for anything that may go wrong. I understand also that the reason for this is to be able to generate a distinct exception for each case, independent of exception numbering. At the same time, The link between Exception DWORD Numbers for exceptions, and Existing or New derrived exception classes is not very clear in the documentation.
A Point in case is, you use catch(...)in your sample code!as you know, this catches ALL Exceptions. In a Real life situation, how do you only catch those you are interested in and pass the rest on to some other handler.
LateNightsInNewry
|
|
|
|
|
It's actually Microsoft sample code. It worked well for my test because I could put a breakpoint
in the catch block and I could immediately see the exception class without knowing what I'd get.
In real-life, IMO, a catch(...) is pretty useless. How can you possibly know how to proceed
or if it's even safe to proceed after catching an unknown exception?
The CException class is an abstract base class that provides one interface to get an error
message. If there's a DWORD involved, it's in a derived class, and is generally added so one
has a better context to detect why the exception occurred. I'm not sure what the DWORD is you're
referring to  The variables added by the MFC exception classes are well documented.
With new CException-derived classes, you're on your own to add what you want.
In real life, AFAIK, exceptions shouldn't be used for simple error handling. Returning an error
code is faster and simpler.
Constructors can't return error codes so throwing an exception is the only way to indicate
failure.
Using MFC, sometimes it's not a choice. The database classes are a good example. Those
exceptions must be handled, and generally it's safe to continue after handling them, and they
also provide detailed error information for logging and/or deciding how to proceed after they
occur.
Hmm, I'm rambling pointlessly 
Mark
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
|
|
|
|
|
hi all i m using this line in my outlook addin project but it give error
"unresolved external symbol _IID_IMAPISession", so i search on net for that value,i foud one but when assign that value its as string when i assign that value to a CString object then it gives error cannot covert Cstring to struct _GUUId,
it tried this
#define IID_IMAPISession= "00020300-0000-0000-C000-000000000046"
this but stil same error
struct _GUID IID_IMAPISession= 00020300-0000-0000-C000-000000000046;
tell me what to do.
CComPtr<iunknown> punk;
spMailItem->get_MAPIOBJECT(&punk);
punk->QueryInterface(IID_IMAPISession, (void**)&m_pSession);
tell me what to so that it works i m stuck to that.
Regards.
Tasleem Arif
|
|
|
|
|
You need to include MAPIguid.h I believe.
Then you can use IID_IMAPISession.
Mark
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
|
|
|
|
|
still same problem.
Regards.
Tasleem Arif
|
|
|
|
|
An unresolved external means you're missing a library.
I don't know what library you need to link to but I'll take a guess that you need to add
MAPI32.lib to your project.
Mark
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
|
|
|
|
|
thanks, i managed to solve that erro, i was including MAPI32.lib,but i was using extended MAPI function such MapiLoginEx,Problem was that i was confused with MAPI and Extended MAPI Dll's. i searched a lot on internet some people were saying MAPI32.dll is extended MAPI some MAPIX.dll is extended MAPI, and some MAPI32x.dll is extended MAPI, i posted question on CP but found no reply.
i replaced that line with IID_IUnknown and it worked fine. Thanks for ur kind answers.
Regards.
Tasleem Arif
|
|
|
|
|
Sorry for the newbie question.
I downloaded the platform sdk from Microsoft to get the GDI+ header files and now I need some documentation. Is there any in the 2 gigabytes of krap they dump onto your system? MSDN.com is awfully slow, and I don't want to go to the World Wide Web every time I want a parameter description. There is a 'precompiled help file' in the platform sdk, 'gdicpp.hxs', and it contains GDI+ terms. However, I don't know how to open it . Drag it onto VC++ express, and it doesn't know how to open it either.
|
|
|
|
|
In the SDK docs...
Contents (tab)/Graphics and Multimedia/GDI+
Mark
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
|
|
|
|
|
I don't know where that is - what application do I need to open? I've downloaded VC++ express and the PlatformSDK for windows server R2 2003. Im running Windows 2000.
What application opens the SDK docs?
In VC++ express, if you search for GDI+, it goes to the internet and comes back and says it didn't find anything.
I normally use Dev-C++. To me VC++ is such a joke. You open it, and immediately it starts searching the internet for "News" or what-not, even though you didn't ask for it.
|
|
|
|
|
Force Code wrote: What application opens the SDK docs?
When I installed the PSDK, a program folder was created called "Microsoft Platform SDK for
Windows Server 2003 R2". In that folder is a "Platform SDK Documentation" shortcut.
Force Code wrote: In VC++ express, if you search for GDI+, it goes to the internet and comes back and says it didn't find anything.
That's because the express edition is free. You get what you pay for 
Force Code wrote: To me VC++ is such a joke. You open it, and immediately it starts searching the internet for "News" or what-not, even though you didn't ask for it.
You can turn that off - go to Tools menu, Options.../Environment/Startup and select the
appropriate item in the "At startup" combobox.
Mark
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
|
|
|
|
|
Mark Salsbery wrote: When I installed the PSDK, a program folder was created called "Microsoft Platform SDK for Windows Server 2003 R2". In that folder is a "Platform SDK Documentation" shortcut.
I have "Microsoft Platform SDK for Windows Server 2003 R2", but not "Platform SDK Documentation" shortcut. Did you have to do anything to "install" the Platform SDK after downloading it? There's a setup directory, but no setup.exe. AS I said, it downloaded gigabytes so I don't know what I'm missing.
|
|
|
|
|
|
Are these two (handling keyboard/mouse input and handling the graphics display) typically done in separate threads or in a single thread? I've been considering doing them in separate threads so the input is always responsive, however, that may not be the best idea, given how often I will have to synchronize between the two.
Advantages of using only a single thread:
-input polling is combined with the graphics loop, so there is less overhead as the loop takes longer to execute (advantage for single core processors but a disadvantage for multi-core processors)
-no synchronization required
Disadvantages of using only a single thread:
-input may be required for a variety of components, such as handling combat and other character states and reliance on a combined (input + graphics) cycle can slow down the processing of these other components
-will not scale as well with multiple cores
Any suggestions? This is my first time venturing into game engine development (from scratch, because it's more fun and you learn more that way).
|
|
|
|
|
This is purely off the top of my head, but it seems you can rely on window messaging for most things. Windows generates messages for mouse movement etc, which you set up handlers for. You can set up a timer to cause windows to send timer messages at certain intervals as well, which is useful for updating the game state. Each character could have a thread, but that's not strictly necessary. They could just be in a list and every 1/100 of a second you update the next one (when you receive a WM_TIMER msg from windows). Threads are mandatory for background computation that would otherwise freeze the system.
|
|
|
|
|
I was thinking of using a key array (of bools) and catching WM_KEYDOWN / WM_KEYUP to change the states of the keys from the input thread, then sending the states to the graphics thread. The input thread would have the WndProc function, whereas the graphics thread would simply check the local key array (in a while loop) to determine what happens.
Basically, it would look sort of like this:
WndProc (which runs in the input thread) catches WM_KEYDOWN where the key is VK_ESCAPE. The input thread sets key[VK_ESCAPE] = true. The graphics thread has a while loop that checks for VK_ESCAPE, and if true, it will return the thread (quit), if it sees another command such as the movement keys, then it will draw the next frame.
|
|
|
|
|
Having a while loop in the graphics thread seems pointless. You can imagine walking out to your mailbox opening it, closing it, walking back inside, and doing the same thing over and over again continuously until the mailman arrives. You accomplish nothing by putting this in a seperate thread. When you get the WM_KEYDOWN message just call the appropriate code to update the games state - it doesn't have to be in a seperate thread. If you can't update the games state fast enough to avoid slowing down user input, it means you can't update the game state fast enough to begin with (if that's clear). If its a single processor, seperate threads don't magically give you more speed. If its a seperate grapics processor, that's another matter I guess.
A seperate thread would be for a situation where a computation literally took several seconds to complete or something. Presumably you can animate your game fast enough to keep up with user input.
---------------------
Let me be clearer:
IF you hit some key, presmuably all you will do is change the value of some variable in a character object for example, which will be processed the next time a WM_TIMER message is received. Its better for the graphics to do nothing until it receives a timer message. Really, the timer is to slow things down. You'll set it at a certain level and everyone will be running around too fast.
-- modified at 14:59 Monday 18th June, 2007
|
|
|
|
|
If you can't update the games state fast enough to avoid slowing down user input,
it means you can't update the game state fast enough to begin with
Hmm... you do have a point.
Thanks.
|
|
|
|
|
Let me just add something:
Depending on your situation, its possible you could have a seperate thread for graphics. But you definitely wouldn't just sit there in a while loop. You would have shared access (via critical sections, mutexes or whatever) to data, which the input process would update and the graphics thread would check at set intervals. If the graphics thread has so much to do that is must run continuously without interruption, then it should have its own thread, it will check for updated data periodically, but shouldn't just be in a loop doing *nothing* but checking for data updates.
|
|
|
|
|
Then my question is, how do you explain the current crop of games today? They don't update the frame buffer synchronously. They won't be trying to send you 60 frames per second all the time. On heavier scenes, the frames may drop down to the 20s, and on lighter scenes, they may jump up to 150. What else, besides a while loop displaying graphics would do this?
|
|
|
|
|
Cyrilix wrote: Then my question is, how do you explain the current crop of games today? They don't update the frame buffer synchronously. They won't be trying to send you 60 frames per second all the time. On heavier scenes, the frames may drop down to the 20s, and on lighter scenes, they may jump up to 150. What else, besides a while loop displaying graphics would do this?
To make sure I understood correctly, I thought you were saying your graphics thread would literally have nothing to do until it recieved some sort of input, so it would do nothing but check an inbox, continuously, billions of times a second, until it recieved a message. This is pointless processing, even if you put in a seperate thread. If you're running a seperate *process* as opposed to thread, sometimes that sort of wait loop is necessary, but then you call Sleep() with each iteration to avoid wasting the CPU. A windows application behind the scenes has a message loop, but when it calls GetMessage, windows doesn't return until there is actually a message, so the calling process isn't wasting time continuosly checking.
AS far as modern games, I didn't think you were developing for PlayStation X or some specific game processor, but they can ascertain the game state (e.g. how many frames to display at a given time), without the sort of loop you're talking about.
Just to reiterate, I think the way to go for game state updates is a windows timer (don't know what the precise synax in MFC is).
|
|
|
|
|
Oh no, what I meant was... the graphics thread would be in a while loop constantly filling the frame buffer and putting it to the screen. On every iteration of filling this frame buffer, it would have to draw a bunch of shapes, and a set of variables that track your movement (say, x, y, z, and rotate), would determine how to redraw the scene. It would have to check these variables on every iteration. Basically, I'd have to know the translations and rotations that affect my camera every time I redraw.
The code would be very similar to what is on Nehe's OpenGL tutorial: Link to source
Here is the code that I'm pointing to, specifically:
while(!done)
{
if (PeekMessage(&msg,NULL,0,0,PM_REMOVE))
{
if (msg.message==WM_QUIT)
{
done=TRUE;
}
else
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
}
else
{
if (active)
{
if (keys[VK_ESCAPE])
{
done=TRUE;
}
else
{
DrawGLScene();
SwapBuffers(hDC);
}
}
if (keys[VK_F1])
{
keys[VK_F1]=FALSE;
KillGLWindow();
fullscreen=!fullscreen;
if (!CreateGLWindow("NeHe's OpenGL Framework",640,480,16,fullscreen))
{
return 0;
}
}
}
}
MODIFIED:
I guess my question is -- you would consider this bad design?
-- modified at 16:07 Monday 18th June, 2007
|
|
|
|
|
The code sample you provided is in a loop with a PeekMessage. If any messages for the application are pending it processes those before going back to frame updates.
Here was your proposed design:
Cyrilix wrote: I was thinking of using a key array (of bools) and catching WM_KEYDOWN / WM_KEYUP to change the states of the keys from the input thread, then sending the states to the graphics thread. The input thread would have the WndProc function, whereas the graphics thread would simply check the local key array (in a while loop) to determine what happens.
Basically, it would look sort of like this:
WndProc (which runs in the input thread) catches WM_KEYDOWN where the key is VK_ESCAPE. The input thread sets key[VK_ESCAPE] = true. The graphics thread has a while loop that checks for VK_ESCAPE, and if true, it will return the thread (quit), if it sees another command such as the movement keys, then it will draw the next frame.
You weren't relinquishing control in anyway to process application messages. However, I'm not entirely clear on your design, because your last statement seems to say that movement in the game is only triggered by user input, whereas I thought there would be game animation regardless of user input.
But as to whether the code sample you provided is bad design, I will say I've never had much use for PeekMessage. In the code sample, you could just take the PeekMessage portion out, and put the remaining code in its own thread, where the OS itself would interrupt it as necessary. The GetMessage loop in the main thread would continue to handle application messages. Maybe you can tell me if I'm missing something
l
|
|
|
|
|
There will have to be game animation regardless of user input. When I say "if it sees another command such as the movement keys, then it will draw the next frame", I mean that if it sees that you're holding down the movement key to move in direction x, it will increment an x counter (based on how long you've been holding down the key). The bit of code above that I posted will check this counter every time a frame is drawn (DrawGLScene()) and translate the camera x units from the (0, 0, 0) position (or rather, translate the objects -x, since it's the objects that are moving, and not you). The main point is, it uses a while loop to constantly spit out frames to the screen. I thought you were advocating against using the while loop and producing frames only when you receive a signal, but it seems like you're not against doing so.
We may have misunderstood each other.
|
|
|
|
|
I have a feeling I may not be completely clear to you.
In the code sample, he has something he feels he has to do continuously. In that instance just create a seperate thread, and do it continously, and let the OS interrupt - No need to call PeekMessage. However, this code doesn't create a seperate thread but is in the main thread, that's why PeekMessage is being used. (You OTOH were saying you wanted to create a seperate thread for graphics updates.) However, in your case, you seemed to say you had nothing to do in the Graphics thread until some user input was received, so you would have a loop to just check for it continuously. That's a complete waste.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
