Messages

Thanks, I'll use this when I start using c++11.
But once I start using c++11 I won't just get rid of boost, I will also use c++11 for the rest of the code, so this is only a small part of what I eventually will write. For tgui v0.6 I also aim to support at least VC++10 and GCC 4.6. So the use of c++11 will still be limited in v0.6.

Did you read the msdn page about the error? Did you try changing optimization?

The error happens on line 2273, but the place that you say it stopped compiling in on a different line. Is this just a mistake or are there errors for other lines than 2273?
EDIT: The line numbers were messed up in my browser for some reason. Now I see that that code is indeed on line 2273.

I don't think I can change the code to solve this, it seems to be a problem with the compiler.

While debugging with VS2010 I only found an assertion when selection the text from any edit box.
So you might want to try and remove the '-1' from the end of line 1711 in EditBox.cpp.

If this doesn't fix your issue then it would indeed be best to debug it yourself. I currently have to borrow a laptop from someone to test on windows and I can't do much either when I can't reproduce it or when I don't have a call stack.

I didn't look at the code in detail, but you aren't calling window.handleEvent in your event loop which is probably the problem.

In tgui v0.5 the headers aren't installed and you have to either copy the folder yourself like you did or set the path to the include folder in your code blocks settings (or as '-I' parameter to the compiler when using g++ directly).
In tgui v0.6 I have already changed it so that the files are installed correctly when calling "make install".

Strange, I can't reproduce that.

Edit: tested on linux and on windows with GCC/MinGW for both the previous version and the latest version. I doesn't crash here.

It has been fixed now.
I deleted the width and height properties from label some time ago and apparently they were still used when changing the text or text size.

There is a small explanation on object files on the old site (which means outdated, but still usable).

You should also take a look at the FormObjectsWindow.txt in the Form Builder folder. It only gives an example for Picture and Button, but it always has the latest syntax (e.g. uses ConfigFile instead of Pathname).

It is supposed to be working. I don't test it much, but there shouldn't be problems with it.
I recently build the one that is included with the latest 0.6 version, and I didn't see a problem at first sight (I only quickly added some objects and moved them around).

Could you be a little more specific about what version you have downloaded?
Did you download tgui v0.5 or v0.6-dev? If v0.6 then did you just download it or a did you download it few days ago (so that I know if it is the latest version or one from a few days old)?

Just in case that it would be OS specific, can you also tell me what OS you use and which compiler? Then I can make the test in the same circumstances.

Edit: Can I safely assume that drawing images with sfml isn't a problem and that it really is the form builder? I don't want to start debugging only to find out later that it was just a driver issue.

Grid will place your objects next to each other, so you don't have to set an exact position.
With the addToRow function you add the object to the right of the previous object and you can use addRow to go to the next row. The addToRow function also optionally takes borders as parameter to put some space between objects. So Grid can be used to make a menu screen by placing buttons beneath each other, without you having to worry about the exact position of the buttons. But Grid doesn't change the size of the objects, you have to set the size yourself.

Although Grid can be compared with the layouts from qt, it still has a lot of limitations.
Support for real layouts is pretty hard. I mostly have to consider how it will be designed, which functions it will have, ...
So this can't be expected before v0.7.

The stretched text is indeed problematic. Depending on where the text is you could draw it with sfml directly with a different view than the gui, but that isn't a great solution either.

What exactly are you talking about? I didn't add layouts.

There is only Grid so far, but this doesn't help against manually resizing.

Depending on what you want to do, you should use a different view to draw the gui. This will allow you to zoom without manually resizing objects.

Not yet, but almost all possible options are already used in the Black.conf file.

