TGUI: a c++ GUI for SFML (with Form Builder)

[texus]

That gives me a linker error

It is fixed now.
I had always been wondering what dllimport was good for, now I finally know it.

[texus]

EditBox is now rewritten.
- The clipping has been improved.
- Scaling has been fixed.
- You can now change the layout of the text.
- Cleaned up some parts (more than 30% of the file was removed).

All changes were internal, so you can still use the EditBox the same way as before.
I just hope that I didn't introduced new bugs during the rewrite.

The text can be centered like below. If you want the text to be on the right side of the edit box then just change Center to Right.

editBox->textLayout = tgui::EditBox::Layout::Center

[model76]

Wow, that's cool, texus!

Unfortunately, there are some new problems with the EditBox:

On small (50x20) Left-aligned EditBoxes, the top and left of the first character is clipped. On right-aligned, it's the top and right of the last character.

Center-aligned text is not centered. In my case, with a 400x27 EditBox, it is 5 pixels to the right of the center.

I also think you should change "Layout" to "Alignment", since that is the right term.

Also, as I was building the library, I decided to look through all those compiler warnings, and they seem pretty easy to fix. Is that something you plan on doing at some point? All you need to do is to explicitly cast some variables, and not compare integers with booleans.

[texus]

I fixed the clipping problem and I renamed Layout to Alignment.

I tested the center alignment with an edit box of the same size and I don't see any problem at all (perhaps I fixed it together with the clipping problem). But if you still have this problem then I will need to know a little bit more e.g. what text you have inside the edit box.

You should just ignore the warnings in visual studio. I build in visual studio from time to time to fix them but most of the time I work on linux in CodeBlocks and it doesn't tell me where those conversions are wrong.
It has been some time ago that I have build with visual studio, so I will see if I can do it somewhere this week.

[model76]

First I have an embarrassing confession: I may have had a space at the beginning of the string I was testing the center alignment with. I have deleted the library files, so I have no easy way of going back to conform it, but it would explain the 5 pixel misalignment.
Anyway, it seems to work perfectly in this build.

The left and right clipping issue is gone. Unfortunately, the top is still being clipped.
With a 50x20 EditBox, the text size has to be set as low as 12 for the issue to disappear, and there seems to definitely be more room to draw the text.

I also tried the setBorders method, and that is producing some unexpected results. For instance, doing setBorders( 0, 4 ) on the 50x20 EditBox will enlarge the font.

[texus]

You can now go up to 16 pixels. It was another small mistake in the clipping calculation.

I also tried the setBorders method, and that is producing some unexpected results.

Actually, what you see is the expected behaviour.

The borders define in what area the text will be centered.
If you set the bottom border from 4 to 0 (which you are doing when only passing 2 parameters to setBorders) then the text will be placed lower. If you are auto-sizing then the text will also be given more space so it will become bigger.

You should usually stay away from the borders. They are set to make sure that your text will not be drawn on specific parts of the edit box. The Black style defines its borders as (6, 4, 6, 4) which means that on the left and right side there should be 6 free pixels and on top and bottom 4 pixels (when the images are drawn at full size). You are drawing the images at half size, which leaves 2 pixels at bottom and top, hence the maximum text size of 16.

If you do want the to be drawn the text as big as possible then you should change the borders to 0. You might want to keep the left and right border at 6 though to avoid the text from being drawn over the rounded edges of the edit box.

[model76]

Ah, that makes sense, then. Thanks for the explanation.

In the new build the EditBox is much more usable. Nice work.

[CombatWombat]

I cannot get buttons to throw any callbacks.  I have commented my program back down to effectively nothing, even setting default views and such.  But I never get any "mouseover" highlight, and it never enters the callback block.  The button otherwise displays correctly.  I just rebuilt SMFL2 (latest snapshot) and TGUI (0.5 from "download latest revision" on homepage) again to make sure I was up to date, but that did not change anything.

    ////////////////// Setup Window //////////////////////
sf::VideoMode mode = sf::VideoMode(1024,768,32);
tgui::Window window(mode, "Terran Command 0.0001 Alpha");
window.globalFont = defaultFont;

tgui::Button* button = window.add<tgui::Button>();
button->load("Gui/Button/Black Square");
button->setText("BUTTON");
button->callbackID = 1;

//////// Main Loop //////////////////
    while(window.isOpen())
    {
        HandleEvents(window);
        tgui::Callback callback;
        while(window.getCallback(callback))
        {
            std::cout << "Anybody?" << std::endl;
        }

        window.clear();
        //window.draw(bg0);
        window.drawGUI();

        //window.setView( sf::View( sf::Vector2f(750, 500), sf::Vector2f(mode.width*4, mode.height*4)));  // Set view for drawing game objects
        window.setView(window.getDefaultView());
        //vertexArray.s = texPage.GetTexPage();       // Select texturePage for vertexArray
        //window.draw(vertexArray, vertexArray.s);    // Draw vertexArray

        window.display();
    }

What am I missing?

[texus]

I guess you are not sending events to the button.
You will need to poll the sfml events and pass them to tgui with window.handleEvent(event).

[CombatWombat]

Ah, yep.  Missed that one in your setup tutorial.  Works now, thanks for the speedy reply.

I think the name "handleEvent(event)" kind of blends into the woodwork of the SFML event system that is already there.  It isn't very clear that it is related to the GUI working.

Maybe something like
"HookEventsToTGUI" or something similar that makes it clear what its really doing.

[texus]

Something like hookEventsToTGUI or passEventToObjects should indead be more clear.
I'll probably just put another poll on my site and let everyone vote on which name they think is best.

Talking about the poll, those who requested a Tab object won't have to wait much longer as it is almost finished.

[CombatWombat]

Minor thing...

setText() seems to lose leading spaces in the string.  I am having some trouble with text overlapping on my checkboxes, and I cannot space it out this way. 

[model76]

Something like hookEventsToTGUI or passEventToObjects should indead be more clear.

Only for those who choose not to separate the GUI from the window. This is one of the reasons why I think inheriting sf::RenderWindow is a bad idea to begin with. A GUI system is not a RenderWindow, and pretending it is will lead to things like this.

[texus]

setText() seems to lose leading spaces in the string.

If I would allow spaces in front of the text, do you expect the area of the spaces to be clickable or not?

Only for those who choose not to separate the GUI from the window.

I'll leave it like it is now in the Form class.

[CombatWombat]

setText() seems to lose leading spaces in the string.

If I would allow spaces in front of the text, do you expect the area of the spaces to be clickable or not?

By all means, do not show leading spaces.  But I can't figure out how to make my text not overlap the button.
It's entirely possible I just don't know what I'm doing.  In fact, that's very likely.