Messages

We have been looking at the wrong place.

Creating the Form and even calling the draw function causes no problem.

It is the button that is causing the problems. The image is drawn when the button is drawn (when the form is drawn). This is why you only saw something when form.draw was uncommented. If you remove the button->setPosition(...) call you will also notice that the small image isn't drawn on the same spot anymore.

So basically your texture is used as image for the button. The question that remains is why.

Edit:
I"ll continue running tests tomorrow. I'll check if it does the same on an ati card, if there is a difference when I rebuild the libraries (dynamic vs static), if it is solved with the different design in v0.6, ...
So hopefully I will be able to find, and if possible fix, this issue tomorrow.

Now we are getting somewhere.
The executable produces the same result as you had.

Great, but how the heck do I download it?
I'd say by logging in, but it won't register me.

Could you perhaps put it on something like dropbox?

EDIT: Nermind, I found it. Half of the page wasn't displayed because of AddBlock Plus.

Ok, could you send me everything needed to reproduce this?
The source code, executable, images u use, even the compiled sfml and tgui libraries.

I want to test this with the exact same resources.

It works fine for me, so I'm not sure what I can do about it.

You could try using a sprite instead of a vertex array (to rule out the possibility that it is about the vertex array instead of the render texture).

Other than that, you should try to find where it goes wrong, but I won't be able to help you with that.
Try to remove (place in comments) the contents of all functions in Form and see if that changes anything.
If that doesn't then you should continue with removing the functions in Group.

Edit: Can you find someone else to test this as well? I'm still not sure if there is a problem with your pc or whether more people have problems with it. I'll try on my pc with ati card tomorrow as well.

The download on my site is the right version, but if "tgui::Form form(&window);" compiles then you are still using the header files and library of an older version.

But you are definately not running the latest tgui and sfml versions.

You are passing a pointer to the Form constructor, I changed it to a reference on 21 August.

You should try again with TGUI v0.5.2 and SFML 2.1.

How would I draw the form?

It has a draw method (instead of the drawGUI method from tgui::Window).
You can find the usage of tgui::Form at the bottom of the introduction tutorial (this reminds me that I should still move these tutorials to tgui.eu).

I now tested it on both linux and windows 7 on a laptop with an intel HD 3000 graphics card. I can see the image.
The only thing I changed in the above code is the image filename.

I'm going to sleep now, so if you find anything else then I'll look into it tomorrow.

My image gets displayed.

I was already typing my reply as a mail, but I'll answer here instead.

I don't even see how it is technically possible that it works with sf::RenderWindow but not with tgui::Window.
tgui::Window just inherits from sf::RenderWindow.

The code works fine on my linux laptop. I am using TGUI v0.5.2 and SFML 2.1.

As a quick workaround, you could try using sf::RenderWindow and tgui::Form instead of tgui::Window.

The Ptr's are indeed just typedefs in every widget.

But the smart pointer was written so that you wouldn't need to manually cast, it will work automatically.
Internally there will still be a cast, but you don't have to worry about it.

This will work:

Code Select Expand

tgui::Combobox::Ptr comboPtr = gui.get("A Combo Box");
comboPtr->addItem("test");

This will NOT work (as the get function only returns a tgui::Widget and there is no cast involved):

Code Select Expand

gui.get("A Combo Box")->addItem("test");

But you can still make it work on one line like this:

Code Select Expand

tgui::ComboBox::Ptr(gui.get("A Combo Box"))->addItem("test");

I was struggling with casting the returned Widget::Ptr into specific types.

Any function declared on tgui::Widget can be called no matter the real type of the widget. You only need to upcast when you need specific functions like setText.

Binding of the built in "callback triggers" would be a welcome future addition, though.

I will add it to the todo list. I'll see when I have enough time to add something like this.

No.
The problem is that object files are old, they were introduced in v0.4 and since then they were only patched to keep working with the latest tgui version. When introducing the new callback system in v0.6, I couldn't immediate find a way to get callback working and eventually nothing was changed and binding callbacks still doesn't work.

I'm still not sure how to handle it.
For just binding the callback so that it is send to the parent widget (and eventually to the gui), I would have to make a check for every widget if the string is one of the possible triggers. And binding a callback to a function seems completely impossible.
Currenly the only way to solve this seems to be to let the form builder generate c++ code instead of object files, but that has its downsides too.


You don't have to go over every widget seperately, depending on the situation code like below is enough.

Code Select Expand


auto widgets = gui.getWidgets(); // replace gui with the container that contains the loaded widgets
for (auto& widget : widgets) {
    if (widget->getWidgetType() == tgui::Type_Button)
        widget->bindCallback(tgui::Button::LeftMouseClicked);
//  else if (widget->getWidgetType() == tgui::Type_xxx)
//      widget->bindCallback(tgui::xxx::yyy);
}

But if you really need a lot more code than what I have above then I might be able to quickly arrange something.
I could add callback so that you have to manually add 'Callback = LeftMousePressed' to the buttons in the object file. But then you still won't be able to bind functions. This change could take a few hours though.

I realized I could just call "loadWidgetsFromFile" from the container I want to populate, instead of from the instance of GUI.

I already forgot that I once added this possibility.

It still appears in the 0.6 documentation.

It seems like the online docs haven't been updated yet. Will be fixed in a few minutes. Thanks for letting me know.