Messages

Just try to make a minimal example before posting. If you make a mistake like this one then you will most likely find it yourself while making the example, and otherwise I will ask for an example anyway .

It works fine here with either the config file or setTextColor. Could you show some minimal code in which it fails for you?

Since the CloseAndSaveCallback is a function inside a class, it looks like this for the compiler:

Code (cpp) Select Expand

void CloseAndSaveCallback(const AddObjectDialog* this, Obj obj)

std::bind takes the following parameters: the function and the parameters. Since "this" is always the first parameter, it should always be before the other parameters in the bind call. The bind call needs to look like this:

Code (cpp) Select Expand

std::bind(&AddObjectDialog::CloseAndSaveCallback, this, p.object)

The bindCallback function has one version where the first parameter is the function and the second one is the 'this' pointer, but this is actually only a shortcut so that you don't have to call std::bind yourself. But if you need a function that has parameters then you must use the normal bindCallback function. So the line should look like this:

Code (cpp) Select Expand

p.button->bindCallback(std::bind(&AddObjectDialog::CloseAndSaveCallback, this, p.object), tgui::Button::LeftMouseClicked);

The menu bar issue seems to come from the fact that the "Options" has no menu items. It should be solved when adding items to it.

The problem with the buttons is the order of initialization. You cannot change them before they are loaded. The load function has to be called before you call setText.

Do you have an idea of how I should do to have a beautiful resizable program with no Grid?

In v0.6 there is no build-in way, but Grid is not the only option. For more control you can basically have a function that you call every time the window is resized that will call setPosition and setSize on all your widgets. Obviously this can result in a lot of code but then you at least control where everything is positioned under any resolution.

Another option to consider is trying out tgui 0.7-dev. In this development version it is possible to give widgets relative positions and sizes (e.g. a button with a width of 80% of the window). The position and size will automatically be updated once the bound widget changes. The big downside of using v0.7-dev is that the version is not finished so updates will break the API and you will have to change some code (e.g. the way widgets are loaded is going to be completely rewritten before 0.7.0 is released).

MenuBar doesn't really belong in a Grid. I've never tested it but it might give technical problems since it uses the width of its parent by default (which normally is the gui, but in this case the Grid which might not have a width yet). So the problem with MenuBar not being clickable might be a consequence of such a problem.

The buttons not having text can be caused by multiple things. It is basically because they are not getting the font correctly from their parent (the grid).

But in order to fix these problems I would need to see the whole code, not just this part. Could you write some minimal code that I can just copy-paste and run here?

Code (cpp) Select Expand

sprite.setPosition(40, getChildWindow(financeChildWin)->getSize().y * 0.5);

It took me some time to understand what was going wrong, but this is where the mistake lies.

The position is relative to the canvas. So if the canvas covers the entire child window it will clear the entire window with its black color (which is the default of the clear function) and the sprite will be inside it. When you make the canvas smaller the sprite is drawn outside the canvas and thus not visible.

I'll fix this in the next patch release then. The problem only occurs when drawing to a sf::RenderTexture (which Canvas uses) right before calling gui.draw. If that "dialog.Display(&win);" would be anywhere else (e.g. before the win.clear) or if there would be another draw call in between it then it wouldn't have caused troubles.

Btw, your project uses backslashes in the includes which prevents it from working on non-windows systems. Using normal slashes makes it cross-platform.

Since you are using a Canvas on which you draw with sfml I think I already know what the issue is going to be.
An issue was reported not so long ago but I didn't fix it because I thought the chance that someone else would run into an identical situation was like one in a billion.

Try with adding window.resetGLStates() right before gui.draw.

I'll be trying to set up the project in the meantime in case that doesn't help.

I was not able to provide an executable because I was guessing you use Linux

You guessed right . Even if you added a .exe which I could run with wine, I wouldn't be able to do anything with it anyway since I need the code to make small changes and test stuff.

Are you drawing anything directly with sfml?

If not, could you create some code that I can run here? Because this is a really strange bug and I don't think I will be able to solve it without debugging.

we can see that the widgets that are in the panel aren't hidden when they get out of it

This is not supposed to happen, so lets focus on fixing this and then see if the problem with the invisible text still persists.

If you look at my example codes, I never call the add functions. The most important line is actually not being shown in your code: the way the widget is created. If you initialize it with the m_win object then they will immediately be added to the gui. You have to initialize them with "*m_panel". Only when you don't pass any parent, then you have to call the add function to add it somewhere later.

I suspect that you created the buttons being inside the Gui, and then you added them to the Panel. That could explain why the buttons are still visible. Its possible that I am completely wrong about this, but you should show some more code then. If you would have a minimal code example inside a main function that I can just copy-paste then I can usually find the problem really fast.

It has a Closed trigger which you can bind.

Code (cpp) Select Expand

childWindow->bindCallback(tgui::ChildWindow::Closed);

