Recent Posts

Pages: [1] 2 3 ... 10
1
Feature requests / Re: Visual Studio warnings
« Last post by texus on Yesterday at 19:19:08 »
I am aware that VS gives some warnings, this will often be the case. Occasionally I do fix those VS warnings (usually right before I release a new patch version), but because I work on linux with gcc I only see the warnings given by gcc. If a warning is serious then it is likely that gcc will also the warning, so the warnings that do occur are usually about int/float or signed/unsigned mismatches. I do care about these things, I wish that gcc showed them too in which case I would fix them immediately, but I'm not going to constantly check the windows logs just to see if there is any minor warning.

I also rely on unit tests to find code issues. I've had windows tests failing on multiple occasions while everything passed on linux, but I have never encountered any bug that got through those tests but would have been fixed if I had gotten these few extra warnings. This is why I consider them mostly harmless. That being said, I do prefer it if my projects build without any warnings at all on all compilers, even if the warnings aren't important, so I will probably fix them this weekend or so unless someone sends a PR before that time. (The one in CopiedPtr.hpp isn't going to be fixed, it is a false positive and it also isn't part of TGUI but part of the external Aurora library)

It has been longer than usual since the last patch release, which is also why it is longer than usual since I built with VS.
2
Feature requests / Re: Visual Studio warnings
« Last post by billarhos on Yesterday at 09:20:23 »
hi, compiling with vs 2019 16.2.5 , 10.0.18362.0 sdk version and Level4 (/W4) warning level, i have the following warnings.

Quote
2>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.22.27905\include\xutility(2866,22): warning C4389:  '==': signed/unsigned mismatch

Quote
2>D:\Pandora\ThirdParty\TGUI-0.8\src\TGUI\Widgets\Label.cpp(625): message :  see reference to function template instantiation 'int std::count<sf::String::Iterator,char>(const _InIt,const _InIt,const _Ty &)' being compiled
2>D:\Pandora\ThirdParty\TGUI-0.8\src\TGUI\Widgets\Label.cpp(625): message :         with
2>D:\Pandora\ThirdParty\TGUI-0.8\src\TGUI\Widgets\Label.cpp(625): message :         [
2>D:\Pandora\ThirdParty\TGUI-0.8\src\TGUI\Widgets\Label.cpp(625): message :             _InIt=sf::String::Iterator,
2>D:\Pandora\ThirdParty\TGUI-0.8\src\TGUI\Widgets\Label.cpp(625): message :             _Ty=char
2>D:\Pandora\ThirdParty\TGUI-0.8\src\TGUI\Widgets\Label.cpp(625): message :         ]

Quote
3>D:\Pandora\ThirdParty\TGUI-0.8\gui-builder\include\WidgetProperties/EditBoxProperties.hpp(44,56): warning C4244:  'argument': conversion from 'sf::Uint32' to 'char', possible loss of data
3
Feature requests / Re: Visual Studio warnings
« Last post by Kvaz1r on 18 September 2019, 19:29:07 »
It's seems as false positive. mOwner can't be dereferencing with null  here because it initialize with same condition as mOwner itself.

But are you sure that you use latest version of compiler because I didn't get it for VS 16.2.5.
4
Feature requests / Visual Studio warnings
« Last post by Ardent Coder on 18 September 2019, 17:09:32 »
It is good to have a project compile with no errors and warnings. But sometimes third party libraries introduce warning messages into our projects and so is the case with TGUI.
I think you should build the library in Visual Studio because it provides serious warnings as well that are ought to be noticed. One of the four warnings I'm currently getting says "Dereferencing NULL pointer mOwner" inside CopiedPtr.hpp line 121, which I guess, can prove fatal during runtime!
I hope these issues will be solved in an upcoming version of this library so that the developers can build their projects without worrying about the warnings that are produced while compiling such libraries.
5
Help requests / Re: OOP and TGUI
« Last post by texus on 17 September 2019, 22:35:28 »
I don't do it because i don't want to complicate the code. It doesn't add much complexity, but I feel like the minimal examples should be as straightforward as possible: just a main function with the minimum required code in them. By adding classes you are adding stuff to the code that is irrelevant to the example.

I'm not against OOP for larger examples, but for the really simple examples I don't really feel that it is needed.

It might be a good idea to have at least one example with a class though, it could be useful to demonstrate how to initialize the gui in a class and how to connect member functions. These are cases that people likely face but are currently not covered in the examples.

Calling setTarget is one way to do it, but even in a class you can still use the constructor by using the initializer list:
MyFrame::MyFrame(int argc, char* argv[]) :
    window(sf::VideoMode(800, 600), "TGUI window"),
    gui(window)
{
6
Help requests / OOP and TGUI
« Last post by Kvaz1r on 17 September 2019, 11:58:45 »
I noticed that all examples use only "all in main" style. Is there any reason why it don't write in OOP-style?
Minimal example(it took for me a while before I realize how create Gui inside class):

Code: [Select]
#include <TGUI/TGUI.hpp>

class MyFrame
{
public:
    MyFrame(int argc, char* argv[]);
    void main();

protected:
    tgui::Button::Ptr m_Button;

private:
    sf::RenderWindow window;
    tgui::Gui gui;
};

MyFrame::MyFrame(int argc, char* argv[])
{
    window.create(sf::VideoMode(800, 600), "TGUI window");
    gui.setTarget(window);
    auto panel = tgui::ScrollablePanel::create();
    m_Button = tgui::Button::create("Press");
    panel->add(m_Button);
    gui.add(panel);
}

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

            else if (event.type == sf::Event::Resized)
            {
                window.setView(sf::View(sf::FloatRect(0.f, 0.f, static_cast<float>(event.size.width), static_cast<float>(event.size.height))));
                gui.setView(window.getView());
            }
            gui.handleEvent(event);
        }

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

int main(int argc, char* argv[])
{
    MyFrame f(argc, argv);
    f.main();
}
7
Feature requests / Re: Add table widget
« Last post by Kvaz1r on 16 September 2019, 19:54:03 »
great, thank you
8
Feature requests / Re: Add table widget
« Last post by texus on 16 September 2019, 19:49:19 »
I made setItemColor virtual now.
9
Feature requests / Re: Add table widget
« Last post by Kvaz1r on 16 September 2019, 19:48:11 »
Yes, you're right, it's my mistake.
10
Feature requests / Re: Missing .pdb files
« Last post by Ardent Coder on 16 September 2019, 19:16:19 »
Thank you
Pages: [1] 2 3 ... 10