Recent posts

#61

Help requests / Re: Weird error after updating...

Last post by texus - 16 November 2024, 18:12:56

it won't load the SFML libraries because they're not signed correctly

I vaguely remember that you had to go into the macOS settings somewhere and press a button to add an exception for the unsigned library. And you had to do the whole thing once for each library (i.e. separately for sfml-system, sfml-window and sfml-graphics). But maybe there is some setting in xcode to completely disable this security.

Now I get BAD ACCESS errors from my class destructors that use TGUI. Does 1.6.1 require explicit cleanup steps that 0.6 didn't?

It doesn't require explicit cleanup, but no TGUI widgets or textures are allowed to exist anymore after the backend is destroyed (which happens when calling setBackend(nullptr) or in the destructor of the Gui object if you don't manually create a backend). If TGUI objects still exist afterwards then their destructors would crash at the end of the program.

Porting old code to fit these new restrictions can of course be annoying. If you write new code then it would immediately give you an error when doing something like that, and you know you have to change the code that you just wrote. When porting existing code it might be more difficult to find the issue and potentially redesign it a bit to make things execute nicely.

#62

Help requests / Re: Weird error after updating...

Last post by johnnywz00 - 16 November 2024, 18:00:41

Your instructions for explicitly building the backend before creating the EditBoxes have helped me at least get the program running. Thanks for that! I'd really rather not leave that block in my code, though, so I still want to get to the bottom of the issue. I'm trying to duplicate the project in a fresh XCode project, but for one reason and another I'm having trouble getting things running. This new project is claiming that it won't load the SFML libraries because they're not signed correctly. So many headaches for juniorish-level computer hack.

Separately: I don't remember having to run any explicit cleanup code for TGUI 0.6 when I first made these projects on an Intel Mac. Now I get BAD ACCESS errors from my class destructors that use TGUI. Does 1.6.1 require explicit cleanup steps that 0.6 didn't?

#63

Help requests / Re: Weird error after updating...

Last post by johnnywz00 - 16 November 2024, 04:01:13

The Game class has no members that construct TGUI elements. The Gui is not in a global. I have a growing suspicion that XCode could be messing something up. I renamed a directory or the project name or something that messed up tracking somehow. I will let you know if I find it out. In the meantime I may try to build the backend like you suggest and see if it's a workaround. But I'm probably not going to be content until I know why it's giving me this inexplicable behavior!

#64

Help requests / Re: Weird error after updating...

Last post by texus - 15 November 2024, 18:36:15

Are there any other things I need to change?

None that I can think of.

Is it viable to have a Game class with `tgui::Gui  gui;`  and then call `gui.setTarget([RenderWindow&])` in the class constructor?

Yes. You just have to be careful about which objects you put in the same class.

TGUI is only fully constructed once you make the setTarget call. Suppose the class containing the Gui is called Game. If Game contains a member called MenuScreen, then the constructor of MenuScreen will execute before the constructor of Game. So if inside the MenuScreen constructor you call tgui::EditBox::create(), then you would have an issue.

I imagine that your issue is similar to the case described above.
Alternatively, maybe the class that contains the Gui is a global variable? That could also cause serious issues (although you probably would have already faced some before in that case).

Ideally you would create the Gui at the correct spot to avoid issues. If for some reason it is too difficult: there is a way to manually construct the TGUI backend. By default the Gui creates the backend internally to reduces the amount of work you have to do, but it has the downside of complicating the lifetime of the backend.
An alternative is thus to manually create the backend object. This can be done before the SFML window is even created, so you would essentially just put the following as the very first lines in your main function:

Code (cpp) Select Expand

auto backend = std::make_shared<tgui::BackendSFML>();
backend->setFontBackend(std::make_shared<tgui::BackendFontFactoryImpl<tgui::BackendFontSFML>>());
backend->setRenderer(std::make_shared<tgui::BackendRendererSFML>());
tgui::setBackend(backend);
At the very end of your main function you would put the following line:

Code Select Expand

tgui::setBackend(nullptr);

When creating the backend manually like that, you can work with widgets before the Gui is constructed without any issues.

#65

Help requests / Re: Weird error after updating...

Last post by johnnywz00 - 15 November 2024, 15:39:15

I really appreciate the swift replies. You are correct that the backend is resulting in a nullptr, but I can't figure out why, because the TGUI-specific code seems to be the same in this problematic project as it is in a similar project that isn't throwing this error.

I never really read any docs about new protocol for using 1.6.1, but I stumbled across the fact that you now include a backend header and change tgui::GuiSFML to tgui::Gui. Are there any other things I need to change? Is it viable to have a Game class with `tgui::Gui  gui;`  and then call `gui.setTarget([RenderWindow&])` in the class constructor?

[check where you are passing the window to the gui. This is the moment that the backend will be created, all widget creations should happen later]

#66

Help requests / Re: Weird error after updating...

Last post by texus - 14 November 2024, 22:19:36

I checked the code and it seems like there is no error in Release mode when attempting to use a backend that doesn't exist. If TGUI is built in debug mode then it would print something to the terminal and terminate.

The bad access happens on address 0x30, such a low address means that it tried to dereference a nullptr.
With that call stack, the only explanation that I see is that the backend would be a nullptr.

Try printing the value of "tgui::getBackend()" before creating the edit box. If my theory is right then it it will be a nullptr and calling "tgui::isBackendSet()" will return false. If this is the case then check where you are passing the window to the gui. This is the moment that the backend will be created, all widget creations should happen later. This restriction was added in TGUI 0.9 (when making the library work with other backends than SFML) so the old TGUI versions had no problems with creating widgets earlier.

Not all widgets create their resources immediately, which could explain why creating some widgets do work. I imagine that e.g. RadioButton will also cause the crash.

#67

Help requests / Re: Weird error after updating...

Last post by johnnywz00 - 14 November 2024, 21:56:11

The only message I see is "bad access". And this program worked until I moved the project to a new computer and upgraded to 1.6.1.
There is a Gui object.
There is no error trying to create other kinds of widgets, just EditBox.

ARM Silicon Mac running Sequoia

#68

Help requests / Re: Weird error after updating...

Last post by texus - 14 November 2024, 15:50:32

I'm assuming the message in the thrown error is about no backend existing?

You must first create a Gui object and attach a window to it before you are allowed to create any widgets. Otherwise the widgets can't create textures or texts.

#69

Help requests / Weird error after updating to ...

Last post by johnnywz00 - 14 November 2024, 15:12:07

Some time ago I wrote some SFML projects using TGUI 0.6, mainly to implement a high scores window. Now I've moved my work to a new computer and upgraded to 1.6.1. The first project seemed to go fine. The second project is almost copy-paste of the first in terms of the code that uses TGUI, to implement high scores.
I am getting a bad access error with the simple line
```
auto eb = tgui::EditBox::create();
```
What is most odd to me is if I cut that line and paste it as the very first line in `main()`, it still throws the error. And yet `tgui::Panel::create()` (and probably most others) do not throw the error. Any explanations?

The stack trace seemed to indicate it was on Backend::createText

Thanks!

#70

General Discussion / Re: multiple windows

Last post by texus - 06 November 2024, 19:49:58

In the latest TGUI version, gui.handleEvent will now return false when the event is for a different window.
I didn't put it behind an option, the filter is always enabled.