Messages

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.

Form Builder is unable to create panels and child windows (I am currently rewriting the form builder from scratch in a more extendible way).

So you will have to edit the object files yourself. (code below is quickly written, it might contain small mistakes)
You can use the form builder to generate this:

Code Select Expand

Button: ""
{
    // ...
}
which you should then change in

Code Select Expand

ChildWindow: ""
{
    ConfigFile = "Black.conf"
    Size = (800, 600)

    Button: ""
    {
        // ...
    }
}

Other than the ConfigFile and Size, you can change more properties of the ChildWindow. I found a list in an old tutorial.


I hope to have the new form builder working at the end of the month so that you no longer need any workarounds, but I can't make any guarantees.

It wasn't an easy decision.
I tried to keep using boost for as long as possible but this started to give problems.

The major reason to remove boost and start using c++11 was because if tgui wasn't compiled with the '-std=c++11' flag then strange behaviour occured when building your own project with '-std=c++11' (MinGW compiler).

If I wouldn't had to use boost or c++11 for the callback system (I really needed std::function), then I would have definately kept support for older compilers much longer.

No, I recently decided to make the switch to c++11.

You will need at least Visual Studio 2010 to use tgui.

I built the dynamic libraries, for both debug and release.
They can be downloaded here.

The errors are like this:

libcmtd.lib(crt0dat.obj) : error LNK2005: xxx already defined in MSVCRTD.lib

After searching I can find only one explaination: you are mixing MD and MT settings (hence the libcmtd confilict with libcrtd).

I would rebuild sfml and tgui (in CMake use File > Delete Cache), and make 100% sure that you don't change any build settings.
But now that I have my windows running anyway, if you want to I'll send you some precompiled libraries.

I just built both sfml and tgui in VS2012 without any problems, so I'm not sure where it is going wrong.

What generator did you select in cmake? The number is the compiler version, so you will need "Visual Studio 11" for VS2012.

Could you send the tgui.vcxproj file in the build/src/TGUI directory?
I'm not sure if I will be able to get much info from it, but I can at least compare it with what I have.

Strange.
I'm going to boot my own windows and do some tests just to be sure that I didn't mess something up with the recent commits.

The warnings are 'normal'. I should really make time to fix these conversion.

I thing that errors about MSVCRTD.lib are caused when using wrong settings.

- Did you download sfml binaries or did you compile it yourself?
- When compiling tgui, did you check TGUI_USE_STATIC_STD_LIBS? If you downloaded precompiled sfml libs then this should be left unchecked.
- There is some option in visual studio that can be put on /MD or /MT, you shouldn't touch this when TGUI_USE_STATIC_STD_LIBS was unchecked (I think that the default is /MD).

Those three options have to match. So from what I see, you most likely checked the TGUI_USE_STATIC_STD_LIBS option when compiling tgui.

If you really want static std libs, then you have to recompile sfml with SFML_USE_STATIC_STD_LIBS, compile tgui with TGUI_USE_STATIC_STD_LIBS and set the visual studio option to /MT.
But normally you don't want to do this and you shouldn't touch these options.

Edit: I now see that you are talking about tgui.sln. What I said stays the same, but this rules out the possibility that you messed with settings in visual studio. I could have thus made my answer a lot shorter.

Thanks for adding this feature and sharing the code.
I'll add it to the next release, which will hopefully have basic documentation and tutorials.

The minimum compilers are supposed to be VC++10 and GCC 4.6, but I can only test with VC++11 and GCC 4.8.
So if tgui wouldn't compile with Visual Studio 2010 then you should just let me know.

I'd be very interested to see the changes.
You could perhaps put the files on dropbox or something similar. Or if it are only a few source files then you could send them by email.

Good to hear that it doesn't take too many changes.
If images can get to work, then I'm sure ConfigFile shouldn't need more than a few extra modifications.

I'm just going to leave the setSize empty for now.
As long as the function isn't really needed I see no reason to implement it, as the whole GuiContainer class is just a workaround to make my design possible. If I ever find a better design again this class will get removed again.

No TGUI class has a constructor with a Stream. The Font class, or any other that have it, are part of SFML.

Loading from Stream is not planned in v0.6. It has been requested in the c++ version and this was my answer:

Loading from memory is just not possible with the current design. The whole texture managment is build on top of the fact that images are loaded from files. So I would have to find a new design for the texture managment and I would have to change the config files to support this. I'm not even sure if I will be able to add this to the next version.

Of course c# is different. The biggest concern in the c++ version was TextureManager, but this class isn't needed in c# (at least not in the same way). But that leaves one issue: ConfigFile.
If you can point me out how I have to adjust my ConfigFile class to support streams then I'd be happy to make the changes. So if you can get the widgets to work that u use (or just for the Button class, that should be enough), then you can send me the modified files and I will make the adjustment to all other widgets.

was able to get the library up effortlessly simply by recompiling the source.

Did you have to do anything special for the Tao.OpenGL, or was it enought to include the sfml libraries?

I slept on it for a night and I got the same idea.
I was planning to add a Gui*, but a Window* is even better.

Done.

The problem is that the gui is only told about the resize when receiving the Resize event (by the way, is the resize event send after recreating the window on windows?).

I can solve this particular scenario, but it won't be completely solved.
If you have a button in the gui and then use button->getParent()->getSize() you will still get the wrong size.

Passing the window to the gui again should solve this issue, so maybe I should document it somewhere that you have to call gui.setWindow(window) after calling window.create(...)?