SFML community forums
General => Feature requests => Topic started by: efeXor on December 01, 2008, 07:05:30 pm
-
Not sure if SFML already has it, i'm still kind of new to it, but it would be nice to be able to display message boxes that pop up in your SFML window like say if you have an error or something. (Yes i know you can do it using the winapi but it requires alot of stuff being setup).
-
This would be quite hard to implement practical and universal.
SFML is used in a lot of different enviroments with a lot of different window handlers. Think of it, there is no "global" way of making a box on them all. Each system has to have a hand written implemention, not to mention the intergration with QT and such.
And then also, this would distract the focus from a simple and fast multimedia layer and turn into something bloated. There is no universal way for each project. I know people using it for games, visualising studies and such.
Get developing with Win32 or QT is my advice.
-
(Yes i know you can do it using the winapi but it requires alot of stuff being setup).
win32 api message box is not that hard to do :)
#define WIN32_LEAN_AND_MEAN
#include <windows.h>
int main(void)
{
MessageBoxA(NULL, "text", "Title!!", MB_OKCANCEL | MB_ICONEXCLAMATION)
return 0;
}
-
No. It will not show in your application :(
-
If you're trying to display a message in your SFML canvas, simply draw a rectangle Shape and then draw a String containing a message inside of the rectangle.
-
You can also write a thread class. It isn't as difficult as it sounds ;)
Here's a part of mine. (I'm also a beginner and so don't know if this is a good solution. But so, you don't need to use the WAPI)
#include <SFML/Graphics.hpp>
#include <string>
class EMessage : public sf::Thread
{
public:
//variables
std::string EMessage;
protected:
//methods
virtual void Run()
{
bool running = true;
sf::RenderWindow ErrWindow(sf::VideoMode(600, 130, 32), "ERROR!", sf::Style::Close);
sf::String ErrMessage;
ErrMessage.SetText(EMessage);
while(running)
{
while(ErrWindow.GetEvent(Event))
{ /* Button Click, ...*/ }
ErrWindow.Draw(ErrMessage);
ErrWindow.Display();
}
}
},
-
Actually, a cross-platform message box (for the really bad/unrecoverable errors) would be nice to have.
-
What about std::cerr?
-
Besides, a message box can rather easily be implemented about a separate window (and perhaps threads).
I don't see any need to change SFML in this point.
-
What about std::cerr?
Only works if you have one of those ugly console windows ;-)
-
What about std::cerr?
Only works if you have one of those ugly console windows ;-)
Which you mostly have for debugging, I guess.
-
What about std::cerr?
Only works if you have one of those ugly console windows ;-)
Which you mostly have for debugging, I guess.
Console windows are fine for debugging. They are not fine for informing the end-user about an error.
@thread
IMO, this should be considered a GUI function. GUIs can be implemented in SFML and themed according to the game/multimedia project you are designing.
If you are designing an SFML and want a standard windowing environment, look up how to use an appropriate windowing setup in the tutorials section of the Wiki.
-
What about std::cerr?
Only works if you have one of those ugly console windows ;-)
Which you mostly have for debugging, I guess.
Console windows are fine for debugging. They are not fine for informing the end-user about an error.
std::cerr is not the console. It's a standard stream that can be redirected to whatever you like; the console is just the default output.
-
Console windows are fine for debugging. They are not fine for informing the end-user about an error.
Exactly.
@thread
IMO, this should be considered a GUI function. GUIs can be implemented in SFML and themed according to the game/multimedia project you are designing.
If you are designing an SFML and want a standard windowing environment, look up how to use an appropriate windowing setup in the tutorials section of the Wiki.
I'm talking about a platform independent error message box. Its a bad idea to do this in the GUI (as it might be a part of the GUI that caused the error). Bad errors happen. Even after tons of debugging and testing.
std::cerr is not the console. It's a standard stream that can be redirected to whatever you like; the console is just the default output.
I know, but of what use would that be in this case? So I might be able to log the error. But should the app simply close on a fatal error, without even pointing out to the user what happened? It should display a message box or something similar... and these aren't compatible with streams.
-
It should display a message box or something similar... and these aren't compatible with streams.
Why not? You can redirect the stream to whatever you want, even message boxes.
The good thing with standard streams is that they don't care about where they write, they just send their content to their streambuf, which can be specialized to write to anything that support text output.
-
It should display a message box or something similar... and these aren't compatible with streams.
Why not? You can redirect the stream to whatever you want, even message boxes.
The good thing with standard streams is that they don't care about where they write, they just send their content to their streambuf, which can be specialized to write to anything that support text output.
Technically it might be possible. But semantically it would probably turn out to be nonsense. When do you display the message box? When a newline occurs? What about multiline messages? Also, when is the stream flushed (and the message box actually displayed) etc.
EDIT:
And this would still require a platform-dependent message box ;-)
-
Technically it might be possible. But semantically it would probably turn out to be nonsense. When do you display the message box? When a newline occurs? What about multiline messages? Also, when is the stream flushed (and the message box actually displayed) etc.
The stream is flushed and the message box displayed, when... well, the stream is flushed ;)
I mean std::cerr << std::flush (which is also called by std::cerr << std::endl). A multiline message can then be displayed using '\n'.
EDIT:
And this would still require a platform-dependent message box
But then it's not mandatory to be implemented in SFML ;)
-
Technically it might be possible. But semantically it would probably turn out to be nonsense. When do you display the message box? When a newline occurs? What about multiline messages? Also, when is the stream flushed (and the message box actually displayed) etc.
The stream is flushed and the message box displayed, when... well, the stream is flushed ;)
I mean std::cerr << std::flush (which is also called by std::cerr << std::endl). A multiline message can then be displayed using '\n'.
not exactly. streams can be flushed at any time, not only when flush or endl are used!
EDIT:
And this would still require a platform-dependent message box
But then it's not mandatory to be implemented in SFML ;)
but still very useful ;-)
-
not exactly. streams can be flushed at any time, not only when flush or endl are used!
How (or when)?
but still very useful
Still out of scope, in my opinion ;)
-
not exactly. streams can be flushed at any time, not only when flush or endl are used!
How (or when)?
When the buffer is full. (?)
But std::cerr has no buffer so std::cerr << std::flush does nothing.
-
But std::cerr has no buffer so std::cerr << std::flush does nothing.
What do you mean?
-
not exactly. streams can be flushed at any time, not only when flush or endl are used!
How (or when)?
When the buffer is full. (?)
Yes.
But std::cerr has no buffer so std::cerr << std::flush does nothing.
Not quite sure what you mean either
-
I would like to see this too.
The only way to have such a thing would be to use an additional GUI library but this is way to heavyweight just for showing an error.
Showing errors in errordialog is at least on windows standard and not inconvenient on other plattforms so I think it really is the best way to inform the user that an error occured.
You could make an errorfunction in the Systemlib or wherever which shows an messagebox, logs the error and so on, I think this would fit sfml much better then adding a messagebox class since a general messagebox would be a gui element..
-
One week later... :roll:
But std::cerr has no buffer so std::cerr << std::flush does nothing.
What do you mean?
I mean this : http://www.dinkumware.com/manuals/?manual=compleat&page=iostream.html#cerr
The object controls unbuffered insertions to the standard error output
-
Ok, but it doesn't matter as I'm planning to use my own ostream instance for SFML instead of std::cerr ;)