🔒 Locked
Log window?
Advertisement
Original Post
Hello.
I want to open a ''log'' window, to dump there all messages from my dx application, instead of using messagebox().
It has to be a simple text window, done in any way, just with continuous scrolling refresh of new added lines.
I am not expert of windows programming, so have patience!
I suspect it is a trivial thing...
Thanks,
Michele.
AllocConsole() will open up a console window. You can then use:
HANDLE hOutput = GetStdHandle( STD_OUTPUT_HANDLE );
DWORD dw;
char text[] = "This is my console output";
WriteFile( hOutput, text, strlen(text), &dw, NULL );
Of course, you''d probably have this wrapped in a LogPrint function or some such. Another method is, once you''ve
AllocConsole''ed, do this:
freopen("CONOUT$", "w", stdout);
and you''ll then be able to use the normal
printf methods to write to it. codeka.com - Just click it.
It works, but it is monster-slow: due to its pseudo-dos work i pass from 30 to 12 fps, jusst making a printline per frame...
I''ve seen consoles that are not dos windows, but look more like application windows ( withs the same background color, font, etc) how do i do it? and, is it faster?
Thanks!
Michele.
I''ve seen consoles that are not dos windows, but look more like application windows ( withs the same background color, font, etc) how do i do it? and, is it faster?
Thanks!
Michele.
It''s pretty easy to make a new window. It would take a while to explain here, but just look up CreateWindowEx in MSDN and you should be able to figure it out. You''ll need to create the log window, and then a child of that window to actually display the text (use the pre-defined "edit" class).
I''m not sure how to go about adding text to it though. I know you can use SetDlgItemText() to give it a string, but that will overwrite whatever''s already there. I guess you could just keep a big string in memory and every time you add something to it, if it''s longer than the maximum length, shift everything back so it just drops off if it gets too big. There''s probably a way to make Windows deal with it for you though, but I''m not very experienced in Win32 programming either.
-Deku-chan
DK Art (my site, which has little programming-related stuff on it, but you should go anyway^_^)
I''m not sure how to go about adding text to it though. I know you can use SetDlgItemText() to give it a string, but that will overwrite whatever''s already there. I guess you could just keep a big string in memory and every time you add something to it, if it''s longer than the maximum length, shift everything back so it just drops off if it gets too big. There''s probably a way to make Windows deal with it for you though, but I''m not very experienced in Win32 programming either.
-Deku-chan
DK Art (my site, which has little programming-related stuff on it, but you should go anyway^_^)
Getright doesn''t grab it! I''ll try later..
anyway, maybe it is important WHEN you make prints. i make them just-just before rendering and slows down. But i need it there!
it is for sure slow because if you make 2 programs that write down just a,b,c,..,z,a,b,c....and so on, but one on console, the other on HD file, and let them run for a while, the second one will ''produce'' more. Output window is slow. At least in DOS mode.
Bye,
Michele.
anyway, maybe it is important WHEN you make prints. i make them just-just before rendering and slows down. But i need it there!
it is for sure slow because if you make 2 programs that write down just a,b,c,..,z,a,b,c....and so on, but one on console, the other on HD file, and let them run for a while, the second one will ''produce'' more. Output window is slow. At least in DOS mode.
Bye,
Michele.
Does it have to be displayed while your app is running, or is it intended just to export certain details of your programs functionality?
I normally send the debugging functions to hell, define a global ofstream object and send anything I want to track to a text file for viewing at my leisure.
ofstream logfile("log.txt");
// Anywhere in app
logfile << "Aiaiaiiaiaiaiaiaaiai thar be data" << endl;
I normally send the debugging functions to hell, define a global ofstream object and send anything I want to track to a text file for viewing at my leisure.
ofstream logfile("log.txt");
// Anywhere in app
logfile << "Aiaiaiiaiaiaiaiaaiai thar be data" << endl;
Don''t knock simple but effective methods for exporting data, in the world of DX any simple solutions are welcome IMO
I''ve been programming C++ for years and still prefer that method over any other for tracking events, lol.
To properly explain how to create a Window and edit control within it and how to add lines would take too long. Do a search for some Windows programming tutorials and as soon as you figure out how to create a Window and a multi-line edit control (not difficult), you''ll have a solution. Whether it causes any slow downs is based on how you implement it and when you send data. If your app is full screen, obviously this is out the window anyway (pun intended :D).
The other alternative to create on-screen text display is to create a text stack and render it on top of your scene. I used this once to create a console in which I could enter commands as well as retrieve values. I used the CD3DFont class and stored an array of strings. Then when rendering them I simply did so down the left side of the screen. There was no scroll bars to see old messages though.
However note that a lot of CD3DFont text on screen will also have a performance impact, although its not that severe. I linked the console to a key that toggled whether or not to render it, thus could turn it off and on at runtime (using a bool flag).
Basically if you can render a string to a D3D window, it should be pretty easy to design a stack/render system for your own needs.
To properly explain how to create a Window and edit control within it and how to add lines would take too long. Do a search for some Windows programming tutorials and as soon as you figure out how to create a Window and a multi-line edit control (not difficult), you''ll have a solution. Whether it causes any slow downs is based on how you implement it and when you send data. If your app is full screen, obviously this is out the window anyway (pun intended :D).
The other alternative to create on-screen text display is to create a text stack and render it on top of your scene. I used this once to create a console in which I could enter commands as well as retrieve values. I used the CD3DFont class and stored an array of strings. Then when rendering them I simply did so down the left side of the screen. There was no scroll bars to see old messages though.
However note that a lot of CD3DFont text on screen will also have a performance impact, although its not that severe. I linked the console to a key that toggled whether or not to render it, thus could turn it off and on at runtime (using a bool flag).
Basically if you can render a string to a D3D window, it should be pretty easy to design a stack/render system for your own needs.
I wrote a handy-dandy log file making class. It will create a file (you specify the name and extension) and it will output to the file whatever you tell it to. If anyone wants the source, just say so! Its not all that long or complicated.
Moe''s Site
Moe''s Site
What the hell is OutputDebugString?
Please, explain, if i posted a question is because
1)i know that there''s a LOT of material around but i have little time. If someone has the solution i ask, post it (code welcome).
If not, thanks the same.
2)Suggestions have to be useful, or don''t post at all: if i say
"use CoolCall(), it''s very COOL" i have to say what you need to use it and where you find it. Unless is no help at all.
Thanks,
Michele.
Please, explain, if i posted a question is because
1)i know that there''s a LOT of material around but i have little time. If someone has the solution i ask, post it (code welcome).
If not, thanks the same.
2)Suggestions have to be useful, or don''t post at all: if i say
"use CoolCall(), it''s very COOL" i have to say what you need to use it and where you find it. Unless is no help at all.
Thanks,
Michele.
Open MSDN and type "OutputDebugString"
As for what''s wrong with it, well, you don''t always have the debugger running...
codeka.com - Just click it.
As for what''s wrong with it, well, you don''t always have the debugger running...
codeka.com - Just click it.
quote:
Original post by Dean Harding
Open MSDN and type "OutputDebugString"
As for what''s wrong with it, well, you don''t always have the debugger running...
But you don''t have to have the debugger running...
I just found SysInternals DbgView, which captures anything output by OutputDebugString() (and some others) and shows it in a window. It can filter the output and record it to a file. It can even send the debug stream across a network to another machine running DbgView, which is nice :D
Ah, but that requires that you have DbgView running. The times that debug output is most useful is on a user''s computer where you''re trying to figure out what''s happening. It''s easier to say "just send me the log file" than it is to say "install DbgView and then send me the log file".
Of course, the discussion is actually about a debug window, as opposed to a debug file, which is really only good when you''re debugging something specific...
codeka.com - Just click it.
Of course, the discussion is actually about a debug window, as opposed to a debug file, which is really only good when you''re debugging something specific...
codeka.com - Just click it.
Topic Locked
This topic has been locked by a moderator. New replies are not allowed.
Sign in to reply to this topic.
Advertisement
