I'm NOT talking about the ingame console.

I'm talking about the little window that pops when when you first run Quake2 and Return to Castle Wolf that displays initialization and error messages.

I downloaded the Q2 source and was trying to find out how it was done. I searched for 'CreateWindowEx', but that is only used by the rendering DLLs. I searched for 'Dialog', no dialog functions and nothing in the RC files. The only thing I could find was AllocConsole.

- How is this used (doesn't it get it's own text window)?
- How do you get messages from a console into a window?

I would like to have a debug window like this for my own proggies.

Any help or suggestions would be greatly appreciated.

Maelstrom

:stupid:
Posted on 2002-01-12 20:17:40 by Maelstrom
Or was it Q3 when the debug window appeared?

Would explain why I can't find it.

Maelstrom
Posted on 2002-01-12 20:27:09 by Maelstrom
Yep, it appeared in Q3. It shouldn't be too hard to code anyway...
use a multiline editbox for the text.
Posted on 2002-01-17 07:34:20 by f0dder
f0dder

Thanks for the clarification, the thought came to me after I posted the original message, isn't it always the way!

Anyway, I did get the console working with a multiline editbox, but I have a question.

Lets say that I want to log error messages to the console and then terminate the app, I can log the message easy enough, but how do I keep the console (a dialogbox) active until the user decides to continue and terminate the app, so the user can see what the error was.

Hope you understand what I mean.

Any ideas

Maelstrom
Posted on 2002-01-18 18:33:12 by Maelstrom
Depends on how you set up your game loop and how the log box
is created. If you do it RegisterClass/CreateWindow style, there
should be no sweat.
Posted on 2002-01-19 12:59:22 by f0dder
Could you explain your suggestion in a bit more detail f0dder.

My game loop is as follows:



.while 1
invoke PeekMessage
.if message
invoke GetMessage
.break .if WM_QUIT
invoke TranslateMessage
invoke DispatchMessage
.endif
invoke DoGameFrame
.endw


Now when I detect an error I call my error function.



FatalError proc
invoke LogToConsole
invoke ExitProcess
ret
FatalError endp


Now I want the console to remain active until the user is ready to
exit so they can see what the error message was, any ideas?
What about a message loop in the error function specifically for
the console? or isolating the main message loop in a function
and calling it from the error function?

Oh, the console is a dialog box.

Maelstrom
Posted on 2002-01-19 23:18:59 by Maelstrom
If the console is a dialog box, isn't it closed before you start the
gameloop? Or are you using a modeless dialog box?

Anyway, the trick is to not call ExitProcess in your error function.
Shut down the game gracefully, and don't call DoGameFrame so
that the gameloop will only process the debug console messages.
Posted on 2002-01-20 05:10:42 by f0dder
Yes the dialog box is modeless.

I hope I understood you correctly

- Remove DoGameFrame from the message loop. So I should have a flag controlling whether the DoGameFrame is called?



.if all_ok
invoke DoGameFrame
.endif


- Remove ExitProcess from the error function. What is the best method then for gracefully shutting down the applicaiton? Do I send a WM_CLOSE?



.if WM_DESTROY
invoke ShutdownGfx
invoke ShutdownInput
...
invoke PostQuitMessage
.endif


Won't I have to exit the routine that the error was detected in and every other routine in the call chain until I get back to the message loop? If so, isn't this easily stuffed up if you modify a routine which previously returned no error but now does, or do you have all routines return an error code?

Sorry for all the stupid newbie questions.

Maelstrom

:stupid:
Posted on 2002-01-20 17:25:09 by Maelstrom
One way to handle it, yes, would be a "is the game running" flag
in the message loop. You could also remove the error console while
the game is running, and pop it up again only if an error occurs,
fill the listbox from memory, and call this in a dialog... there's a lot
of ways to go about it realy :).

Gracefully shutting down an application... well, since you're programming
it yourself, *you* have to think about a scheme to gracefully shut
it down - it will very much depend on what you're doing and how your
program is laid out. WM_CLOSE sounds pretty graceful to me, but
you might as well have a "oopsSeriousError" flag that the game
loop checks for.


Won't I have to exit the routine that the error was detected in and every other routine in the call chain until I get back to the message loop?

If you want to do it gracefully, yes. And yup, this can suck, lots of
return value error checking. Sucks to be a programmer, huh? ;).
I guess you could use some exception handling instead, but...
this is an advanced topic. I use exception handling very seldomly
myself... but it can sure come in handy.

Your questions aren't stupid, really. Issues like gracefully handling
errors aren't easy topics. I've seen it done wrong in a lot of software,
be it freeware or commercial. The more complicated your applications
get, the more weird code paths are possible, and you can end up
in some very hairy situations. Lay out your program wrong, and
the error checks you have to (constantly) do will end up killing you.
Yeah, I've learned the hard way that you should sit down and think
a bit about your program design if you're doing something a tad
larger than the usual little tool.
Posted on 2002-01-20 17:43:43 by f0dder