Messages

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.

This is exactly why it is a bad idea to use the PATH. The dlls should be next to your exe and not in some folder in the PATH variable.

But I'm glad you figured it out, and I'll try to remember that program.

If its compiled with mingw then you could perhaps send it to me (including the mingw dlls that you have to ship) so that I can test to see if it runs?
Executables created by visual studio require me to boot my windows to install redistributable packages, for which I don't have time now.

You need to be sure that the error that he is getting is exactly "TGUI error: Failed to open graphics/gui/Black.conf."
If its any other error then there might be another problem.

The file is just read with an ifstream. There is a difference between "failed to parse" and "failed to open" though.
But if the error is exactly "TGUI error: Failed to open Black.conf." then it just means that the std::ifstream::is_open returned false and thus the file really isn't in the location where it should be. The error tells exactly what it tried to open, if it just said Black.conf then it is supposed to be located in the folder from where the exe is being ran. Otherwise there will be a pathname too.

I would be surprised that it would fail to open when the file is there.
I can't see any situation where it would work on your pc and not one one from someone else unless you haven't distributed the file correctly (e.g. somewhere in your code it is loading the file from a different path than you expect).

This version has a LeftMouseDoubleClicked callback in both ListBox and Label:
https://www.dropbox.com/s/cai8p2j1j2vhldr/texus-tgui-devel-aef1e62a6d20.zip

