Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - texus

Pages: [1] 2 3 ... 88
Help requests / Re: List view
« on: 14 February 2019, 22:19:14 »
The following changes were just made to the ListView widget:

- Added horizontal grid lines to ListView
- Added option to ListView to expand the last column to fill the remaining space
- Allow a separator between the header and contents in a ListView
- Split separator in ListView into separator and vertical grid line

Help requests / Re: List view
« on: 01 February 2019, 18:43:56 »
I'll add VerticalGridLines and HorizontalGridLines properties.
Then the current SeparatorColor in the renderer could be just for the part in the header and a new GridLinesColor could be used for the vertical and horizontal grid lines.

Instead of LastColumnBorderVisible, I could perhaps add a FillColumn option which can be set to the column that should expand to fill the list view. Although then I can't make the last column filled by default as I would already need -1 to disable the option. Maybe I should just stick with FillLastColumn or ExpandLastColumn as this will be most likely be the column that should be expanded.

Help requests / Re: List view
« on: 01 February 2019, 08:22:31 »
I added the border behind the last column because this is how a ListView in Windows also works. But I agree that it looks better without the last line, I was also thinking about removing the line when I was making a screenshot of the widget.

I'm not sure how resizing the last column would work then though (in a case where there is a horizontal scrollbar), since normally you drag the line to the right of a column to resize it. Currently that's not really an issue as TGUI doesn't support resizing the columns by dragging the line yet.
Edit: Maybe a compromise could be to only hide the border when there isn't a horizontal scrollbar?

Help requests / Re: ChildWindow change position when title changes.
« on: 15 January 2019, 18:08:41 »
What happening when "setKeepInParent" is declared and the form size is bigger than parent size?
When the position of the child window is updated (not only when it changes, but also on some other places that just call the function like setTitle), it will check if the child window is within the parent and move it if it partially lies outside the parent. Whether it moves it to the right or left just depend on which check is done first in the code. But since the code should always do the same thing, the position shouldn't jump, so I should probably still investigate this further as it indicates some place in the code where the position isn't updated even though it should.

Check some "dot net" windows forms. When you create a form with a size, created form is always less than the requested size. We are talking about normal windows. So the title bar and borders are inside the calculated size of window.
I'll have a look at how some other libraries. I'll probably change the behavior of setSize in TGUI 0.9 to include everything while a new setContentSize/setClientSize would be added that acts like the current setSize implementation.

Help requests / Re: ChildWindow change position when title changes.
« on: 14 January 2019, 22:08:38 »
What do you mean exactly? That the window size should automatically be made smaller if it doesn't fit inside the window? Or that the child window size should always include the borders and title bar?

