I'm using the SDL library in my project and I'm working on a Windows platform.
When I'd decided to move my project to SDL 2, I encountered a problem:
There was an option in SDL 1.2 to print output from stdout/stderr into the console window, rather than to files by defining a NO_STDIO_REDIRECT macro. However, I haven't found that macro in SDL 2.
Is there a way to print SDL 2 output to the console instead of the standard files?
I suspect that NO_STDIO_REDIRECT is no longer part of SDL2.
You should use instead SDL_Log and all the other related functions to log messages from within your application.
Then you can use SDL_LogSetOutputFunction to:
replace the default log output function with one of your own
Note that you can gracefully handle any given category or priority, being the prototype of the handler the one below:
void SDL_LogOutputFunction(void* userdata,
int category,
SDL_LogPriority priority,
const char* message)
Please, refer to the linked documentation for further details.
Related
I need to make a windows console application file explorer using c++ , but I couldn't figure out how to use functions to display files nor how am I going to make it look like knowing that console application doesn't support buttons or displaying lists , specially that the project must be based on windows.h library. any tip, advice or suggestion may be helpful , thank you !
Have a look at http://www.martinbroadhurst.com/list-the-files-in-a-directory-in-c.html and scroll down to method 4. There you can see a possible implementation of a read-directory function. You should store a default start path, implement some console arguments as commands, then, whenever the user writes a command (for example goUp) ,change the path accordingly (in this case, remove the last foldername), call the function, which reads the directory, again and output all files in that folder.
I'm running an OpenGL program, and have setup a basic error reporting system which I'm using to call a function which uses fprintf and prints to stderr. On top of this, I have several fprintf's inline with the rest of my code.
I also have a fstream setup which allows me to print directly to the log file of my choice. However I don't want to duplicate every line in which I use fprintf to include printing to the log.
Is there a way I can set my stderr and stdout to also point to the log, or can I create my own?
I'm seeing other questions like this and this, and the answers seem to use a tee and wtee function. The second one states that tee only works on UNIX. Since I'm doing this on Visual Studio 2015 on Windows, so this isn't going to be an option. However I am trying to cross-platform my application, so I'm looking for a cross-platform solution. I'm not too worried about Linux at this stage, as long as it works on MacOS and Windows.
I made a program in c++ (visual studio 2010) that looks for serial com ports and compares their friendly names with defined text. When there is a match that port is opened/connected and serial communication starts.
The program notifies the user when a com port is found, whether the connection was successful or not and if the data send was successful or not and other useful information. The program uses cout to notify the user.
I want to replace console output window with windows form but cant find much resources online on how to do this. To illustrate, I want this:
To become this:
I included form1.h and other files and tried replacing cout with below line but code is not compiling:
Form1::textBox1->Text = L" Text I want to display";
Can anyone explain how to use textBox1, or a tutorial for this?
"I included form1.h" - You can't just grab random files and hope it works. That is not how C++ works, or computers in general.
How then do you do something like this? The Standard Library provides std::cout and Visual Studio by default includes the Standard Library, so using it is fairly easy. But for graphics, you will need another library. I recommend Qt, if only because there are good tutorials for beginners.
So I finally did achieve the functionality I described above in my question and thought I should post my findings here.
To convert my code from console output to Windows Form I basically had to migrate from c++ to C++/cli.
holowczak.com has a great tutorial on how to get started with windows form (c++/cli) in visual studio.
Next if there is any busy looping(like infinite while-loop) in your c++ code then you would need to run that busy loop on a separate thread or the program can hang. Dr.Dobb's tutorial on how to create and mange threads in c++/cli, can help a lot.
Finally, if you need to access resources (such as textbox and other controls) of windows form from another thread then a thread-safe call has to be made. Microsoft's "HowTo:Make thread-safe call to windows Form controls" explains how the invoke method can be used for updating textbox from another thread.
I'm working on a windows application in C++, and I'd like to use cout for debugging purposes.
It seems that the effects of cout are hidden, is there a configuration option that will allow a console window to open with my debug information?
You have a couple of reasonable options. One is to rename your entrypoint from WinMain to main, so it'll be built as a console application. That can still use things like RegisterClass and CreateWindow just fine.
The obvious alternative would be to use OutputDebugString instead of cout. The output from that will show up in a debugger, or any number of programs built specifically to display what it produces (basically mini-debuggers that just don't provide other debugging capabilities).
A third solution I'd consider less reasonable is to call AllocConsole to allocate a console, then write to it. If you don't mind doing all your writing with Windows-native console functions (WriteFile, WriteConsoleOutput, etc.) that's fine. Unfortunately, it won't initialize the C++ streams to work with the console, so you'll need to either open file streams pointing the console, or else find and use the (undocumented) function that initializes the streams library for the console. While this can be made to work, you end up doing extra work to write non-portable code, and little (if any) advantage to make up for it (and in this case, "non-portable" can include not even working with other versions of the same compiler, at least if you invoke the library's initialization function).
To add a console window to a GUI application, you can use the AllocConsole API.
Then you just need to open the special file name "CONOUT$" and attach your streams to it (cout, cerr, etc)
See this explanation on MSDN.
I believe the accepted answers are actually not what you are looking for. You say you need it only for debugging, not for release. Your best options are:
a) redirect stdout and stderr to a file and then inspect the file. This you can set in the VS project Properties > Configuration Properties > Debugging > Command Arguments: you should enter >out.txt 2>&1. This will output both stdout and stderr to out.txt
b) set your debug (you say you need it only for debugging) configuration Properties > Configuration Properties > Linker > System > SubSystem to Console (/SUBSYSTEM:CONSOLE). Then you can run the project with F5, but it will hide the console window when your application finishes. If you run it with Ctrl+F5 (but then you will not have debugger attached), then it will not be hidden.
The simplest way to do this is to start a Console application from scratch:
In VisualStudio, File > New Project. Select Win32 Console Application. Select various options and create the new project.
Note that although it says Win32 Console Application, you can create x64 builds without restriction.
At this point you have an application shell. If you already have code and you want to bring it in to this new project, simply do Project > Add Existing Item... and select the files to include in the project.
Managing a console from a GUI program is horribly messy, and I suggest you do it another way. For instance, if you need to see the messages in real time, display them in a window; if not, write them to a file.
just use OutputDebugString() but remember to either set your character set to multibyte, or if you don't want to do that, you could write your code like this:
// with multibyte character set:
OutputDebugString("Failed to do something");
// without multibyte character set:
OutputDebugString(L"Failed to do something");
I'm currently trying to re-write my binder between Ogre and SDL in my game engine. Originally I used the method outlined in the Ogre Wiki here. I recently updated my version of SDL to 1.3 and noticed the "SDL_CreateWindowFrom()" function call and re-implemented my binder to allow Ogre to build the window, and then get the HWND from Ogre to be passed into SDL.
Only one window is made and I see everything renders properly, however no input is collected. I have no idea why. Here's the code I am currently working with (on windows):
OgreWindow = Ogre::Root::getSingleton().createRenderWindow(WindowCaption, Settings.RenderWidth, Settings.RenderHeight, Settings.Fullscreen, &Opts);
size_t Data = 0;
OgreWindow->getCustomAttribute("WINDOW",&Data);
SDLWindow = SDL_CreateWindowFrom(&Data);
SDL_SetWindowGrab(SDLWindow,SDL_TRUE);
I've tried looking around and there are a number of people that have done this to one degree of success or another(such as here or here). But no one seems to comment on handling the input after implementing this.
I originally thought that maybe since SDL does not own the window it wouldn't collect input from it by default, which is reasonable. So I searched the SDL API and only found that one function "SDL_SetWindowGrab()" that seems to relate to input capture. But calling that has no effect.
How can I get SDL to collect input from my Ogre-made window?
It has been a while, but I figured I would put in the answer for others that may need it. It turned out to be a bug/incomplete feature in SDL 1.3. The "CreateWindowFrom" method wasn't originally intended to be used exclusively as an input handler. At the time of this writing I know myself and another on my team wrote patches for Windows and Linux that permitted this use to work and submitted those patches to SDL.