Messages

If I understand the question correctly then this is indeed about a basic part of c++.

With some basic type:

Code (c++) Select Expand

int i1 = 0; // Create an integer
int* p = &i1; // Create a pointer with the address of i1
int i2 = *p; // Dereference the pointer (get the value of i1)

You are in the exact same situation as the last line, you need a RenderWindow while you only have a RenderWindow* (just like you needed an int and had an int*).
So you can just initialize the gui like this:

Code (c++) Select Expand

tgui::Gui gui(*renderWindowPointer);

There is something wrong with the dlls.

I removed the dlls from your Release folder, and replaced them with the onces that you send earlier, and then everything worked fine.

I'm getting a http error 500 on that page.

Edit: I can acces it now

I just tested your libraries and I don't have any problem with them.

Do you have vs2010 sp1 installed?

Could you send me your vcxproj file, and create a minimal example code (so that we test with the exact same code)?

I would guess something like that from the "Error: Modules with different CPU types were found." line.

All libraries do need to be build for the same architecture.

Which generator did you select in CMake when building TGUI?

I never had the problem myself so I don't really know what you could do.

Quickly googling for that error tells me that you might need to set /OPT:NOREF in linker optimzation settings.

I'm going to sleep now, and tomorrow I have an exam, but I can try to take a look at it afterwards. So if the above doesn't fix the problem and you are 100% sure that you are linking correctly then put your sfml and tgui libs somewere (e.g. dropbox) and I'll see if I can find something special about them tomorrow.

I would guess that your SFML and TGUI libraries aren't compatibe.

Both should be compiled for your exact compiler. Did you compile tgui yourself? You'll have to because there are no precompiled libs for VS2010 (yet).

Both libs should be linked in the same way. In a debug build, you need the debug libs and in release you will need the release libs. If sfml is static, then tgui has to be static as well (or both dynamic).

You could disable it, which will stop the events from reaching the text box.

Code (c++) Select Expand

textbox->disable();

However if you do this then the scrollbar won't work anymore.

So I would suggest using the ChatBox widget to create a log panel.

There might be a bug in the clang compiler.

https://stackoverflow.com/questions/20927695/clang-bug-with-stdfunction-stdbind-and-stdref

Thanks.

On mac I tend to not use the resourcePath() like the sfml examples but to just put this at the beginning of the file:

Code (c++) Select Expand

#ifdef __APPLE__
    #include "CoreFoundation/CoreFoundation.h"

    CFBundleRef mainBundle = CFBundleGetMainBundle();
    CFURLRef resourcesURL = CFBundleCopyResourcesDirectoryURL(mainBundle);
    char path[PATH_MAX];
    if (!CFURLGetFileSystemRepresentation(resourcesURL, TRUE, (UInt8 *)path, PATH_MAX))
        return 1;

    CFRelease(resourcesURL);

    chdir(path);
#endif

But using resource paths will probably make it easier either way, and could also be used for other things. So I'll definately include this in the v0.6.0 release.

Could you try changing the std::ref to std::cref and see it the error still occurs?

I hope that it can get solved like that, because I really don't have much time right now (I have exams this month).

Are you using the Github sources as SFML_ROOT or are you building then installing SFML and using that as your SFML_ROOT? For me, cmake complains about missing files if it SFML_ROOT is set to the Github sources.

I just wanted to respond on that you said that FindSFML.cmake was the only file in that folder. I pointed to the contents of that folder in the latest sfml version to show that there should be multiple files. I didn't do anything, I haven't even opened cmake today .

But anyway, I have now applied the patch in the master branch. So everything should work now without changes.
Thanks for your help.

But I think other people might still have problems with this. I think that it finds the dependencies because you install sfml. I don't install sfml which might explain why it didn't found the dependencies for me yesterday. But the automatically finding isn't really a big issue, especially because you shouldn't be building the form builder on windows in the first place. And at least I can just tell people to just try to install sfml.
And with a little luck, I just did something wrong yesterday, and it will just work out-of-the-box.

FindSFML.cmake is the only file in the SFML/cmake/Modules folder.

I use this as a reference: https://github.com/LaurentGomila/SFML/tree/master/cmake/Modules

Copying it to the the TGUI/cmake/Modules folder allows cmake to find the the required dependencies and everything builds as it should.

Really? When I tried that then cmake complained that it couldn't find the dependencies and I had to set them manually. I'm not sure what we are doing differently. Anyway, I guess I can already safely update the FindSFML.cmake script in tgui without breaking anything new.

If you copy FindSFML.cmake from the SFML install location to the TGUI cmake/Modules it will build properly. If you're using cmake-gui, you can also manually set CMAKE_MODULE_PATH to the SFML/cmake/Modules path and it will build successfully too, since it winds up pointing to the same file.

I wasn't talking about just FindSFML.cmake, I was talking about the other files. I am trying to understand what I have to do to make cmake find the dependencies to jpeg, glew and freetype automatically.
The questions basically are:
- Does cmake find these dependencies automatically without changing the settings? (apparently not)
- Does cmake find them when setting CMAKE_MODULE_PATH to the sfml folder?
- If the above question is yes, is it enough to copy ALL the files from SFML/cmake/Modules to TGUI/cmake/Modules and then just leave CMAKE_MODULE_PATH to its default value?

I like the second option because of its simplicity for the user, on Windows at least.

Well, once this problem is solved, the necessary files will be in TGUI/cmake/Modules by default and you don't even have to change the CMAKE_MODULE_PATH option or copy any files at all.

As for building on my own, I want to make sure I want to make sure I'm using the most up to date version of SFML with the form builder since it's also being used in my game. It's one less thing to think about.

Building the form builder against SFML 2.0 or against the github version of sfml isn't going to make any difference at all. It only makes a difference with which tgui version it is compiled, and the current form builder is only a few commits behind.
If you use the latest sfml version then you will of course need to compile tgui against this latest version, but recompiling the form builder isn't needed.

If you want, I can look into making the install process how I was requesting.

That would be really kind. You probably have more experience with developing on windows than me, so maybe you can make it work.