If the Closed trigger is not bound, then clicking the close button will close the window. However, once you bind the close button you will get the ability to keep it open, so you will have to close it yourself. Either childWindow->destroy() or parent.remove(widget) will do that. The callback class contains a "widget" pointer which can be used for the remove.

Code (cpp) Select Expand

gui.remove(callback.widget);

The form builder will be removed from the next version since it is too much work to maintain it, so I won't spend much time in improving it anymore. I can still make small fixes though.

When I have got Checkbox and I change a "Enabled" value to false. I can't get focus to it in "Form builder" clicking it.

This is a side-effect of how the form builder works, it relies on tgui for everything, including the events. If a widget gets disabled then it will no longer send callbacks. There is no simple workaround for this.

I can't acces a all items.

This is something that I can still fix. I'll fix that tomorrow.

I'm glad you like it. I've seen this game on the sfml forum, it looks really awesome. I'm proud that my gui is used in a game like that.

I actually noticed that LeftMouseClicked didn't seem to generate a callback yesterday when I wrote my answer. But it was 3am and I was about to go to sleep when you posted your question, so I didn't look into it. But that bug will be fixed later today. But LeftMouseClicked is a bit useless since it doesn't tell on which arrow you clicked.

but few bindCallback's covering the different types of the callbacks used by different widgets