Help requests / Re: ChildWindow change position when title changes.
« on: 14 January 2019, 20:06:39 »
The size of a ChildWindow is a bit special. While the size usually defines the total size of the widget, the size of the child window is it's "client size". So when you create a ChildWindow with width 800, it is actually 800 pixels + the border width on both sides (so the total width is 802 pixels). Since your window only has a width of 800 pixels, the child window doesn't actually fit inside your screen. The KeepInParent will attempt to keep the window inside the screen, but it is unable to do so (and whether it pushes the child window off the screen to the left or right is undefined as you noticed with it the window switching position).
It is surprising that something changes when calling setTitle, but doing so triggers a position recalculation for some reason which is where it goes wrong with the KeepInParent property set to true. Although I could probably fix this, it is an edge case that occurs in a situation which should never happen (forcing the widget inside a window where it can't fit), so this might not get fixed (or when it does get fixed there might be other calls that trigger the reposition).

Feature requests / Re: "opacity when widget is disabled
« on: 12 January 2019, 14:05:04 »
Also, if i run "setOpacity" other than 1.0f before adding widget to gui manager the opacity does not apply. It works if i first add the widget and then apply new opacity. I tried this with "button".
I didn't realize earlier because I was focusing on the gui.add call, but the issue you are having has probably already been fixed in the github version:

Feature requests / Re: "opacity when widget is disabled
« on: 10 January 2019, 19:53:39 »
The OpacityDisabled property has been added to the version on github:

Feature requests / Re: "opacity when widget is disabled
« on: 10 January 2019, 18:45:01 »
I'll add a "OpacityDisabled" property to the renderer.

Also, if i run "setOpacity" other than 1.0f before adding widget to gui manager the opacity does not apply. It works if i first add the widget and then apply new opacity. I tried this with "button".
Could you show some code for this? I can't reproduce it.

Help requests / Re: EditBox acts strange.
« on: 07 January 2019, 08:27:35 »
You should probably restructure your code. Clearing and drawing shouldn't happen in the event loop. You should also pass all events to editGui.handleEvent, not just TextEntered ones. This is likely why backspace doesn't work, it relies on KeyPressed.
If showEdit is being called multiple times then the issue must be in the code where you are calling it.

There are probably many ways to redesign the code, here is one:
You should try to only have a single main loop which handles events and draws to the screen. Depending on the state of your program (e.g. whether in main menu or somewhere else), you call a different function for handling the event and for drawing (e.g. you use a pointer to a State class that has virtual handleEvent and draw functions). You can choose to either give each state its own Gui object or just have a single Gui object that you use everywhere and just put every screen in a Group (or Panel) and just show and hide this group when switch state.

Installation help / Re: Exseption std::bad_array_new_length
« on: 02 January 2019, 22:17:21 »
You should double check that you aren't linking debug libraries in release mode or the other way around.
If that isn't the problem (and I hope it is because it is the only explanation that I currently have for such a crash) then I will need a bit more info:
Is the setSize call or the parameter to the create function required to get the crash?
Which version of SFML and TGUI libraries are you using?
What compiler are you using?
Did you download the SFML and TGUI libraries or did you compile them yourself with cmake?

Feature requests / Re: Checkbox future improvments
« on: 30 December 2018, 12:38:39 »
Can't you just call the connect function after reading the data?

It's a bit more verbose than "changed", but you can do the following:
pCheckBox->connect("Checked Unchecked", [=](bool) {});

The bool parameter is optional, you can still use a function without parameters if you don't care about the new state.

Help requests / Re: Getting an error after drawing a widget
« on: 28 December 2018, 22:53:23 »
TGUI throws exceptions when things go wrong. Some compilers show the text when it happens, but Visual Studio doesn't. So if the "unhandled exception" is a TGUI exception then you have to catch it yourself. You basically need to put something like this around your code:
    // Code goes here
catch (const tgui::Exception& e)
    std::cerr << "TGUI Exception: " << e.what() << std::endl;
    return 1;

I'm not aware of any TGUI exception that can be thrown during drawing though, so if the above still crashes on the same line then it isn't a TGUI exception being thrown. You can try changing "tgui::Exception" with "std::exception" and see if that shows a clearer error.

I've seen crashes before on the gui.draw call which were caused by incompatible libraries. So you may want to double check that both SFML and TGUI libraries are for your exact compiler version and you aren't mixing debug/release or dynamic/static libraries.

After debugging the whole code I got the following error in the console window:
"sfml-graphics requires support for OpenGL 1.1 or greater
Ensure that hardware acceleration is enabled if available"
Try installing the latest graphics driver for your video card just in case this has anything to do with it.

Help requests / Re: Build issues
« on: 25 December 2018, 10:01:59 »
What compiler are you using?

I also get 2 warnings about lambda capture initializers only available in -std=c++14 or -std=gnu++14 even though I have compile with that standard on in build options
Maybe you enabled that option but it gets a -std=c++11 option from somewhere else which overrides it?
Can you show the command passed to the compiler (e.g. in CodeBlocks this can be found in the "Build log" tab, at least after changing the logging settings as described at

Installation help / Re: libintl-8.dll not found?
« on: 24 December 2018, 20:01:22 »
Guide on how to add path to to PATH variable:
The path that you should add contains a g++.exe and/or mingw32-g++.exe file from your compiler.

Edit: in some cases you need to reboot before the new PATH takes effect.

Pages: [1] 2 3 ... 88