Messages

Glad to see that TGUI is used in a ludum dare by other people than myself .

The game looks good, well done!

If you would like to make tutorials then that would be very kind.

Maybe the most important one right now would be a tutorial about how to configure visual studio to use the library. So if you want to do something you could perhaps make a few screenshots that fit these instructions.

Other than that, I'll put any helpful tutorial online.

But maybe the tutorials shouldn't be placed on my site, but on the github wiki? That way everybody could just add useful tutorials.

For now, I'll let addLine return the numbers of lines.

The other option is better, but requires a bit more work (e.g. make sure that a newline in a label has the same spacing as the lines that I manually place below each other).
I'll implement it somewhere soon, but for now you'll have to do with the first option.

Edit:
With the Notepad++ way, what do you expect that happens when the string that you pass to addLine has a '\n' character? Should it count as two lines or should everything passed to addLine count as a single line?
I'm thinking of something like skype. In your message you could still add newlines, and it would be nice that the whole message could be treated as a whole. But on the other hand, it also makes sence that when encountering a newline means that the lines are split.

The three functions have been added.

I could add the following functions:

Code (cpp) Select Expand

sf::String getLine(unsigned int lineNumber);
void removeLine(unsigned int lineNumber);

Maybe I should add this as well?

Code (cpp) Select Expand

void setLineLimit(unsigned int maxLines);

But the right click is a bigger change. I was trying to delay that until I was going to add a PopupMenu widget (probably not in v0.6).

It's fixed now.
I once made a change to the function, but it seems like I didn't update all widgets.

The mistake becomes clearly visible if you put these lines below each other

Code (cpp) Select Expand

void tgui::ChatBox::mouseWheelMoved(int delta);
widget->mouseWheelMoved(event.mouseWheel.delta, event.mouseWheel.x,  event.mouseWheel.y);

Sure, I got no problem with that.

Actually, it is possible to focus the child window automatically. But I'll have to look into the consequences of such change first.

Ah, indeed, you can't type in it.

The ChildWindow has to be focused in order to pass the event to the EditBox, so you should focus the child window as well.

Code (cpp) Select Expand

else if (event.type == sf::Event::TextEntered && event.text.unicode == '`')
{
    childWindow->focus();
    editBox->focus();
}

Automatically focusing the child window when the edit box gets focused is currently not possible, but it will probably be added in the future.

This code works for me. The edit box gets focused when I press the '`' key (isn't a tilde '~'?).

Are u using the latest tgui version?

The focus function should do the job, could you post a minimal code of what you are doing (to make sure that we are testing the same thing)?

There is nothing wrong with TGUI in this case. What you are asking was already supported.

I just tested it and it seems that no MouseButtonReleased event is send when the mouse is released outside the window (on Windows). So that sounds more like an SFML problem. If the MouseButtonReleased would be sent (like it does on linux), then it will work.

I doubt that many people are not going to use my library just because they need c++11. Most VS users have the express version anyway, so they can easily upgrade. And anyone downloading MinGW will also have c++11 support.

But those who really don't want to upgrade to a newer compiler (which I can understand in some situations) can still use tgui v0.5.

ListBox?

I'm not sure what you mean with interactable buttons though.

is there a reason they aren't generally distributed?

They are almost as big as the library itself.
In the case of tgui the difference won't be very big, but if sfml would provide pdb files then the download would become a lot bigger.
I'm just not distributing them because sfml doesn't do it.

v0.5 has the limitation that all widgets just send callbacks on all situations. In this case button can handle both mouse pressed and mouse clicked callbacks, so both will be send. This has been fixed in v0.6 where you specify which particular callback you want.

In your own code you could check if the callback.trigger equals tgui::Callback::mouseClick and otherwise ignore the callback.

Or if it becomes bothering to always check against the trigger then you could remove everything except the "m_MouseDown = true;" from the leftMousePressed function in Button.cpp on line 515.

You need the pdb files in order to debug the library, but I don't distribute them (neither does sfml). You only get these when you compile tgui yourself.

On windows the debug libraries aren't just made for debugging the library. You need debug libraries when you compile your own program in debug mode. It is more logical on linux where debug libraries are indeed only needed for debugging the library itself, and in all other situations you can just use the release lib.

Try with commenting out parts of your code, try using only sfml code but still linking to tgui and then add the tgui code again bit by bit. See where it goes wrong.

I hate windows, I can't even get my own library working. I either get tons of opengl errors, or a crash on exit, but it just won't work anymore and I don't even get the exception like you do.

Edit: The pdb file can be downloaded here.

You could try following the CMake tutorial and compile the library yourself. It is possible that I messed up the precompiled lib (if I think of it, I used the latest sfml headers but the sfml 2.1 libraries).

I am trying to test the libraries myself right now, but all I get are opengl errors so I'm going to reinstall my graphics driver first (not sure if thats going to help much though).

I never had that problem so I can't immediately tell whats wrong.

Did you download the precompiled version (created only a few hours ago) or did you compile tgui yourself?
Which compiler are u using?

Maybe you are linking to the release version of tgui while linking to the debug version of sfml?

Edit: Does the 'first chance exception' says what type of exception?

I found the issue.

You were linking to the static sfml libraries, but to the dynamic tgui libraries. This isn't possible (because tgui uses the SFML_STATIC as well). I am very surprised that this is even possible, I would have expected tons of errors or warnings in this situation.

So if you link to tgui-s.lib instead of tgui.lib then the problem should go away.

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.