Read Access violation error when getting widget pointer from loaded gui

Started by Eisverygoodletter, 24 October 2021, 14:07:06


currently, I have this code:

sf::RenderWindow window{ {800, 600}, "TGUI window with SFML" };
tgui::GuiSFML gui{ window };
auto b = gui.get<tgui::Button>("loadFromFile");

the program throws a read access violation error on the gui.get<tgui::Button>("loadFromFile");
I can confirm that without this line the page loads normally.
I've already asked at stackoverflow , but I didn't get any answers :(


What is the contents of startMenu.txt? Are you certain it contains a button with the name "loadFromFile" or "a"?
The access violation happens on a nullptr, which is what the get() function returns when no widget exists with that name.


If I run

tgui::Widget::Ptr a = gui.get("loadFromFile");
std::cout << (a == nullptr);

it outputs 0 (it's not a nullptr)
If i use any other names, it outputs 1, (because of nullptr)

(attached file with startMenu.txt below. I checked the name inside)


Another really odd thing is that if I do

tgui::Widget::Ptr widgetPtr = gui.get("loadFromFile");
tgui::Button::Ptr ptrIWant = std::dynamic_pointer_cast<tgui::Button>(widgetPtr);

It doesn't throw me any errors, until I use a function like


where it gives me the read access violation error.

Some other functions such as

somehow don't throw a read access violation error


setSize is implemented in Button while isMouseDown is implemented in the Widget base class. If the first one crashes while the other does not then it may imply that the object is a Widget but not really a Button.
Since your code works here, I'm starting to wonder if there might be some library incompatibility that causes the Button class in your code to be different from the Button class in TGUI code.

Did you compile SFML and TGUI yourself or did you download precompiled versions from the websites? Which visual studio compiler are you using exactly? Are you certain you aren't linking to Debug libraries while in Release mode, or vice versa?
I noticed you mentioning debug mode but also mentioning tgui.dll, which is the release dll. Make sure to use the library with "-d" postfix in debug mode (for both SFML and TGUI).


sorry for the late reply...

The Issue fixed itself after I restarted Visual Studio 2019. Probably because of Visual Studio not updating the linking. Everything seems to work fine after I restarted Visual studio (and my computer). About the Debug or Release version i'm using, I was dynamically linking with Release, using precompiled versions from both websites for x32.

Basically I just had to restart Visual studio :|

Sorry for wasting your time :P