Messages

It is possible with the tgui::Texture class, but I just noticed that there is no easy way to create it from an existing sf::Texture, it only takes a filename.
I'll check if I can improve this without breaking existing code.

It isn't possible directly, Cavas was created exactly for these cases where you needed to do this.

One option would be to create a custom widget though. Create a new class that inherits from tgui::ClickableWidget and override the draw function with something like this:

Code (cpp) Select Expand

void CustomWidget::draw(sf::RenderTarget& target, sf::RenderStates states) const
{
    states.transform.translate(getPosition());
    sf::RectangleShape background(getSize());
    target.draw(background);
}

Just to clarify that only canvas uses RenderTexture? So if I convert my SFText to labels then I would not need a canvas as I can draw them directly onto the childwindow container?

Yes, RenderTexture is not used anywhere else.
If they are labels then they can indeed be drawn directly to the child window.

Also can childwindows have background image?

The possibility to assign a background image to child window was removed a long time ago since you could do the same by creating a Picture of a Canvas and adding it to the child window.

The reason why the blink would be longer with Canvas is because both the creation and the setSize call will call renderTexture.create so I would expect the blink with Canvas to be twice as long as the code you have now. Maybe the clear/display in setSize make it even longer as well.

I doubt that it has anything to do with TGUI and since it blinks with just sf::RenderTexture it does indeed look like its directly related to SFML.

But if you go to the SFML forum I already know what they are going to tell you: this is a graphics driver issue. Hundreds of people use sf::RenderTexture without having such blinking so this is not going to be a mistake in the SFML code. It would rather be the combination of specific opengl calls from sfml in combination with your graphics driver. So I suggest you try update or downgrade your graphics driver before trying anything else and see if that makes a difference.

Canvas is the only widget that uses sf::RenderTexture so I still think it is related to that.

