Messages

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.