[0x00]

Hi Texus and community, we have a problem (houston.. pshhh pshhh).

Tests:
Win7 x64
Link type: Static\Dynamic
Target platform: x32\x64
SFML 2.4.0 x32 (Static\Dynamic)
TGUI 0.7.1 x32 (Static\Dynamic)

Tests on video:
Win7 x64
Link type: Dynamic
Target platform: x32
SFML 2.4.0 x32 (Static\Dynamic)
TGUI 0.7.1 x32 (Static\Dynamic)

Links:
Link on video bug-report.
//sorry for ugly video quality
https://dl.dropboxusercontent.com/u/71162716/TGUI%200.7.1%20Bugreport.mp4

Link on code.
https://pastebin.com/fRk2Cr7D

Error List:
0. Need to press and hold LMB on MenuBar to see subitems menu.
1. If MenuBar parent to HorizontalLayout or VerticalLayout we can't select its subitems.
2. EditBox caret isn't change self size when its parent to Vertical or Horizontal Layout its size binds to EditBox height. (not relative to text)
3. If MenuBar is last element in VerticalLayout (in the bottom on window) the subitems spawns under window area.
4. When MenuBar parenting latest to VerticalLayout its subitem menu spawns under window (ViewPort).
5. If we use EditBox::setText("asdasd\n\nasdasd\n\nasdasd") and try to select something we got hmm... uncorrect behaviour.




And finally I have a question: is it bugs or features or my broken hands? //Self-criticism

[texus]

I'll have a look at these things, but here is a quick reply on the things you mentioned (I haven't looked at the video or code yet)
0) Holding LMB shouldn't be needed, this sounds like a bug
1) HorizontalLayout and VerticalLayout weren't created by me and may not work for everything, but they are meant for e.g. placing buttons next or below each other, not for complex widgets like a menu bar
2) I'll have a look at it
3) MenuBar widget assumes that it is always on top of the window
4) Probably same remark as 3
5) EditBox is single line and doesn't support newlines. TextBox is for multiple lines of text.

Thanks for such a detailed bug report btw.

[0x00]

Thanks for such a detailed bug report btw.

No prob. Thanks for fast reply)

[texus]

0) This should be fixed now in the latest version.
1) I'm going to leave this, it would be too complicated to change. These classes simply weren't made for this.

The MenuBar being partly behind the TextBox is a bit tricky to solve. The gui doesn't discriminate between widgets, the last widget added (or the last one that explicitly called the moveToFront function) is always the one on top. I could work around this by calling the function myself on a mouse click (like I do for child windows), but it will mean that you won't be able to intentionally put widgets on top of it (e.g. having a button on the right side of the bar). Making the list a separate widget and solve the problem like I did with ComboBox is not an option right now because ListBox doesn't support textures for each item yet and it would make it harder to expand the menu bar to have submenus in the future. So I'm going to leave it as it is for now.

2) Not really an issue since EditBox doesn't support multi-line text
3) This could be seen as a missing feature. The MenuBar assumes that it is on top, maybe a flag could be added in the future about whether the menus should be below or above the bar.
4) I didn't get the difference between this and #3?
5) Same remark as in #2, not considered an issue

I'll add the boolean flag for #3 on my todo list. It should be a simple addition, maybe if I have more time today I'll add it but otherwise it might take a while before it gets added.

[0x00]

maybe a flag could be added

Sounds good, like enumerator MenuBar::Direction {AUTO = 0, TOP, BOTTOM, LEFT, RIGHT};



Where can it be used?
ofc in game (Homebrew) \ non-game (Blender) editors or something similar

[texus]

Since I don't have time to implement auto, left and right in the near future, I'm just going to add a boolean flag in 0.7 to add support for having it at the bottom. I will implement it like you suggested in 0.8 when I have more time.

[texus]

I overestimated the spare time that I would have and underestimated the amount of work that this would be. Apparently it requires more changes than just a few lines in the draw function.

Both this change and the addition of setCaretPosition in TextBox also require changes in part of the code that has changed from 0.7 to 0.8 which makes it even more work to implement.

I have added both things on the todo list but they, or any other new features, should not be expected anywhere soon.

[texus]

In case you still care, the MenuBar now has a setInvertedMenuDirection function in 0.8-dev.