Messages

Are you certain that the .dll files next to your exe are from the same place as the .a files? I didn't realize that possibility until I was creating a test here.

There is actually one more thing that we could test. I've created a project using the same compiler as yours. Could you try downloading it:
https://www.dropbox.com/s/iowa9pof9kx85td/TGUI-Test.7z?dl=0
(I've used 7z instead of a normal zip because it gave a big difference in size, download button should be at top right of page)

Try to run the TGUI-Test.exe inside the bin folder (either Debug or Release). If it complains about missing gcc and dlls then copy them from your "C:\Program Files (x86)\CodeBlocks\MinGW\bin" folder and put them next to the exe.
If the exe runs then try to open the .cbp project and building the project. Check if it still runs after you build the project.

I don't know what it could still be. The code works fine for others but everything seems to be set up correctly on your pc.

The only thing that wasn't normal in the things you send (except for the fact that you are receiving a segmentation fault) was the result of the call stack. Could you double check that you are running in Debug mode when you get that call stack? It shouldn't contain question marks on the top.

The only other thing you could still try is rebuilding TGUI yourself with cmake, but I fear that it isn't going to make a difference.

I'm starting to run out of ideas on what the issue could be.
- Could you send me your TGUI/include/TGUI/Config.hpp file?
- In CodeBlocks in the menu under Settings > Compiler... in the "Toolchain executables" tab (in the tabs near the top of the Compiler settings window), what is the "Compiler's installation directory" set to?
- If you open a command prompt, what is the output of executing "echo %PATH%"?

Everything seems to be configured correctly in the cbp file.

Could you send me your libsfml-graphics.a and libtgui.a files?

In that case it might just some driver issue. Make sure your graphics driver is up to date.

@Kvaz1r
The exception that you had in ProgressBar has nothing to do with this. That issue was already fixed.
You were also getting the GL_INVALID_OPERATION error, but there are two possibilities:
- Either it disappeared together with the exception which would mean that it is unrelated to this issue report (which is a possibility since the error could be caused by multiple things).
- Or it had nothing to do with the exception that you were getting and the GL_INVALID_OPERATION error was thus never fixed (I only fixed the exception issue).

You did make me realize one thing though: fonts also use textures. So I shouldn't just be looking at my texture management but also at the font management. Although I still don't see where it would try to copy something.

@che2a
When you get back to your computer, the following are what I would need to know (you can e.g. add some output in the program so that you can see when the error happens):
- Does it occur before the main loop starts? If so, when? (E.g. when creating the gui, when creating the first widget or every time a widget is created)
- Does it go away if gui.draw() is removed?
- What if you do draw but no widgets were created? What if some were created but never added to the gui (no gui.add(widget))?
- Does it occur every frame? Only once per frame, or e.g. once per widget, or multiple times per widget?

So you get there errors even if you don't add any widgets?
Do they still occur if you remove gui.draw()?

I'm not sure where that code is even executed. There shouldn't be a single place in TGUI where a texture is copied every frame.

Did you make any modifications to the example? Did you download or build SFML and TGUI?
This warning seems to occur when creating a texture before the RenderWindow is created, but the scalable login example shouldn't be doing that.

That particular line has been removed from SFML in the version on github (https://github.com/SFML/SFML/commit/f2b8e6397b3420f01b463d549ccc145ddf152dea), so maybe building the latest SFML version (and rebuilding TGUI with that version) might solve it.

Nice work.
It's good to see TGUI used in some complex projects.

Then the only thing I can think of is if the libraries aren't compatible.
Are you using the SFML and TGUI libraries that you downloaded from sfml and tgui websites? Are you using the GCC compiler that comes with codeblocks 17.12? Did you download the SFML and TGUI libraries for exactly this compiler (MinGW 5.1.0 TDM for the one that can be installed together with CodeBlocks)?
Could you send me the .cbp file from your project?

Could you send the full source code that you are using so that I can try to run it here and see if it crashes here as well?

Are you in debug or release mode? Which libraries are you linking exactly?

In the menu bar, check Debug > Debugging Windows > Call Stack.
When it crashes, it shows which functions gets called where. If you are in debug mode and linking to the TGUI libraries ending with "-d" then it will even show where inside the TGUI library it crashes.
If you can send the entire call stack then I may be able to see what went wrong.

What IDE are you using? Visual Studio?

Your method is correct, the window and gui will be constructed when the "app" object is created and destructed at the end of the main function.
The reason why I though you might be using static variables is because it is weird that you typed "Application::" in front of "tgui" and "window" in your original code. People don't usually add the class name before their member names unless it is a static variable or when calling a function from a base class that is overridden in the derived class. You would normally just type "tgui", or "this->tgui" if people really want to show that it is a member variable. So the syntax was a bit unusual, but there is nothing wrong with the code you showed.

You should have a look at the call stack then as I wouldn't know what else could cause it.

You should check the call stack from the debugger to see if it gives any more information.
Are window and tgui static member variables? They should be initialized by the class constructor and not at program startup before the main function gets executed (which happens with globals or static members), as that could give issues.

Thanks for looking into this in such detail.
It does look like this is just a case of the example not being updated with the rest of the code. The correct way is indeed *tgui::getGlobalFont().getFont().

The behavior shouldn't be changed in 0.8 as it appears to be the "intended" behavior: https://github.com/texus/TGUI/blob/0.8/tests/Container.cpp#L46
So for 0.8 I'll just have to fix the example code.

For 0.9 I will follow your suggestion to call getGlobalFont inside Gui::getFont. It does seem to be the best option.

It seems like TGUI links to some SFML libraries installed on your pc, but you are using different SFML libraries in your project. I'm guessing you installed TGUI from the PPA?
If you don't need SFML 2.5 and would be able to use SFML 2.4 then maybe it is enough to uninstall the 2.5 libraries.
Alternatively, you should probably uninstall the TGUI package and build TGUI yourself (so that it uses the same SFML libraries as you use in your project)

1st Question: How can I change the position of the slider at startup? It always starts at 0 (it's at zero now as I tried to fix), yet I assumed setValue would position it to the value correctly.

Calling setSlider->setValue(x) after creating the slider does change the value and will set the thumb on a different position. If not then you are probably calling setValue(0) somewhere afterwards.

2nd Question:   (SOLVED, I FIGURED IT OUT, HAD TO GET FROM GUI. I STILL HAVE TO CLICK EACH SLIDER FOR IT TO UPDATE THE VALUES FOR THE CHILD BACKGROUND)

The "ValueChanged" callback is only going to be called when you actually change the value, either by clicking on it or by calling setValue(). So if you don't give your window the right background color initially then it of course won't be set until the first time you change the slider.

3rd: What does the method update actually do? (Besides the obvious) What is being updated and when would I want to manually call update? Also, what is updateTime() method in the Gui suppose to do?

The update function is an internal function which should never be called manually. It is used to inform widgets that time has passed. Only a few widgets do something with this information, e.g. edit box will blink its caret. The updateTime function in Gui (also meant for internal use and called from inside Gui::draw()), is the function that will call the update() function on all widgets in the gui.
I guess I should rename update() to updateTime() as well to make it more clear what is being updated.

4th: How do I manually call a Widgets connect callback?

You aren't meant to do this. If you really must, you could use slider->onValueChange.emit(slider.get(), slider->getValue());

Edit:

but I realized the color of the background is definitely not accurate.

You are using "[&]" as lambda capture. Is the "slider" object still alive when the lambda is executed (when the value is changed)? It not then you are causing undefined behavior. Widgets in TGUI are stored as pointers, so you can copy them inside the lambda by value:

Code (cpp) Select Expand

slider->connect("ValueChanged", [&,slider]() { ... });

What line in your code is causing this error? I would have to see how you are calling the connect function (or the operator() function) on the signal to see what is wrong.

Maybe your function using std::string or sf::String as unbound parameter? That would have to be changed to tgui::String.

Edit: out of interest, which features were it that you wanted?

@Tojmak I've added a ThumbWithinTrack option to the renderer in TGUI 0.9-dev. Setting it to true will make the side of the thumb align with the side of the track when the thumb has minimum or maximum value.

Class member functions aren't the same as free functions, they have an extra hidden "this" pointer that you also need to bind.

If "onExitClicked" is part of the PixelPaint class then the connect function should look like this:

Code (cpp) Select Expand

menu->connect("MenuItemClicked", &PixelPaint::onExitClicked, this, std::ref(window));

Note that the "this" in the above code is only correct when this line of code is also placed inside the PixelPaint class. If the code is called from somewhere else the instead of "this" you should just pass the address of the PixelPaint object from which you want onExitClicked to be called.

The center of the thumb is currently always placed at the leftmost position of the track. I don't think there currently is a good way to work around this.
I'll consider adding an option to the renderer to choose the behavior so that you could make it so that the entire thumb always remains on top of the track.

I'm not so fond of assign. What would the opposite be, "unassign"? It sound a bit like you are completely changing the object as opposed to adding one callback functions to the list of existing ones.

The downside of using operator() is that the way you connect and disconnect isn't symmetric. If the signal was named differently then using operator() would also typically mean transmit the signal instead of connecting to it. It has been suggested a while ago by someone else as well though, and I have no objections to implement an operator() as alternative method which just calls the connect function in its implementation.

Another method that I'm thinking about is by using "+=" and "-=" operator (similar to the C# code for TGUI.Net). Something like this:

Code (cpp) Select Expand

button->signalPressed += myCallbackFunc;

The boolean parameter has been added to TextBox::setText in 0.8 on github.

Now that we are on the subject of signals, maybe you are willing to answer a poll about it? Which way would you prefer to use in TGUI 0.9 to connect signals?

Code (cpp) Select Expand

1. button->connect("pressed", []{});
2. button->connect(tgui::Signals::Button::Pressed, []{});
3. button->getSignal(tgui::Signals::Button::Pressed).connect([]{});
4. button->onPress.connect([]{});
5. button->signalPressed.connect([]{});
And if you have to choose between 4 or 5, which would you prefer?