Messages

You are using SFML 2.3.2 procompiled libraries from the sfml website, right?
Then I have no more ideas on why it wouldn't work for you.

You could still try to remove everything of tgui from your pc (including the dlls in your project if you are linking dynamically), download the source code and build it yourself with cmake.

The only other thing you could do is start using v0.7-dev which is so different that the same issue can't happen. But that means that you have to rewrite the code that you already have.

The selectText function has been added in the latest version. If I don't do small changes like this right away then it would probably be forgotten.

And please correct the tip on facebook-twitter (switch) when hovering mouse on forum site!! ha!

Haha, nice catch. I have fixed it now but the old css file will still remain cached for a while.

That is indeed a good enough reason. Since exact control about what is being selected isn't really needed, I will just add a selectText() function which will select the entire text of the edit box. I still have to study a bit and I'm also working on adding a built-in font in tgui, so I'll add the function after that. So you can expect it in several hours or otherwise tomorrow.

Although I'm always interested to see where tgui is used, I'm only asking for a simple explanation on why you need to do this. I'm not going to add a function to edit box if it has no use, but if you can give me a use case then I will add such a select function. The function would be editBox->select(begin index, end index) rather than the setTextSelect that you suggest, but it can do the same. I currently just can't come up with any situation in which you would need such function.

I only use windows when I have to, I'm normally always on linux.

Why would you need to select text inside the editbox from your code?

The only thing that I can think of why it doesn't work if is if one of the libraries are incompatible (either wrong compiler version or debug/release mismatch). That leads to undefined behavior but I have only seen crashes due to this, never some part of the code that isn't functioning.

In codeblocks when you go to the settings you should have a tab "Toolchain executables". It states what c++ compiler executable you are using. Could you run that executable from the command line as "mingw-executable -v" and show the output?

Then I have no idea what it can be since it works fine here.
Did you download the precompiled libraries or did you compile tgui yourself? If precompiled, for which compiler?
What compiler are you using?
Are you linking statically/dynamically in release/debug and with the same kind of libraries? (e.g. not using release lib in debug mode)
Have you been using tgui for some time (a few days) already or did you just started with writing something? In the former case, did you ever get a working callback in another situation or are callbacks just not working at all?

Are you sure it isn't working? I changed your window.close() in a cout for some reason, is there nothing being printed in the terminal?

You should try to write a minimal and complete code that reproduces the issue.

If I turn your code fragments into a minimal and complete code then it works fine.

Code (cpp) Select Expand

#include <TGUI/TGUI.hpp>
int main()
{
    sf::RenderWindow window(sf::VideoMode(800, 600), "TGUI Window");
    tgui::Gui gui(window);
    if (gui.setGlobalFont("TGUI/fonts/DejaVuSans.ttf") == false)
        return 1;

    tgui::Button::Ptr quit(gui);
    quit->load("TGUI/widgets/White.conf");
    quit->setText("Quit");
    quit->setSize(230,50);
    quit->setCallbackId(12);
    quit->bindCallback(tgui::Button::LeftMouseClicked);
    quit->setPosition(100, 200);

    while (window.isOpen())
    {
        sf::Event event;
        while (window.pollEvent(event))
        {
            if (event.type == sf::Event::Closed)
                window.close();

            gui.handleEvent(event);
        }

        tgui::Callback callback;
        while (gui.pollCallback(callback))
        {
            if (callback.id == 12)
                std::cout << "CLICKED" << std::endl;
        }

        window.clear();
        gui.draw();
        window.display();
    }

    return 0;
}

So unless that code isn't working for you, the error must be in some other part of the code.

Happy new year to you too.

I have indeed removed the possibility to start comments with '#' in the theme files because I found out that the symbol was also used to store colors in the form of #00FF00. So you will have to use // instead (both ways were supported earlier).

The next tgui release is planned in February, so there's no rush

I fixed the remaining problems, you should pull my version and see if there is still something missing or not.

You can find my changes here: https://bitbucket.org/texus/tguitable
I have added a few things, but I also seem to have broken a few things.

Should setTextColor and setNormalTextColor actually do something to the existing labels? Because if the user has created some labels with a custom color then they would get changed as well. It might be better to just say that these functions set the color of all future labels and thus doesn't affect the ones that already exist.

I should have known that since you said 0.7-dev, there are no precompiled libraries for that version. But linking problems are the most common reason why tgui crashes on windows which is why I automatically assumed that this is another similar case.

I can't really think of anything other than a wrong library that could cause such crash though.

You didn't have any other tgui version installed before?

Are you compiling as Release with both SFML and TGUI compiled in Release, or in Debug with both libraries compiled as Debug? If they are all in debug perhaps you could show the callstack? That might indicate where it is crashing exactly.