I've created the list, you can find it in the new config file turorial.
There are no explanations of what every option does (I'll add that later), so you'd still have to take a look at the Black.conf file to see how they are used.

It was merged into master a little more than one week ago, I just forgot to delete the branch.

I can't do that now, but I'll remove the branch in the next few days to make sure there is no more confusion.

You are using an older sfml version.
The problems should go away when using the latest version.

I've only saw an error like that happen when linking the debug library in release mode.

Did you had an older version of SFML installed before by any chance?

The things I said that would cause this would probably cause more than one error.

There has been a change with the second parameter of this function between the sfml2-rc and the final release.
This error might mean that tgui was compiled with the correct sfml version (it looks for the right function), but you are still linking to an older library in your project.

It couldn't find the sf::Window::create function which I call when creating tgui::Window.
Which means that you don't link to sfml-window.lib or that the libraries of sfml and tgui don't match (e.g. not declaring SFML_STATIC while using static tgui libs).

I can only think of one thing that could cause this other than a fault in the configuration.
When creating the libraries with cmake, cmake searches for the sfml libraries and links my tgui lib with them. This is a possible scenario of what could have gone wrong: you first created the debug libraries and cmake linked them to the debug sfml libs. Afterward you changed the settings to release and build it again, but cmake apparently didn't link with the release libs but still with the debug libs.
To outrule the possibility of this being the case, you should recompile your release lib. Go to cmake and use File > Delete Cache. Build only the release version, so that it can't link the wrong library.

If this helps then I guess I should put a giant warning about it in the tutorial.
If not then this clearly wasn't what happened and you should send me your project file(s) so that I can try to see what could have gone wrong.

But I'm going to sleep now, so I won't respond anymore in the next 9 hours.

If you get different results in debug and release then you must have done something wrong with your settings. Somthing like only declare SFML_STATIC in debug, but not in release.

The callback.mouse can already be casted to sf::Vector2i, so you could write sf::Vector2i(callback.mouse) if you want to make it a vector.

But this still wouldn't work because there is no + operator between Vector2f (which getPosition returns) and a Vector2i.

So unless I would make it a Vector2f directly (which I don't want because it is a pixel position and shouldn't be a float value), you would have to make a cast.

Code (cpp) Select Expand

sf::Vector2f mousePos = sf::Vector2f(sf::Vector2i(callback.mouse));

I will probably make it so that callback.mouse is a Vector2i so that you would only have to cast to Vector2f, but I'll do that in the latest version when I have time so you'll have to keep the extra cast for now.

It took me some time, but I think I have found the issue.

Your TurretWindow has a member turretPanels, which is a vector of InformationPanel. This InformationPanel contains an sf::Texture object. Sprites keep a pointer to the texture, so the location of the InformationPanel may not be moved. However, because you are using a vector, reallocation can take place when adding a new object. Your InformationPanel was moved and so was your texture, but the sprites kept the pointer to the old location.
There are different ways to fix this, but I think the easiest way would be to use a list of it instead of a vector. This does mean that you have to work with iterators instead of using the [] operator, so some code might need to change.

Its not related to this issue, but you should make two small changes to your code.
- In your addTurret function you pass **this as parent when creating InformationPanel. It should be *turretGrid as it is supposed to be part of the grid and not part of the child window.
- When you include a header, you should use '/' instead of '\'. That way I can at least compile your code without changes .

Okay, but the Panel holds only the pointer to the texture, right? So then I have to make sure the texture exists?

Yep

There aren't really any plans for that yet.
I would have to keep track whether or not the image was loaded from a file or not. It's not such a big change but I'm looking for a cleaner alternative.

But there is another workaround: create a panel with the size of the texture and use setBackgroundTexture on it.

In the future there will be another possibility because I will add an sfml canvas so that you can draw an sfml sprite in between tgui objects. (See blog post about combining sfml and tgui rendering)

Well that explains why I couldn't reproduce it .

I don't see any problems with this inheritance, it should be fine.
You don't even have to call removeAllObjects, it gets called automatically when your object is destroyed.

Based on your code you were using v0.6, which was all I needed to know in order to compile the code.

But what is the problem exactly?
You aren't calling setTextSize, so the text is scaled to fit inside the button.
When I add the setTextSize calls then the text gets the size that I passed to the function. I don't see any problems.

And you don't have to upload the whole VS2012 solution, the source code (or even a small example code) would have been enough. Unless it is for tracking a specific windows-only bug, I don't boot in my windows anyway.

What version of tgui are u using?

Can u show me the code that u use to create the button (so I can try to reproduce the problem)?

For now, you can just make the bug reports on this forum.

This is indeed a bug in tgui, thanks for reporting.

The EditBoxCallbacks enum in EditBox.hpp uses ObjectCallbacksCount. This should be changed to ClickableObjectCallbacksCount.
Either change this manually or just download tgui again, and then recompile.

PS: You can just write tgui::EditBox::ReturnKeyPressed instead of tgui::EditBox::EditBoxCallbacks::ReturnKeyPressed.

EDIT: I have a small problem with my dropbox, so I can't upload the new version immediately.