Ignore the warnings when you compile it, its all from TextBox because half of its code is still in comments.
(at least your text will display nicely in it, since word wrap is already implemented. All the rest just isn't)

In order to remove the item which you double click on in the list box, you can call listBox->removeItemByIndex(callback.value).
Removing from a Grid has to be done manually and costs a lot more work.

I'll just have to find another way to delete Items in Grid B, C and D then

I'll just have to add double click to labels too

TextBox isn't supposed to work yet. The first preview of v0.7 that I send had the class entirely commented out. But when I send the fix with these combo boxes I was too lazy to do that again. The code in TextBox is being entirely rewritten.
TextBox is kindof useless until I'm finished with it. I think it already exists since v0.4 but the performance is too bad to actually use it. I hope to have it rewritten and fully usable by the end of next week.

The double click will only work in list boxes. But since ListBox A is still a list box this is no problem.
You can use grids for the others, just put Label widgets in them to contain the text.

Double click callback in ListBox sounds reasonable. I'll see if I can add it.

1. I couldn't manage to change the size of text in a ListBox. So I tried to change the Global Font Size, but I couldn't find that either. Is there a simple way to do it ?

The text size can't be changed directly in ListBox. You have to set the height of the items with setItemHeight. (The text size is internally set to 0.8 * itemHeight)
I did this so that you can easily predict the amount of visible items. If the height is 200 and you set the item height to 20 then there are 10 visible items. If you would be setting the text height then you have no idea how many items fit (since there has to be a small space between the lines).

2. Also, is it not possible to give each item of a ListBox a specific color ? Like, Item0 is orange, Item1 is green, etc.

That can't be done. It would be pretty hard to pass all the colors anyway since you would need to set the background colors too and the colors for when they are selected. I think it would become a mess to know which color to use where.

3. The Double Left Click event is not yet implemented, correct ?

Correct. In which situation do you need a double click callback?

The master branch on github is always the kindof "recommended" version.

So right now it contains v0.6 with the few bug fixes that were made after the previous release.
The "unstable" stuff can be found in the v0.7-dev branch (which will be made public in one or two weeks).

At some point in the future, v0.7 will be considered stable enough and will take over the master branch while the current contents would be moved to a v0.6 branch. This happens still a long time before v0.7.0 is released, but it means that the biggest changes have been made already.

So to answer your question: it depends.
As long as the master branch contains v0.6 (latest releast version), then it is usually more stable than the last release since it contains just bug fixes or very small features.
When the master branch contains v0.7 (version in development), then it will be less stable than the releases. But it will contains tons of more features. But since it is not yet a released version (no v0.7.0 yet), things can still change and thus you can still opt for v0.6 to have a more stable, but less feature-rich version.

So once both versions are online, the first choice should not be between the release or the github version, but between the older stable version or the newer less stable version.

But it is very important to see that the time where tgui could crash by just hovering your mouse over the screen (such bug really existed in v0.3) are long gone. When I speak about bugs and unstable branches I'm talking about bugs that are usually extremely specific to certain widgets, and where they display slightly different than expected. Usually you can just keep developing while ignoring the bug and then later on update the tgui version to fix the bug.

Instead of giving this big explanation I should just have answered: look at the download page.
As long as new bugs in v0.6 are minor and only affect a select few, the latest release can still be used. If a really serious bug is found, then you will find the link to the source code linking directly to the latest github version instead of to the latest release.

Plus you can always check the latest commits to find out if it is worth taking the github version over the release.
If you look at it now you will find:
    Focused property of Gui wasn't properly copied
    List from ComboBox did not shrink when removing items
    Fixed potential bug with internal function
    Update version number to 0.6.5

So since v0.6.5 has been released, there has been a bugfix about removing an item from a combo box (very specific bug), and with copying the Gui object (something you normally don't do, plus the bug is just that the carets in edit boxes stop blinking). So its pretty safe to use the latest stable release.

Also note that I have no timetable for releases so if there have been many small bug fixes or some major bug then a new release won't be far away.

Wow, that was a long text that I just wrote . I guess if anyone has a similar question in the future I can just point them here.

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.

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.

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.

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.

The __imp__ has something to do with static vs dynamic linking iirc. It would be caused when e.g. defining SFML_STATIC while linking to dynamic libs or the other way around.

Normally you just link against "-ltgui-d -lsfml-graphics-d -lsfml-window-d -lsfml-system-d", I don't think you need to specify any others unless you are using another library next to tgui and sfml as well.

Which compiler are u using exactly (download link if possible)? Then perhaps I can try to see for myself.
On second thought, I won't be able to install another compiler to test this.

You should also make sure that you are linking to the same sfml version that you used to compile tgui with.

Edit:
This answer was not marked as the solution, so it may not be correct. But if this is true then cmake may have found VS libraries from sfml instead of the MinGW ones (I've seen it happen before, it doesn't care that it is linking with .lib files instead of .a files).
https://stackoverflow.com/a/20240189

Originally grid was fixed sized, the first implementation allowed you to set the row and column size. I got rid of it for some reason, but I can't remember why. But a lot has changed since then, so I don't expect too much problems with allowing to set an exact row and column size.

So I will have a look at it when rewriting the Grid (but my todo list is already getting very long ).

Ok, I've used the 3th way.
In case you are interested in using the updated combo box, you can download it here: https://www.dropbox.com/s/a23r9b8qnt50f5t/texus-tgui-devel-791673a73568.zip.

Grid is still a bit limited in usage. It was added in the first place to just put widgets below or next to each other in a simple way.
I'm planning to give it a big update later in v0.7 development, but I'm not sure yet how it will eventually look. I am planning on adding a maximum size so that if you go bigger a scrollbar would get added. Drawing lines is a nice idea, I'll add it on the todo list too.

The second column just starts where the first one ends, you can't set an exact position.
However you can put some space around widgets by using the fourth parameter of addWidget (https://tgui.eu/documentation/v0.6/classtgui_1_1Grid.html#aaf0e06ecc9f7dad5b54e6e5d7d38d469).
So take leftBorder = rightBorder = (50 - widgetInFirstColumn.getSize().x) / 2, then the second column will start at position 50.

the length of the "panel" sometimes keeps the length it had with the previous items, instead of going back to minimal length.

It seems like removing an item from the combo box doesn't shrink the list at all. It should be easy to fix.

But do you have a suggestion on what should happen when there are no items left in the combo box?
- Just ignore any clicks on the combo box
- Still flip the arrow but don't show a list
- Show an empty list with the size of a single item

I would tend to choose the third behaviour, do you have an opinion on this?

I wasn't talking about v0.6, sorry if I wasn't clear. Its a feature for v0.7.
So it will be available either when I make the v0.7-dev branch public (by the end of next week perhaps), or if you really want it I can send you another zip file of the currently latest v0.7-dev version.

The error is caused by switching between library versions (you had 0.7 installed but now installed 0.6).
You have to run "sudo ldconfig" because the old version is still cached.

When you set the size of your checkbox, editbox, etc, it usually never gives them the exact size you provided.

It is somewhat deliberately. The rule is very simple: borders are drawn outside the widget. The size you pass to setSize is the size without the borders. The reason I made this decision was because otherwise when giving ListBox a height of 200 and the item height is 20, there wouldn't fit 10 items in the list box because the borders were subtracted from the size. Now the borders are outside the widget and the list box can fit exactly 10 items as expected.

But it is something that bothers me too. Neither solutions are really correct.

And right now if a widget has a left position of 50 and the left border has width 2, then the first visible pixel is on left position 48. But that is still something that I plan to change, so that the whole widget including the border starts from the given position.

So this is a subject that I wouldn't mind discussing to find the best possible way to implement it.

I can only give one advice now: don't use borders . If you use images for all widgets then you usually don't need to have borders around it.

Also, when you have a combobox depending on another one, and you change the selected item of the first one so that there is no items available for the second one, though the second one doesn't display any items indeed, the length of the "panel" sometimes keeps the length it had with the previous items, instead of going back to minimal length.

I'll have a look at it.

Talking about combo boxes, I have been making the changes that you suggested. The list now disappears when the mouse is released again, and the item below the mouse is highlighted (if it is not already selected).

I assume that you are certain that the myGUI and LoginEvent are valid pointers when that line is executed.

The only thing that comes in mind is that you made a small mistake in the configuration (incompatible sfml and tgui libs, read https://forum.tgui.eu/index.php/topic,216.msg1092.html#msg1092). The smallest incompatibility can cause such a crash in either the handleEvent or draw function, and its usually very unpredictable (I have seen multiple different crashes for this reason).

If you are 100% sure that everything has been setup correctly then I'm going to have to test it myself. But I don't have qt, so you would have to come up with some minimal but complete code to reproduce it with just sfml and tgui.

Its ok, you can't help it that windows is such a pain to develop with .
The smallest mistake leads to strange crashes, and its always hard to find out which mistake you made.

What about changing combo box #2 when you receive a ItemSelected callback from combo box #1?

Are u perhaps still using the dlls of the old sfml version?

The crash really indicates that there is some incompatibilities in the libraries.
TGUI v0.6.5 has just been build and thus not yet tested, but if you really have v0.6.4 (search PATCH_VERSION in CMakeLists.txt to be sure) then it can't really be a mistake on my side.

You can't put two different callbacks (like, LeftMouseReleased and )LeftMousePressed) this way, correct

All callbacks will have the same callbackId, you cannot use more than one id.
The id is just needed to differentiate between the widgets, you also have callback.trigger which contains whether it was a LeftMouseReleased or LeftMousePressed. But in most cases you don't even need the id since you just call a specific function when something happens to that widget. And the function isn't called from anywhere else.

Also, just for your future versions, you might want the comboboxes' content to disappear on LeftMouseReleased rather than LeftMousePressed. Also it could be nice to highlight the item you are currently hovering.

Thanks for the feedback.
Altough this might be harder than it looks. The list is actually a ListBox that gets created. Highlighting items should thus just be implemented in ListBox and it will automatically work with the combo box. So that is doable.
But the list box is closed when the combo box gets a ItemSelected callback from the list box. This brings 2 problems: the list doesn't close when clicking on the already selected item, and it always happens on mouse press. Using the click callback instead of the ItemSelect won't work because you may click on the scrollbar. So I'm still looking for a way to get around this limitation.