Knowing that on windows everything has to match perfectly with each other while on linux it doesn't matter what you link, this sounds like something wrong being linked.

Since you mention you are using MinGW 4.8.3, my first guess would be that you are using the precompiled TGUI libraries which were compiled for MinGW 4.7 instead of compiling TGUI yourself for MinGW 4.8.3?

I think it would be best if you wrote the code to recalculate the positions and sizes of everything because I don't know yet what all variables do. Actually there probably shouldn't be a new function, updateWidgetPositions should just be extended to also set the sizes of the rows instead of only the positions. And then setFont should just call updateWidgetPositions at the end and the problem with manually having to call setFont will be gone as well.

It is a good point about it no longer being a VerticalLayout. I didn't know that VerticalLayout only contained an updateWidgetPositions function, I though it contained more.

I will take care of the setTextColor and setNormalTextColor and I will have a look at the TableItem and the events (tomorrow).
I will also change the insert function so that it will create a TableRow and insert the widget in it when you call insert with a widget other than TableRow.

Here are some remarks on the code. I can fix some of these things, but maybe you want to give your opinion on some of these points first.

There should be some function that recalculates the entire widget. The reason why you have to call setFont manually is because otherwise it only gets the font when gui.add is called. Even if I call updateColumnsDelimitatorsSize and updateWidgetPositions in the setFont function the text still doesn't show on the correct location because the only place where you set the height of a row is in the insert function which is called before the font is set. The setFont function should trigger some recalculation because changing the font might result in different text sizes.

Was there any reason to use BoxLayout instead of VerticalLayout in Table?

Perhaps HorizontalAlign::None can be renamed to HorizontalAlign::Default and then in the documentation of the setItemsHorizontalAlign function we can state that it changes the default alignment. This way it doesn't has to be marked as internal because using that would thus result in a clear documented behavior. The only problem would be when the user tries to pass Default to setItemsHorizontalAlign, but we can interpret that as the default gui behavior and thus set it to Left (or Center).

For setTextColor and setNormalTextColor you can loop over all widgets and check the result of dynamic_pointer_cast<tgui::Label>. If it is nullptr then it wasn't a label and you just ignore it, if it isn't nullptr then it is a label and you can set its color. Alternatively you can hold a boolean in the items but since the color is not changed much the little overhead of dynamic cast definately shouldn't be a problem.

For the mouseOnWidget function instead of passing (x-getPosition().x,y-getPosition().y) you just had to pass (x,y) but it seems like that is not enough to show the hover picure. The problem is also that your TableItem is receiving all events but is not relaying it to the widget (the other functions have to implemented like mouseOnWidget is now). It would be better if I fix this because I know more about this, but I do start to wonder if having a TableItem widget is really needed. Maybe the TableRow should just take widgets directly and be responsible for positioning them (the alignments would be stored in TableRow as a vector).

I have some time in the next few days to help with the Table class.

Could you perhaps make the code independent of your xal code? If the headers would not be in a xalTGUI subfolder, you would remove the Global.hpp include and if you would make example.cpp a standalone example code then I can just clone your repository and compile and run here. That would make it a lot easier for me to help with writing the code.

There isn't really a better way. It might be easier if you created a Label instead of an sf::Text and use label->getSize().x though.

If there is padding then it should also be included, the line should thus become:

Code (cpp) Select Expand

std::max(max, popumMenu->getRenderer()->getPadding().left + label->getSize().x + popumMenu->getRenderer()->getPadding().right)

I have found some time to implement a basic version of the resizable child windows. The mouse currently has to stand exactly on the border in order to start dragging it (so make sure the borders are thick enough). Since the cursor cannot be changed yet you also won't be able to see if you are actually on top of the correct pixel or right next to it. But I can add the changing cursor later without you having to change your code.

In order to use the feature, use the latest TGUI version from github and call the setResizable function on the child window (by default they are not resizable).

Code (cpp) Select Expand

childWindow->setResizable(true);

The config file seems to be wrong. Try replacing "ImageRotation = 0" with "ImageRotation = 90", does it work fine then? The rotation is closely related with mathematics, so 0° would mean that the line in the front image is facing to the right while 90° is upward like in your image.

Edit: You would also have to add 90 to the start and end rotations in your code to get the same knob as you have now.

It is still working here, but I noticed that my invalid area is on the left side, while in your screenshots it seems to be at the bottom. So the only thing that I can still think of that can be the issue is a difference in the config file. Could you also send the Knob.conf and the images so that I can test with them?

It should work both ways. The code that you last showed had the invalid area on the left side. When I click just above the middle it goes up, if you click right below the middle it goes down. It still works as intended when I set the rotations to 0 and 180.

So if it is only going to the maximum then you could still show your code and then I can check why it goes wrong in that situation (if I can reproduce it here).

That's actually intended behaviour, it sets the value to the closest possible location.