Although not very easy to find (it is spread over multiple places due to the widgets inheriting from each other), the information can be found in the documentation. You would have to look for the <WidgetName>Callbacks enum inside the class. For SpinButton that would be here (hmm, small typo in that part, I'll fix that in the next version). In the diagram on top of the page you see that SpinButton inherits from ClickableWidget, so if you click on that ClickableWidget node then you will end on a page containing this. And if you do that again then you end up in the Widget class which gives you the remaining callback triggers here.

I couldn't use this since XP limited Visual Studio 2008, which didn't allow C++11.

Actually Windows XP supports up to VS2010 which is the minimum supported version of tgui 0.6. It is only from tgui 0.7 onwards that I drop support for VS on XP (but MinGW can still be used) as the minimum compiler becomes VS2013.

You didn't bind any callback for the spin button. You are basically missing the following line:

Code (cpp) Select Expand

spinButton->bindCallback(tgui::SpinButton::ValueChanged);

Calling just setCallbackId won't do anything, the function just changes an integer so that you could later identify callbacks for that widget. But without a call to bindCallback or bindCallbackEx the widget won't send callbacks.

This has been reported a few times, but my suspicion on what the problem is has never been confirmed. I'm still assuming that this is a problem with the graphics driver, you should ask your friend to update it.

To be certain that it has nothing to do with tgui you can try out a program with just sfml and use code like this:

Code (cpp) Select Expand

// Load a small to medium sized texture, set it to repeat
sf::Texture texture;
texture.loadFromFile("Filename.jpg");
texture.setRepeated(true);

// Create the sprite and give it a texture rect that is several times larger than the size of the texture
sf::Sprite sprite;
sprite.setTexture(texture);
sprite.setTextureRect({0, 0, 800, 600});

// Draw the sprite and see if it displays without gaps between the repeated texture
window.draw(sprite);

If that code fails on your friends computer too then I will finally be certain that it is completely unrelated to tgui.

What is missing in that code is indeed something that blocks. Right now that function will do nothing since there will never be callbacks since you don't give the user time to make a move. The most straightforward way to fix it is putting a while loop around the pollCallback and once there is a callback you return from the function. But then you would also have to handle events and draw to the screen in that while loop so this method leads to a lot of duplicated code.

Instead you should always have one main loop and no part of the program should be blocking so that that loop is always executed many times per second. All you need to solve your problem is a simple boolean (or an integer if there are more enemies/players). Your simplified main loop will look like this:

Code (cpp) Select Expand

while (window.isOpen()) {
    handleEvents();

    if (playerTurn)
        takeTurn(player);
    else
        opponentTurn();

    drawEverything();
}

I can think of two ways to handle this, both with their own advantages and disadvantages.

The first one is to use a vector<tgui::Widget::Ptr> everywhere, so both PanelList and childWindowList would be of that type. This of course has the disadvantage that if you want to call function that are specific to Panel or ChildWindow you would first have to cast the pointer every time to call that function.

The second option looks better to me: templates. They are made exactly for situations like this where you need the same code for different types. It even has the advantage that the code not only works for Panel and ChildWindow but for every type of widget. The minor downside is that you will need to put the function definition in a header if you want to use it from multiple files. And although you only have to write one function definition. Inside the class definition in the header file you would write the following:

Code (cpp) Select Expand

template <typename T> bool isWidgetPresentInContainer(string passed_widgetName, vector<typename T::Ptr> containerList) { /* ... */ }

There might be a third option though. But that involves asking yourself if a function like this is the best way. I can't answer that because it depends too much on the situation. Other options would be to store a vector of pairs with the pointer and its name, or even store two vectors. That way you have both a list of pointers and a list of names, this function would just be replaced by a find call on the second vector (or for the second attribute in the pair).

Edit:

So I'm assuming that this is actually a std::vector issue?

This isn't really an "issue", both vectors are of a completely different type as far as the compiler is concerned. I know that it would be nice if it would just accept that both version just are similar to a vector of pointers of any type, but that is not how c++ works. C++ is statically typed which leads to these vectors being incompatible. Its just a limitation of the language.

however there was no better driver available as I feared

If the problem is specific to the driver that you use then downgrading might work, but it is just as possible that it won't change anything or even make things worse.

It's good to hear TGUI-0.6.8 can be used with SFML-2.1 can work with cmake.

Actually I just remembered that you can't use TGUI 0.6.8 with SFML 2.1. You need at least SFML 2.2.
Although if really needed you could download TGUI 0.6.6 from github which was still compatible with any SFML 2.x.

That subject is no longer posted on the forum or I can't find it

I guess it is this one: https://en.sfml-dev.org/forums/index.php?topic=12611.0
In your profile you can find the posts you made.

a way of testing SFML 2.1 with TGUI-0.6.8 Visual C++12 (2013) - 32bit?

The precompiled library in the download is only compatible with sfml 2.3 (thats just how libraries work on windows, they are only compatible with one specific version). So if you want to use tgui with sfml 2.1 then you will have to compile tgui yourself with cmake.

setArrowScrollAmount will just set the amount of values to move when pressing the arrows or while scrolling. Setting this to a higher number will just make the thumb jump even more.

Smooth thumb movement was possible with neither scrollbar nor slider, so I decided to stop delaying it and just implement it right away. You can download the lastest version from the master branch on github and compile it yourself. Or if you don't want to compile it yourself you could ignore the issue and wait a month or so and then download tgui 0.6.9.

There is nothing wrong with the function, so if it doesn't find it then it is just not there.
You should try putting the font directly next to your project file or perhaps next to the executable and try with

Code (cpp) Select Expand

gui.setGlobalFont("DejaVuSans.ttf");

If you can't get it to work then post the exact code that you are using.

Does using sfml without tgui (using sf::Text) display correctly?
Because it looks like rendering is broken and you should update your graphics driver.

Disclaimer: I didn't think before starting to write this post, so it is mostly random thoughts that crossed my mind. You can pick the design that you like the most, these are just some ideas that I had.

Ok, I see why you do it like that now.

People might also want to set the ratio for a widget that they did not name:

Code (cpp) Select Expand

bool setRatio(Widget::Ptr widget, float ratio);

That way they don't need to give the widget a name just to do this:

Code (cpp) Select Expand

layout->add(widget);
layout->setRatio(widget, 0.5f);

For convenience the following functions could be added for the ratio:

Code (cpp) Select Expand


void insertSpace(unsigned int position, float ratio);
void addSpace(float ratio);

But then it might also be interesting to have the ratio parameter like that in the 'add' and 'insert' functions, and then you could also have functions with both the name and the ratio. That way people can choose between the name, the ratio or both. But then we start having a lot of functions for a simple thing, so this probably isn't feasible.


So perhaps the design should get a more radical change. What about not using the widget name and making space implicit?

Code (cpp) Select Expand

void insert(unsigned int position, const tgui::Widget::Ptr& widget, const sf::String& widgetName = "");
void add(const tgui::Widget::Ptr& widget, const sf::String& widgetName = "");
void setRatio(const tgui::Widget::Ptr& widget, float ratio);
void setRatio(unsigned int position, float ratio);

It would be used like this:

Code (cpp) Select Expand

layout->add(widget);
layout->insert(2, widget2);
layout->setRatio(1, 0.5f); // Set the ratio of the space
layout->setRatio(0, 0.5f); // Set ratio of the first widget
layout->setRatio(widget2, 0.5f); // Set ratio of the second widget

The downside of this is of course that for the second widget you have to use the insert function because the add function would have inserted it at position 1. But perhaps we could still use the addSpace functions with a ratio:

Code (cpp) Select Expand

void insertSpace(unsigned int position, float ratio);
void addSpace(float ratio);

Then the code could look like this:

Code (cpp) Select Expand

layout->add(widget);
layout->addSpace(0.5f);
layout->add(widget2);
layout->setRatio(0, 0.5f); // Set ratio of the first widget
layout->setRatio(widget2, 0.5f); // Set ratio of the second widget

Code (cpp) Select Expand

canvas->clear();

That code will clear the canvas with a black color.
Change it to

Code (cpp) Select Expand

canvas->clear(sf::Color::Transparent);

The Panel also has a background color. So you should add this line as well:

Code (cpp) Select Expand

panel->setBackgroundColor(sf::Color::Transparent);