Messages

x

x

test

That code should work fine. I would expect the error to be in the code where you handle your events: when gui.handleEvent is called with the mouse click release event as argument, the button will emit the pressed signal. Are you calling gui.handleEvent for each sfml event or is it possible that you are somehow buffering the events somewhere and only pass the previous sfml event when the next one arrived?
If you can't figure out where the issue comes from, you should write some minimal code that reproduces the problem so that I can test it myself.

Code (cpp) Select Expand

bClickMe->setPosition("50%", 100);

This code only works in tgui 0.8-dev. In tgui 0.7 the "50%" gets evaluated as "50 mod 0", which is NaN.

The equivalent line for tgui 0.7 is:

Code (cpp) Select Expand

bClickMe->setPosition("parent.width/2", 100);

or shorter:

Code (cpp) Select Expand

bClickMe->setPosition("&.w/2", 100);

removeAllWidgets apparently calls setSize(0,0) so another workaround would be to set the size again after removing the widget.
I tried to figure out why the code is there to determine if it is ok to just remove it and it turns out that setting the size to (0,0) is something that was added early in 2013, when the size of the grid still had a different meaning. I have removed the setSize call now, you can download the source code of the latest version on github.

When a widget is added to its parent, it inherits the font and Gui is the only object with a built-in font. My guess is that you are settings these fonts before the panel gets added to the gui. No matter what the font of the widget is set to, when the panel has no font yet and is added to the gui, its setFont is called to give it a font. Since the setFont function doesn't know the difference between such call and a manual call to setFont where the intention is to change the font of the children as well, all widgets inside the panel will get the new font. A workaround in your code would be to manually set the font of the panel before changing that of the children (but then it would again be overwritten when the panel is added to another panel before being added to the gui) or only set the font after the panel is added to the gui.

A solution on my side would be to give setFont an extra boolean to choose to pass the font to all child widgets, but I already made that option kinda impossible in the design of 0.8.

The scale function just calls setSize(getSize() * scaleFactor), which is not what you need. (I removed it from 0.8 because you can easily call setSize yourself)

What you are describing sounds like the view not being changed, if that is the case then it should affect all widgets and not just the MenuBar. Unless you call gui.setView when the window is resized, the view will remain unchanged and everything drawn to the screen will be stretched. (SFML has the exact same behavior by default, you also need to call window.setView if you want your own SFML drawings to not get stretched)

If that is not the problem then please provide some minimal and complete code that reproduces the issue so that I can try it here.

I prefer the first one.

You can have multiple Gui objects, although it is advised to use a single Gui object and have multiple Panel/Group widgets inside it of which you only show one and hide the others.

