Messages

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.

I'm going to have a look if I can reproduce it.

In the meantime you can change your settings to also work in debug, and revert the order of the libraries (first system, then window, ..., finally tgui). And then rebuild the project. Just to be sure that neither of these things influence the crash.

The library paths in release mode seem right, but the ones in debug mode are wrong.

Code Select Expand

C:\SFML 2.1 -32\SFML-2.1\lib
Should be

Code Select Expand

C:\TGUI-0.6\lib\SFML

Oh, and the include directory doesn't need "C:\TGUI-0.6\include\SFML". But that doesn't really matter.

Edit: I now see that the include directory in debug mode is also set to the wrong sfml version.

So unless you were experiencing the crash in release mode, it should be solved after changing library and include paths.

Also how can we write in italics or bold in comboboxes, listboxes, etc?

That is something that you can't do. It could be added in the future but it will take some planning about how it would be implemented.

I was also wondering how many different events tgui knows, beyond tgui::button::LeftMouseClicked.

Normally this is found in the documentation of that widget and its base classes. But since the documentation isn't really complete yet, here is the full list. Button inherits from ClickableWidget which inherits from Widget, so it also has the events from its base classes.
(The documentation of v0.6 should contain the ones from the other widgets, I think only PositionChanged and SizeChanged are new in v0.7)

Widget:
  PositionChanged       ///< Position of the widget has changed
  SizeChanged           ///< Size of the widget has changed
  Focused               ///< Widget gained focus.
  Unfocused             ///< Widget lost focus.
  MouseEntered         ///< Mouse cursor entered in the Widget area.
  MouseLeft            ///< Mouse cursor left the Widget area.

ClickableWidget:
  LeftMousePressed     ///< The left mouse button was pressed
  LeftMouseReleased     ///< The left mouse button was released
  LeftMouseClicked     ///< The left mouse button was clicked

Button:
  SpaceKeyPressed     ///< Space key was pressed
  ReturnKeyPressed     ///< Return key was pressed

what is the appropriate event when the user clicks outside of the widget he was using

That will hopefully generate an Unfocused event

Focusing widgets is something very tricky in my code and even I can't always predict the exact behavior. The event should be fired when clicking outside the edit box that you were typing. But I don't think it will work with e.g. a slider.

The SpaceKeyPressed and ReturnKeyPressed callbacks only work when the button is focused, but the black style has no focused image by default. So it may not be possible to focus a button and then press space to trigger a callback while using the black theme.

Edit: I just verified it. Clicking outside the edit box will correctly generate the unfocused callback. Button will generate this callback immediately after the focused callback, since it cannot be focused without a focus image. Edit box is the exception since it has to be focused to type text in it, which is the reason that it can be focused even when there is no focus image.

I just need the vcxproj file. If your code is just a single file then you can send that as well.

Those files should even be small enough to be added as an attachment to your post.

Just to be sure, you have v0.6.5, right?

I'm not sure if I hit a bug in gcc, or just some special case in the c++ standard.
I'm going to assume its a bug since it compiled with gcc 4.9.

The braces on lines 274 and 284 in src/TGUI/Layout.cpp should be replaced by brackets.
So "m_first{...}" should be "m_first(...)".
It should compile after that change.

I also found 2 other places that didn't compile, but you since you already passed the first one, and I assume that gcc 4.8 will have an emplace function, they just have to be fixed to make it work on gcc 4.7.

Left, Middle and Right.

The Left and Right parts would keep their ratio, while the Middle part gets stretched.
E.g. the EditBox image in the black theme is only 120 pixels width, but it still looks good when giving it a width of 1000 pixels.

But this has been replaced in v0.7 where you can even use 9-slice scaling. You would specify the entire button image there, and then set the middle rect to (50, 0, 100, 50) to split the image (with a width of 200 and a height of 50) into 3 parts (these rects are always left,top,width,height).

I think we may have a serious problem here, this may not be easy to fix.
But before I can try to fix it I have to reproduce it. I have 4.9.1 installed on all my linuxes so I'm going to check on windows with 4.7.1.

In worst case I will have to completely rewrite the layout system (which I'm planning to do someday anyway since it has become a mess), but then it will take another week before you can use this version.

Yes, but I was just mentioning it in case you also develop on another computer.

What compiler version do you have? (type "g++ --version" in the terminal)

And you are 100% sure that you are linking tgui in the same way as sfml? (both dynamic or both static, both release in release mode and both debug in debug mode).

If so then could you send me your project file(s)?