Messages

There is at least one big breaking change still coming in v0.7-dev, the whole loading system is being rewritten. So if you wait on that you only have to change your code once instead of twice. But it is hard to foresee how long it will take before the change is finished (currently expected to be finished before the end of this month).

If I change widgets then the changes are usually pretty small, so the operations you do on the widgets probably won't have to change much. The way you create the widget and add it to the gui however is something that is very different in 0.7 (and will be different once more after the new loading system is done), so this requires changing every widget. Also the entire callback system is different in v0.7-dev as well (so all bindCallback lines have to be changed and callbacks can't be polled anymore).

I only have short-term plans (the changes I want to make up till v0.7-alpha), so I don't even know myself which changes will be made between alpha and final release. So technically many more breaking changes might be made before reaching beta phase (it is only after this point that I start actively recommending tgui 0.7 over 0.6). Although I doubt there will be many really big changes after this new loading system is done.

So changing to v0.7-dev might take some effort, you should decide for yourself if the new features in 0.7-dev are worth the effort. A better textbox and a tooltip class are just a few of the many small improvements.

I can't afford to mess with the tiny capacity textboxes in v0.6. They are soul crushingly painful to handle and I'm barely putting 1/10 of the expected characters in them as it is.

One thing I would like to know though is, is there an actual tutorial on the new callbacks? The documentation doesn't seem to have it. All the rest of the errors I got after switching appear to be relatively easy to fix, mostly ctrl+r stuff after searching my files with TextCrawler.

Also, do you know what kind of change the loading system will have compared to the current 0.7?

So I guess the real question then is how much of a hassle it will be to switch to 0.7. I don't foresee cracking 100k characters so hopefully the issue will be resolved permanently. Then I'll just have to wait for Tooltips.

I am having an issue where textboxes displaying any more than a trivial amount of information are taking a long time to load. They also take a longer time to move the scroll bar, thus making it all jittery and basically useless. Can you think of why this might be? I've used a custom wxwidgets GUI that had tool tips and text boxes loaded with vastly more text than the stuff causing my current issue, so it seems like something specific to TGUI or at least SFML.

Oh I saw that function but didn't know that determined the location of the scrollbar, too.

Is that in the documentation? I looked before I asked here.

In any case it works perfectly, thank you.

How can I set all scrollbars to be at the top? Current when I click on an object to change the content of a textbox the scrollbar is set all the way to the bottom, I'd prefer the opposite where it goes to the top.

Is that what you thought I should get before?

Yeah. I forgot that I was still using my own smart pointer in v0.6. That assertion is indeed what you get with v0.6.

I can't debug it from here, that's why I need to have more information somehow.
Just try using this code:

Code Select Expand

std::cout << gui.get("WrongName").get() << std::endl; // the last get() may or may not be needed to print the pointer

If that prints something that looks like a null pointer, then I can't do anything and it works as expected.
If that crashes, then could you upload your entire project including sfml and tgui libraries somewhere (e.g. dropbox) and send me the link? Then I may be able to test things myself here.

That was a different error that caused the console message, I tried to hide something before it was there and it wasn't the get function this time. That's working as expected I'd imagine.

I just got an error with nullptr for a different thing. Assertion failed: m_WidgetPtr != nullptr. Is that what you thought I should get before?

I get the call stack the rest of the time, just not on this particular crash. Basically its just what happens if the panel name given to the get function doesn't match the name a valid panel.

Your description is a bit vague. I don't see anything about the Tab class that should be crashing, so I assume you are talking about the get function from Gui in the tab example code?

The get function returns a pointer to the widget, or nullptr when the widget isn't found. If you try to call a function on a nullptr it will crash of course. The only thing I can do about that is throw an exception instead of returning a nullptr, but that might not always be wanted.

You should always be able to find a call stack somewhere when debugging. That usually gives enough information about where it happened. The last line might perhaps be in a tgui function with this=0x0 which can tell you that you called that function on a nullptr.

But if you weren't talking about the get function then you will have to be a bit more specific than "The function".

Yes the get function sorry. And no, this produces no callstack. The program exits with code 3. According to google this means an uncaught exception or "the system cannot find the path specified." Not sure how this would apply to your get function though.

So I set up some tabs based on the tab example code and its pretty much fine except one issue. When Tab causes the program to crash it doesn't say why, even when I was running debug mode. It turns out in the tab show/hide function I hadn't changed the name from Unused2 to Populations. But it took me some time and an epiphany to realize this, and this was after I knew that the problem existed although I didn't know it was messing me up right then. The function should ideally return some sort of couldn't find a panel with that name error or something, instead of just crashing right off.

Do we have this yet? It doesn't seem like we do. The only post I found with search was a year or so old and said you would probably add it later. Tooltips are essentially mandatory for games.

Cool. There were a couple ways to work around it but they were quite a hassle. Probably the simplest one was to reload the image separately to the widget, the next one being by including the widget code in the Building class.

I have a game class for buildings, that loads its own icon. Would it be possible to load an image to a Picture, that I'm using as a button for building buildings, from a pointer to an sf::Texture? Or should I just grab the name of the loaded image, shove it into a filepath and reload it?

Glad that you like it and got it working.

I do want to see if I can reproduce these opengl errors though. What is your compiler and sfml version?

SFML version should have been the one with tgui, at least for the openGL errors. Otherwise it may have been sfml 2.1. Compiler was gcc gnu 4.7.1 sljl unless I'm mistaken.

Unfortunately I am low on time due to work. I just ditched static compiling and it all appears to work. thanks for help though. Your library really puts SFML over the top of SDL for me.

I'm almost certain I followed all those this time. My current issue is the program won't build due to undefined references to various glFunctions like glIsEnabled and whatnot.

Program received signal SIGSEGV, Segmentation fault.
In sf::Shader::bind(sf::Shader const*) () ()