The draw function fails at an assert. Some compilers and IDEs will clearly display the assertion in the output, but I know that some just crash without displaying much information. The reason why it asserts is because the Gui objects are not correctly initialized. They need to be told to which window they have to draw. The initialization should look like this (or use the setWindow/setTarget function if you can't initialize them on the same line).

Code (cpp) Select Expand

tgui::Gui menu{app_win};
tgui::Gui over{app_win};

Edit: are u running the code in release mode instead of debug mode? It looks like assertions are disabled based on your image.

well in the end I moved them to bin folder

Why would you have to move them? Is there a reason you need them in a bin folder?
They just need to be placed next to your executable.

also why is the signal result (checked or unchecked ) is in string style ??

What exactly are you referring to? I didn't understand what you meant with this.

When creating the library, all files that are created end up in a single build directory. I just copy the relevant files (.dll and .lib/.a) together to a "lib" folder. I could put the dlls in a separate "bin" directory perhaps, but I don't really care much where they are placed as long as people can find them.

These forums all use SMF (Simple Machines Forum) as forum software.

"sfml" from pacman is version 2.4.2, and "sfml-git" is 2.4.0.

This is not correct. The sfml-git package (just like tgui-git) always builds the latest version, sfml-git is thus newer than sfml 2.4.2. The version number displayed on the AUR is confusingly the version of the last update to the PKGBUILD script. For instance, tgui-git used to still show version 0.7-alpha2 while it was already building tgui 0.7.3. But any package with "-git" at the end should build the very latest version, no matter what the version number on the AUR says.

Maybe there is some inconsistency with the compiler used to build the sfml and tgui libraries. You could try building SFML from source as well (by installing "sfml-git" from the AUR instead of the "sfml" package).

Edit: I just reproduced it here, using "sfml-git" instead of "sfml" solves the issue.

That error shouldn't happen when you install TGUI from yaourt unless something happened afterwards.
If you e.g. do a system update with pacman then the gcc or SFML version may change and the TGUI libraries that you have installed may no longer be compatible (as they were installed with yaourt and thus not updated with the other packages).

So you should try removing TGUI and reinstalling it (with yaourt) and see if that fixes the issue.

Did you just install SFML and TGUI or were they installed earlier and did you update your compiler since then?
Based on the error I would guess the latter and I would suggest compiling TGUI again.

This was a bug in TGUI, changing the text did not sent a SizeChanged event to which bindWidth subscribes.
I have fixed this in the latest version. You can download the latest version (which will eventually be released as v0.7.5) and build that TGUI version yourself with cmake.

In a design that makes some sense (i.e. in tgui 0.8-dev), the Theme class stores all properties for all sections when the theme file is read. But the class in 0.7 was more like a prototype and there were several bad design choices related to the theme and renderers. But issues like this one of course help me with making decisions on how to improve it in future versions.

If you have multiple of these places where you change the look of the widget dynamically then maybe you would benefit from using 0.8-dev (changing the look of the edit box would be as simple as `editBox->setRenderer(theme.getRenderer("EditBox.Invalid"));`). But if it is just for one or two places in your code then it is probably not worth the effort to upgrade.

I haven't tried it, but based on my Theme class code I guess the EditBox.Invalid is never loaded.

Try adding the following somewhere after you create the theme:

Code (cpp) Select Expand

theme->load("Invalid");

You don't have to do anything with the return value of that function call, it is just needed so that the Theme class reads the EditBox.Invalid section.

This is indeed a bit tricky to do with the way the Theme class works in 0.7. Reloading the look of a widget without recreating the widget is something that is much easier to do in 0.8-dev, but I can't fully recommend that version yet.

You should be able to get the right property by calling theme->getProperty("Invalid", "TextColor"). The "EditBox." in front of the name is just so that the theme class knows what type of widget to construct when you call the theme->load(...). The first "EditBox" section is in fact implicitly renamed to "EditBox.EditBox", which is why the first one can be loaded with the name "EditBox" while the second one has name "Invalid".

Although it would work, it is not advised to have multiple Gui objects. Instead you should rather create a Panel widget for each game state and add all widgets for that state to the panel. That way changing the state just means hiding and showing a panel.

Other than having a longer load time (as you would initialize all states when the program starts), I don't foresee any problems.

Multiple submenu levels is currently not supported.

Currently the following hack seems to work:

Code (cpp) Select Expand

menuBar->connect("MouseLeft", [=](){ menuBar->mouseNoLongerDown(); });

I've added a closeMenu function to the github version (which will become 0.7.5 in a few months). With that version you will be able to write the following, which makes slightly more sense:

Code (cpp) Select Expand

menuBar->connect("MouseLeft", [=](){ menuBar->closeMenu(); });

You might want to have a look at what scopes are again, because it is important to understand how it works in c++.

The first line in Sidebar::Sidebar is still creating a new "app" which only exists until the end of the function and is then destroyed. Every frame you are creating a new Sidebar instance, the constructor will be executed and you create and destroy this App, this would cause a window to be created and immediately disappear.

The app should only be created in one place, the main function:

Code (cpp) Select Expand

int main()
{
    App app;
    app.run();
}

The Sidebar should probably not be created every frame but e.g. be part of the App class:

Code (cpp) Select Expand

class App
{
private:
    sf::RenderWindow mWindow;
    tgui::Gui mGui;
    Sidebar mSidebar;
public:
    App();
    void run();
    ...
}

Code (cpp) Select Expand

App::App() :
    mWindow{{1280, 720}, "Study Buddy"},
    mGui{mWindow},
    mSidebar{mGui}
{
    // If you don't understand what the lines above are, look up "member initializer list"
}

Code (cpp) Select Expand

void App::render()
{
mWindow.clear();
mGui.draw();
mWindow.display();
}

The Sidebar gets a reference to the gui as parameter and adds the button to it:

Code (cpp) Select Expand

Sidebar::Sidebar(tgui::Gui& gui) // Passing by reference is important, we don't want to create a copy
{
tgui::Button::Ptr button = homeButton();
gui.add(button, "homeButton");
}

Code (cpp) Select Expand

std::shared_ptr<tgui::Button> Sidebar::homeButton()
{
        auto button = tgui::Button::create("Home");
button->setPosition(600, 600);
button->setSize(200, 200);
button->setText("test");
button->setTextSize(20);
return button;
}

(Note that the code above is not complete and I didn't test any of the code so try to understand it instead of copying blindly)

You should create a minimal example code that shows this problem. I can't help much by only seeing a small part of the code or if you have too much code.

This might be what you already fixed, but the code in Sidebar::homeButton seems very wrong. You create the App instance inside it which creates the tgui::Gui instance to which you add the widget. But when you return from that homeButton function the App and Gui are destroyed as they go out of scope.