Messages

Just letting you know that I have finally solved the EditBox error, and as suspected it was a result of my class structure. In this second project there is no StateManager and the GameState was getting some init called (in which the gui high scores are set up) in the Game constructor, *before* the gui's target had been set. Transposing the order of two lines fixed the problem... what an oversight! But I'm learning.
I've now got no remaining TGUI related errors and can keep happily programming away!

Ah, that's it!! Thank you, and sorry that I'm so dense. I now have one TGUI project that's error-free and one project that still gets BAD ACCESS when I create EditBoxes unless I manually construct the backend. But I expect that that is a result of how my classes are structured and I am much more inspired to figure it out especially now that I know the restructuring fixed this problem.
Thanks Texus!

Ah, the StateManager is indeed declared above the Gui. I will swap that now and see...

Yes, it prints. After main() finishes, ~Game kicks in which (in this case) calls ~StateManager which calls ~PlayingState, which appears to be calling the destructor of some vector related to an EditBox or a sharedptr of EditBox... ultimately reaching unregisterFont...
The "LetterInvadersState" which you see stores a bare pointer to the Gui object which is a member of the Game class. But LetterInvaders is the class that creates and uses the EditBoxes. Would there be a difference if I constructed all the Widgets in the Game class, and only displayed them through the LetterInvaders class?

Agh. My *other* project, (which didn't throw any errors creating the EditBoxes) *does* throw BAD ACCESS on exiting the program if the EditBoxes have been created. In this other project, there is a menu screen, where the EditBoxes aren't created till you enter the gameplay part. So if you open the program and quit without clicking the start game button, no error will occur. But in both programs, if the Gui creates EditBoxes, there is a bad access when the Game or GameState class destructs.
Could for some reason the m_registeredFonts vector be empty?

I got the new XCode project to run. The EditBox error persists even with a fresh start. It must be something in my code structure, because as I said, I have a similar project on this computer that is running TGUI without error. The code lines that reference TGUI are identical between the two projects (it's the same  high score system), but a few of the lines are located slightly differently because the class structure is a little different. I'll examine that further.

The exit error is coming from Backend::unregisterFont, coming from destructor of an EditBox. But given that this is the same XCode project that was inexplicably throwing bad access to create EditBoxes (until explicitly building the backend), maybe there's a parallel reason that the destruction is wonky. I'm going to shelve this XCode project and try to get a fresh XCode project working with a copy of the same source code files. I really suspect XCode is playing some weird tricks here. Now if only creating a fresh project wasn't giving me headaches as well...
(By the way, I hope that I don't sound like I'm grouching at *you*, because I'm not, at all... TGUI's great! Computing in general is so fraught with gotchas for a guy that has limited free time...)

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?

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!

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?

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

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!

Working! Looking forward to exploring my C++ programming with your GUI...

Okay, I'll look into those options... thanks for your help!

Alas, I don't know how to tell my IDE to link to frameworks as opposed to dylibs. I tried pasting the framework filenames into the Linker Settings->Libraries: field, replacing the dylibs with them, but that didn't work.

I'm attaching a screenshot of the Cmake options that come preset. Can you possibly point to which ones I should modify that might correct this?
Sorry for the trouble! I'm no computer guru...

I built TGUI from source with Cmake, but I don't remember all of the options I selected or deselected. I think I was going for using the dylibs. After building the source, I just went in to the CodeLite project Settings->Linker->Libraries and typed in "libtgui-d.0.9.1.dylib" in addition to the SFML dylibs that were there.

I tried erasing the SFML dylibs from that Libraries line (thinking maybe it was already using the frameworks?), but got a linker error:

Code Select Expand


Undefined symbols for architecture x86_64:
"sf::RenderWindow::RenderWindow(...
more


When I left the dylibs in the Libraries field and tried to manually remove the SFML frameworks from MacintoshHD/Library/Frameworks directory, it compiled but launching the minimal program failed with this message in the terminal:

Code Select Expand


dyld: Library not loaded: @rpath/sfml-graphics.framework/Versions/2.5.1/sfml-graphics
  Referenced from: /usr/local/lib/libtgui-d.0.9.1.dylib
  Reason: image not found
Abort trap: 6

Thanks for replying...

I'm using CodeLite 12.0.3 on MacOS 10.14.2, with SFML 2.5.1 (I think correctly) installed.
I can start a new project and paste in the minimal TGUI code and it will compile and open a blank window. However, the terminal displays this notice when it runs:

Code Select Expand


objc[9998]: Class SFViewController is implemented in both /Library/Frameworks/./sfml-window.framework/Versions/2.5.1/sfml-window (0x10fbd30a8) and /usr/local/lib/libsfml-window.2.5.dylib (0x10d8120a8). One of the two will be used. Which one is undefined.

, along with the same notice for about 7 other Classes.

Then, if I try to add a Button to the GUI object, it compiles, but in the terminal I get:

Code Select Expand


sfml-graphics requires support for OpenGL 1.1 or greater
Ensure that hardware acceleration is enabled if available


Do I need extra software or settings in order to run TGUI without any hitches? Thanks!
I should mention, that I'm pretty new to C++, so all the config is still a little bewildering for me...

John Ziegler