Messages

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.

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?

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.

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?

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).

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: https://github.com/texus/TGUI/blob/d679a0a0c4b60e1895f258d10da940fbdda15e35/changelog.txt#L11

The OpacityDisabled property has been added to the version on github: https://github.com/texus/TGUI

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.

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.

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?

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:

Code (cpp) Select Expand

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.

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 (cpp) Select Expand

throw
{
    // 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.

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 https://www.sfml-dev.org/faq.php#tr-grl-verbose-ide)?

Guide on how to add path to to PATH variable: https://docs.alfresco.com/4.2/tasks/fot-addpath.html
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.

It's a problem with either CMake or your compiler installation. You will get that error when trying to build any cmake project. I've had the error go away in the past after removing and reinstalling cmake and codeblocks (and rebooting). If I had to guess then I would say that the real issue is just that the location of the compiler which you are using isn't in your PATH environment variable (or that you have multiple gcc compilers in your PATH and it chooses the wrong one).

I'm not going to do that, if all goes well then it should be really fast without having to do something like a BeginUpdate/EndUpdate. I use the ListView regularly at work (in c++) and I'm always annoyed by how slow it is when adding data.
With SFML you control when things are drawn anyway so you don't have to "prevent drawing" during the update.

Adding several hundreds to a few thousands of lines is so slow that it feels like the list view is just badly optimized. But I guess it has to do with the way it is designed too. Yesterday I started writing the header file and I intended to keep a similar way of adding items as in the windows component, i.e. by having an Item struct containing the caption and subitems. While doing so I realized that although this would be easy for the user, it meant that the user could change an item without the widget knowing about it and the widget would have to update its internal list of items every frame. By not allowing direct access to the Item struct and providing functions like addSubItem and changeItem, the widget can keep full control of when an item changes and I can reduce the amount of work that has to be done every frame.

You can expect the same performance in the ListView than you get now in the ListBox. And I don't mean the 1.7 seconds to add 10000 items like in TGUI 0.7, I mean the 0.083 seconds that it takes in 0.8.

The best option for label's scrollbar, if it should be enable or disable is to add an 'enum' Scrollbar State = {enabled, disabled, auto} along with a 'setter' and a 'getter' functions

It already exists, both ScrollablePanel and Label contain a ScrollbarPolicy which describes when the scrollbar shows up:

Code (cpp) Select Expand

enum class ScrollbarPolicy { Automatic, Always, Never };

By default, it should be disabled and if someone uses long text then he should enable scrollbar at the beginning.

That is probably the best option and I was planning to do it this way. Although even on Automatic the scrollbar wouldn't show up until someone would use a long text. There are very few cases where a scrollbar would suddenly pop up unexpectedly when using Automatic by default, but these cases still exist so using Never as default is the safest option. In 0.9 (if the version will ever exist) I'll switch to Automatic as default though as I won't have to worry about compatibility then.

I'll look into the multi-column listbox again. I'm not sure whether I should go for a simplified port of the windows ListView control (with only supporting the "report view" at first) or whether I should just create a MultiColumnListBox class though. I started with one of the two last time but I deleted the files and decided to choose the other, but I have absolutely no idea which option I picked last time

With your last post I finally got the correct view on what you are doing. I completely misinterpreted where the text box was located. I was imagining having a full screen textbox and then another window on top of it and that you wanted to close that window when the text box (which is partially hidden by the window) was clicked. I didn't realize that the text box was part of the form that you wanted to close. That is why I came up with the focus event, because you switch focus from the window to the text box behind it. But obviously the focus event wouldn't work if the text box was on the form itself as it already has focus.
Looking back at it, the situation that I was imagining was silly but there was almost nothing in your second post that indicated that the scenario in my head was wrong. The words "close this form with the textbox" do indicate that the text box is in the panel, but I interpreted that part of the sentence as "closing the form by clicking on the textbox", which no longer indicates that the text box has to be on top of the panel. Although the misinterpretation is my fault, it could help to be more verbose about how your forms look next time, perhaps even include a few screenshots. The more details you provide, the less chance there is that I misinterpret it.

I've already finished with adding a scrollbar to the Label class (I just have to decide whether I enable them by default if the text no longer fits or whether I disable them by default for 100% backward compatibility). Now I got to find something else to do
I guess I could try writing a multi-column list box again, but the last time two times I tried writing it I ended up playing games the entire week instead of programming

Label does have a click event (it inherits from ClickableWidget), as it is the only way to "interact" with the widget. The text box on the other hand was designed for inputting text and not for acting on things like being clicked on.

I was already wondering what I could work on next now that the TreeView is finished, so I'm going to try and give label an optional vertical scrollbar in TGUI 0.8.3.
I wonder though, if I have a Label with a scrollbar, should it send a click event when the click happens on the scrollbar? For your use case it should, but widgets typically don't send events when their scrollbar is dragged.

In my mind you don't want to close the form when clicking on the text box, you want to close the form when the user stops interacting with it, i.e. when unfocusing it. I didn't come up with the focus event until pretty late myself, I came up with all the other workarounds first before I realized that the focus event was an option. So I definitely get your point about the click event being more intuitive than the focus.
Actually I just notice a similarity with code I wrote before. When I open a dialog (panel widget) in front of everything else then I just put a panel with a semi-transparent black background between the original widgets and the dialog. Due to the semi-transparency it clearly shows the user that he has to interact with the dialog but I also used the click event on the panel to cancel the dialog.

Discussions like this can definitely make things better. I can be a bit stubborn and not want to change things sometimes, but I usually do give it a lot of thought even after the discussion ends. In the end it is very educational for me to know what difficulties people find when trying to use TGUI. If it wasn't for this discussion then the scrollable label wouldn't be on the planning anywhere soon.

However in the 0.8, i think that adding some features in widgets, like disabling select text without disabling the whole "textbox" widget or adding some extra callbacks is a plus

If I understand the use case for it then I'll add it, but I'm still not convinced that there is a reason to add these "features".
- You want text that can be scrolled. The only perfect way would be if Label supported scrollbars, but since that isn't possible you would have to use a workaround (unless I add support for scrollable labels, which might be a nice thing to have in the future). To me, using a TextBox and disabling the interaction with the text inside it feels like a worse workaround than to just creating a Label inside a ScrollablePanel. In 0.7 the workaround with the TextBox makes sense because ScrollablePanel didn't exist, but if we are looking at improving 0.8 for future users then it doesn't seem necessary.
- If both mouse press callback and focused callback work equally well then I don't need to implement them both. Both events are triggered in the same frame and for the same reason, so I can't come up with a scenario where you would need to do something on mouse press that you wouldn't be able to do on the focus event.

After all, a press event is a pre-event than focus event, so i am a bit faster. LOL

If you intercept the event before passing it to TGUI then you will always be faster, but a widget actually receives the focus BEFORE it is told that the mouse went down on it, so from the widget point of view the focus event is a pre-event to the mouse press event

Even if it didn't emulate a mouse, TGUI supports touch events (as long as SFML supports them on that platform). What I was uncertain about was whether mouse move events would be send when using a touch screen, because MouseEntered and MouseLeft depend on mouse move events and may thus not work correctly on a touch screen.

Is there a reason why you rely on mouse pressed instead of using the focused event of the text box? A mouse down event on a TextBox should always trigger the focused callback. If the focused event somehow doesn't cover your use case then it might still be a good idea to add mouse event callbacks to the TextBox.

1.
If you were using TGUI 0.8 then I would have suggested putting the label in a ScrollablePanel.
You could draw a Panel, put the label inside it and also put a scrollbar inside the panel. Then just change the position of the label when the scrollbar is moved. I just looked at the 0.7 source code and it seems like Panel didn't support padding yet, so the result won't be good if you want to have a bit of padding at the top or bottom of your panel, but it should work otherwise.

2.
One workaround that I can think of would be to listen to the MouseEntered and MouseLeft events of the TextBox to know if the mouse is on top of it and then in your event loop when you get a mouse down event you could close the form if the mouse was on top of the textbox. But since you mentioned kiosk machines, I'm not certain the MouseEntered and MouseLeft will work properly when using a touchscreen instead of a mouse. It isn't really an easy workaround either.

What exactly is the "form" you are talking about? Is it something from TGUI like a panel or child window? Listening to the unfocused event from that form might be an option, but if focusing widgets is as broken in 0.7 as I've always claimed it was then that probably won't work properly either.

What about listening to the "focused" event of the TextBox, instead of trying to close the form on a mouse press?

Nr 1 is by design, read-only just means you can't change the text but shouldn't prevent the user from still being able to copy the text. One thing you could do is disable the widget. It won't respond to any events after that though. Another option is to use a label, they can be given a size and have text fit inside them with word-wrap as well. Labels don't support a background texture or scrollbars though.

I don't understand what your use case is for nr 2. Could you elaborate on what you are trying to do exactly?

I have updated the scripts to be able to build 32-bit libraries, it involved a bit more changes than I originally though.

The steps to download and compile them are as follows:

Code (batch) Select Expand

git clone https://github.com/texus/TGUI.Net
git submodule update --init --recursive
cd build
build.bat x86

I haven't actually been able to test the 32-bit libraries though as I don't know how to get an x86 dotnet program working on my 64-bit windows (I know very little about dotnet). So you are on your own for that part.

You have to clone the project with git, not just download the source code from github.