There are a few things you could look at:
- What happens if instead of canvases you just create a render texture (call create, clear and display on it)? Does it cause blinking as well?
- What if you create the canvases upfront and in setupCanvas you just retrieve the canvas? (you can't call setSize in setupCanvas either because it will cause the render texture to be recreated)
- Try removing the m_renderTexture.clear() and m_renderTexture.display() call inside tgui::Canvas::setSize (src/TGUI/Widgets/Canvas.cpp lines 98 and 99)

Are you calling canvas->clear() and canvas->display() around your canvas->draw() calls?

If you are then all I can think of is a problem with the graphics driver.
Canvas is just a wrapper around sf::RenderTexture and an sf::Sprite to draw it. I have seen weird things happen with render textures before.
If you have the latest driver then you will have to verify whether this is an issue with sfml or tgui:
To test you might want to replace the Canvas with a sf::RenderTexture. It could be passed to a picture to render it with tgui with pic->setTexture(rt.getTexture()). The render texture does not has to be stored since picture copies the texture.
If it still occurs then you could even try without using tgui at all and create a render texture which you draw to the screen yourself on the position of the child window (it has a getChildWidgetsOffset() to find the distance between its position and the area where the widgets in it are drawn).

It should be "&GameEngine::Quit" instead of "&(game->Quit)".

The "Connecting member functions" section in the tutorial shows an example of this.

Great, thanks. I've updated TGUI now to use memcpy.

If only the Visual Studio compiler would be better, I would be able to run my tests on windows and try to prevent issues like this.

Thanks for finding the issue. I have no idea why strcpy_s would suddenly fail though, that code worked fine before.
Could you test one last thing? Try replacing it with this:

Code (cpp) Select Expand

memcpy(pchData, m_contents.toAnsiString().c_str(), m_contents.getSize() + 1);

It is stupid that I handled this line differently in v0.6 and v0.7. In TGUI 0.6 I replaced strcpy with memcpy while for TGUI 0.7 I decided on using strcpy_s.

Also a GlobalFree i beleive is missing from get(). Not sure...

I just looked it up again and the MSDN example on clipboards doesn't has a free so I guess it is not needed since there is no alloc call like in the set function.

How can i help u more?

When it crashes you should be able to break and see where it crashes exactly. If you are in debug mode you must also be linking to the debug tgui library so there will be a very detailed trace of where it crashes. If you can send the contents (or a screenshot after making sure the whole lines are visible) of the call stack window in VS then I should have some information to start looking at.

I can't reproduce it on my windows machine but I'm having other issues here that might influence the result. Just to be certain, you can select text by dragging with your mouse right?

On my linux on which I develop I can't reproduce it either, but that is probably because the issue is going to be in the windows specific code that accesses the system clipboard.

So hopefully with a callstack I will be able to determine what is going wrong and fix it, because I may not be able to debug it myself soon.

Could you perhaps send me the callstack when it crashes in debug mode?

Are shortcuts supported by editbox?

They are supposed to work.

I wanted to write a tutorial about it because someone else asked for an explanation too, but eventually I discovered a bug while doing so and I spend the time that I had with fixing it and finishing the tests for the Texture class instead of actually writing the tutorial.
Writing a tutorial is a boring task anyway so I'm not really motivated to write it during these few hours a week that I have some spare time now.

The values are (LEFT, TOP, width, height) but for the Middle rect it should be noted that it is relative to the Part rect (if Part rect is given).

The Part and Middle rect are both optional, to load the image from a separate file, just write the following:

Code (css) Select Expand

NormalImage : "ThemeNormalImage.png";

The layouts allow you to make the position or size of a widget relative to a different widget.

The tgui::bindWidth(widget) function for example will as far as you should be concerned just return the same as widget->getSize().x. The only difference is that when the width changes then the place where the layout is used will update as well. If you call widget2->setSize(bindSize(widget1)) then when the size of widget1 changes, the size of widget2 is automatically updated.

The bindRange function is probably the most useless function of all the bind functions (I don't even know a use case for it). If you call widget->setPosition(0, bindRange(min, max, val)) then the top position of the widget will be val unless val is less than min or higher than max. Since min, max and val are expressions that may contain bind functions, once any of the bound values changes, the top position of the widget is recalculated based on the new values.
Maybe I should should remove the bindRange function from the tutorial.

Intresting, I have been able to reproduce it with the latest SFML version, but not with the old version that was still on my pc (which according to Config.hpp is 2.3.1).

The following code reproduces it, so it is definately an SFML problem.

Code (cpp) Select Expand

#include <SFML/Graphics.hpp>
#include <memory>

int main()
{
    std::shared_ptr<sf::Font> font3;

    sf::Font font1;
    font1.loadFromFile("sansation.ttf");

    font3 = std::make_shared<sf::Font>(font1);

    sf::Font font2;
    font2.loadFromFile("sansation.ttf");

    font3 = std::make_shared<sf::Font>(font2);
}

I'm going to see if I can find out in which commit the bug was introduced.

Edit: The bug was introduced in 957cabb, earlier SFML versions don't crash.

Edit2: Reported on SFML forum

I tried to debug it myself today but I can't reproduce the issue. I tried the code that you posted without the "assets/" and it runs fine on my emulator.

I would find it strange if this would be specific to hardware, so perhaps the difference could still be in the library versions that we use. Which sfml and tgui versions are you using?

Btw, did you have to do anything that isn't mentioned in the tutorial to compile tgui for android? Because I only tested it on linux so far and I wonder if there are differences with compiling it on mac.

According to the stacktrace it is happening when the default font is destroyed. It still looks like a problem with sfml, but I will first have to come up with an example without tgui that can reproduce this crash to prove that.

The following code still uses something from tgui, but if this also fails then I'm on the right track:

Code (cpp) Select Expand

#include <TGUI/DefaultFont.hpp>
#include <SFML/Graphics.hpp>
#include <memory>
#include <iostream>

int main()
{
    std::shared_ptr<sf::Font> font;

    sf::Font font1;
    if (!font1.loadFromMemory(defaultFontBytes, sizeof(defaultFontBytes)))
    {
        std::cerr << "Could not load default font" << std::endl;
        return 1;
    }
    font = std::make_shared<sf::Font>(font1);

    {
        sf::Font font2;
        if(!font2.loadFromFile("sansation.ttf"))
        {
            std::cerr << "Could not load font" << std::endl;
            return 1;
        }

        font = std::make_shared<sf::Font>(font2);
    }

    return 0;
}

PS: If the forum is loading too slow (it seems to have become really slow in the last 2 days), you can contact me directly on vdv_b@tgui.eu.

I meant without the setFont call, because setFont really shouldn't do much more than copying the font like that.
So if the copy itself is failing (which the backtrace seems to indicate because it contains sf::Font::loadFromStream) then this is still an issue in sfml and I won't be able to help with it.

Edit: based on the backtrace I expected loadFromStream to be used when copying the font but it doesn't seem to do that when looking at the source code. But it has to be called from somewhere.

Edit2: Are you certain the problem isn't already happening inside font.loadFromFile, it does call loadFromStream internally?

Does the following work?

Code (cpp) Select Expand

auto font2 = std::make_shared<sf::Font>(font);

The issue is apparently already fixed by fixing your first issue. So it should work fine with the latest version.

I didn't write the Table class and what you see in the example code is the only test that was done with the class so there will probably be more of these small issues.

I fixed the first issue but I can't reproduce the second one. Could you show the code that you are using for the Table?

Apparently I forgot to push the vertical alignment in label to github. So that feature is now in the latest version as well.

The regex is wrong. I don't think you need the backslashes in front of the comma (only in front of the dot because a dot has a special meaning). But your regex requires your text to have a comma and optionally a dot inside it. So the string ",." is also valid. You can use | as an OR so the regex can be: "[0-9]*(,|\\.)?[0-9]*". It will match either a comma or a dot or neither (due to the question mark) but not both. Alternatively you can also use "[0-9]*[,.]?[0-9]*" which is slightly shorter.

And I just read that you can match digits with \d, so you can even write it as "\\d*[,.]?\\d*". More information about the syntax can be found here.

<AdditionalDependencies>sfml-system-d.lib;sfml-window-d.lib;sfml-graphics-d.lib;tgui.lib;%(AdditionalDependencies)</AdditionalDependencies>

It appears that you are linking to tgui.lib in debug mode instead of tgui-d.lib. So if your project is in debug mode this could go wrong.

Are u kidding me? Have u finished already?

Yeah, I don't have much other things to do . My exams are over and I still have one more week before the next semester starts. So any relatively small feature requests can be implemented immediately during this time.

Since I saw your post before the edit I ended up implementing separate functions. Although I would have actually chosen the one from Grid myself too since it saves one line of code when you want to set both alignments, it doesn't really matter that much.
So the code to center your label is now this:

Code (cpp) Select Expand

label->setHorizontalAlignment(tgui::Label::HorizontalAlignment::Center);
label->setVerticalAlignment(tgui::Label::VerticalAlignment::Center);