[JohnGreek]

'MessageBox' in namespace 'tgui' does not name a type

Under windows - MinGW the class name tgui::MessageBox conflicts with MinGW's MessageBox Winapi defines.
The solution i tried is the following:

1. Go to winuser.h of the compiler directory and comment out the

Code: [Select]

#define MessageBox __MINGW_NAME_AW(MessageBox) and

Code: [Select]

#define MessageBoxEx __MINGW_NAME_AW(MessageBoxEx)

2.

Code: [Select]

#undef MessageBox
#undef MessageBoxA
#undef MessageBoxW
On the project header file.


With this workaround i managed to get it working without any error-warning. Is this known or am i doing something wrong with my includes?

Also

Code: [Select]

tgui::MessageBox::setSize(float,float); doesn't do anything unless it's called after

Code: [Select]

tgui::MessageBox::addButton(sf::String&);

Is this normal?

[texus]

Its not really a problem with MinGW, its probably because you include windows.h.
This is the problems of using c libraries, they have no namespaces and defines just prevents other peoples code from working.

Of course I could work around this be writing "#undef MessageBox" in MessageBox.hpp, but that will only help if windows.h is included BEFORE tgui. If it is included AFTER tgui, then the define will be made later and I can't solve it in my code.
Plus by doing so I force people to use MessageBox from tgui, making it inpossible to use MessageBox from winapi.

So I think the best solution is to let you handle it yourself.
Right below "#include <windows.h>" you just have to write "#undef MessageBox".

I'll look into the thing with setSize.

[texus]

The easy way to work around the conflict with windows.h is to add the #unfef behind it.
The clean way is to isolate the windows-specific code. I don't think there are many things that you need from the window.h header, so you should probably put all windows-specific code in functions in a separate source file. Only in this source file will windows.h be included, and nowhere else in the project will it be used. This not only avoid conflicts with the header, but also makes it easier to port to a different OS since all windows-specific code is grouped in a single file.

About the setSize...
The behavior is kindof intentionally. The message box is auto-sized, which means that its size is recalculated when calling setText or addButton.
The ability to still manually change the size afterwards could be useful to extend the message box. You could e.g. make it 50 pixels wider, shift all widgets by 50 pixels and then add a picture of an icon on the left side.
But normally you shouldn't need to call setSize.

[JohnGreek]

Thanks for your reply.

I' m not including windows.h anywhere in my code, the only headers/libs i use in my project so far are Qt, SFML and TGUI. I guess it could be something from Qt? Anyways it gave me a bit of a headache but since i overcame it it's fine.

On the setSize,  i didn't really mention it as a problem or stopper, just noticed it :p


At the moment i am facing a quite weird situation with a SIGSEV error after a manual delete of my custom class pointer in a Qt slot. Debugger is also not working, crashes at startup on sf::PopEvent, sfml-window.dll
Is it safe to delete a custom class, inheriting from Qt (for usage of signals/slots) that contains tgui objects?
meaning manual delete.

duh..

[texus]

I guess it could be something from Qt?

I'm not sure. Maybe you should try putting the #undef between your includes and move it down and up to see under which include it has to be placed (and thus find the header that includes windows.h).

Is it safe to delete a custom class, inheriting from Qt (for usage of signals/slots) that contains tgui objects?

I have never worked with Qt before, but as long as you don't call delete directly on a pointer to a tgui widgets there shouldn't be problem. And since tgui::Widget::Ptr is not even a raw pointer I don't even think you can call delete on it. So it should be pretty safe. You could always try to remove the tgui stuff and see if the error still occurs if you really want to be 100% sure.

[JohnGreek]

Well, the thing is when i call destroy() on my tgui::MessageBox then i delete the class it is contained, somehow in my parent class(LoginScreen)
on the handleEvent function, this crashes when it tries to handle the event after i destroy the tgui::MessageBox:

Code: [Select]

qDebug() << "i try to handle the event :" << LoginEvent->type;
myGUI->handleEvent(*LoginEvent);
qDebug() << "i handled the event :" << LoginEvent->type;
In the class my message box is contained i pass the main sf::RenderWindow, tgui::GUI and my socket by reference.
If i delete the class the tgui::GUI is not deleted of course(also tried accesing it after the delete and it's fine) but why is this happening?

[texus]

messageBox->destroy() is just a shortcut for gui.remove(messageBox). It doesn't even delete any memory.
But tgui will handle memory management itself. You can rely on RAII when working with these Widget::Ptr. They will be destroyed correctly when no longer in use anywhere.

Are you calling bindCallback somewhere? What you pass there of course must still exist when a callback occurs.

If i delete the class the tgui::GUI is not deleted of course(also tried accesing it after the delete and it's fine) but why is this happening?

Memory is only deleted when you call "delete" on it (or when it is destoyed automatically when it has automatic storage, which should be the preferred way). Just because a class contains a pointer or reference to something doesn't mean it will destroy that thing when the class itself is destroyed.

Why are u using pointers everywhere anyway. You shouldn't be needing manual new and delete calls.
In most cases myGUI doesn't has to be a pointer, although it is still understandable, but LoginEvent definitely doesn't need to be a pointer.

Is the code big? If it is just a few files then I could perhaps have a look at it to see if I find something that you shouldn't be doing with tgui.

[JohnGreek]

Well it's 8 files, 4 headers and 4 source files.
But i will send you the suspicious lines

[texus]

This was indeed a bug in tgui. It was extremely hard to find though.

Although commenting out moveToFront prevented the crash in your case, it has absolutely no link with the mistake which was in the Container::remove function (which got called when you call messageBox->destroy()).

The crash should no longer occur u use the latest version https://github.com/texus/TGUI/commits/master.