Messages

Okay, apparently during the many changes between versions as far as generating a picture pointer widget I changed many other widgets because of a misunderstanding where just setting a picture pointer equal to another one cause I was using the same image for many pictures caused them to move around funny. However for this particular panel I wasn't using the three images for anything. I store images in classes as picture pointers. By swapping to the copy function I was able to trigger the panel population function many times but not have the same issue since only the copies had functions attached or something. I assume.

Nvm, found the problem sort of. Even with removeAllWidgets active someone my initial populatePanel function was somehow leaving widgets up or something? Problem seems to have been solved by, unlike with other such functions, preventing this particular panel from populating more than once.

I am having an issue where sometimes if a function returns too fast, I assume, I get multiple events from a single click. There is also the hold down popping multiple events as well. Essentially a large function is only triggered once while relatively short functions go off several times. Is there a way to make sure a single click triggers only a single activation of a function connected to the GUI object?

What I could do is store the last mouse position and only handle the event when the position changed. I think that should fix the problem. Could you check if the mouse position remains the same during these phantom movements?

It will make my code a bit more complex since I will also have to keep track of what the handleEvent function returned during the last mouse event, but it could be an optimization if the mouse generates a lot of mouse events.

Not sure how to check that really? If you haven't had similar problems it might be specific to something in my hardware. I'm just planning to leave the delay set to 0, seems like a lot less work and I don't really need a delay for my project.

The timers are updated when drawing the gui. I can't see any case where they would blink. You shouldn't be able to blink faster than timeToDisplay anyway (and that is when moving the mouse which you aren't doing).
So maybe you can try setting the timeToDisplay to a different value (e.g. 2 seconds) and see if it affects the blinking.

Maybe you can also add the following right in front of the handleEvent call to check that you aren't getting events without knowing it:

Code (cpp) Select Expand

std::cout << ((event.type == sf::Event::MouseMoved) || (event.type == sf::Event::MouseButtonPressed)
|| (event.type == sf::Event::MouseButtonReleased) || (event.type == sf::Event::MouseWheelMoved)) << std::endl;

It appears that I am indeed getting events without knowing it although they don't seem to affect anything but the toolTips. When I move the mouse the number of events spikes. Otherwise it appears to be a slow tick, actually about the length of time for the blinking. Further fiddling tells me its detecting phantom mouse movements. I took my hand off the mouse but it made no difference.

As soon as you move the mouse the tooltip will vanish (no matter if you stay on the same widget or not).
The tool tip will only be added after timeToDisplay has passed without a single mouse event (on every mouse event the timer is reset).

That's an interesting choice. In any case I tried again and made sure I wasn't moving the mouse or performing any action and its still blinking.

Is it possible if I'm redrawing the gui which seems instant but the tooltip is slow cause of the timeToDisplay?

I resolved the issue in the sense that there's no more blinking, by setting tTD to 0. I still don't know why it blinks or how to fix it.

I can't think of a reason why that would happen without mouse events.

Once visible, it should only be removed again when the handleEvent function is called where this case is true:

Code (cpp) Select Expand

if ((event.type == sf::Event::MouseMoved) || (event.type == sf::Event::MouseButtonPressed)
|| (event.type == sf::Event::MouseButtonReleased) || (event.type == sf::Event::MouseWheelMoved))

Do you check if I'm on the same parent? Like, even if I move the mouse as long as I'm hovering over the same widget it shouldn't spawn the tool tip again. The timeToDisplay thing could cause an interaction that way, though unless I'm crazy I'm not moving anyways.

For some reason tooltips become briefly visible and then blink out and back on repeatedly. Is there a possible reason you can think of easily that this would happen? I'm not executing any code as far as I can tell, and I'm not even moving the mouse.

After a slight issue where I had to find and replace tool tips with the make_shared thing due to a crazy error that stacked traced the initial error to a place that made no god damn sense that I used std::cout to find the real source of I am now in business.

As far as I know TGUI and SFML are now properly integrated in the latest proper version barring 0.8 dev.

Now I just have to resolve the SFML vram issue that caused me to try and upgrade in the first place. FML.

The make_shared function shouldn't crash, it just creates an object. It would mean that the following code would crash as well:

Code (cpp) Select Expand

tgui::Panel panel;

TGUI 0.7-dev stopped using the create function over a year ago already (while 0.7.0 was only released april this year) so you are updating from a rather old version. I actually reintroduced these create functions in 0.8-dev after I realized they were nicer to work with, but if you would start using that version then you would have similar kind of issues next year.

Is the example code itself crashing? If not, could you provide a minimal code example that does crash?

tgui::Panel panel does appear to crash, though Tab worked apparently. I think the issues may all be from using the pre-compiled stuff. I may just have to build SFML/TGUI myself to avoid these issues.

So due to some issues with SFML 2.2 I went ahead and kicked up to TGUI 7.1 and SFML 2.4. Boy was updating from ::create to make_shared annoying. Also had to change all the tool tip crap.

Now I have a lot of problems with creating new objects.

Code Select Expand

mainMenuPanel = std::make_shared<tgui::Panel>();

That line which apparently is required to replace the old ::create function in 7.0 causes a segfault in this code:

Code Select Expand

/**
   *  @brief  Create an object that is owned by a shared_ptr.
   *  @param  __args  Arguments for the @a _Tp object's constructor.
   *  @return A shared_ptr that owns the newly created object.
   *  @throw  std::bad_alloc, or an exception thrown from the
   *          constructor of @a _Tp.
   */
  template<typename _Tp, typename... _Args>
    inline shared_ptr<_Tp>
    make_shared(_Args&&... __args)
    {
      typedef typename std::remove_const<_Tp>::type _Tp_nc;
      return std::allocate_shared<_Tp>(std::allocator<_Tp_nc>(),
       std::forward<_Args>(__args)...);
    }


I copied it exactly from the example code, which is where I figured out that ::create wasn't working in the first place. Do you have any idea why its doing that?

Also making a Tabs that way seemed to work.

I can only think of one reason why this would happen, are you reusing the same tgui::Picture::Ptr in multiple places? Because every widget can only have one parent i.e. you can't add the same picture to multiple panels. You need to copy it if you want to use it somewhere else:

Code (cpp) Select Expand

tgui::Picture::Ptr pic1 = std::make_shared<tgui::Picture>("Image.png");
tgui::Picture::Ptr pic2 = tgui::Picture::copy(pic1);

If that is not the issue then you should show a minimal code example.

This solved the problem. The confusion appears to have resulted from the way Ptr is used in TGUI vs a standard *. Thanks for assistance.

When I load a tgui::Picture::Ptr as part of a class from another such thing, when I try to display it in panels it only shows the very last object. Like it should show the Picture 10 times in 2 rows of 5, but it only shows the last column of the second row. Images that point to something else display properly.

Pictures (or any other widget) are now supported as tool tips in TGUI 0.7-dev.

Normal tool tip:

Code (cpp) Select Expand

tgui::Label::Ptr toolTip = theme->load("ToolTip");
toolTip->setText("Don't read this!");
button->setToolTip(toolTip);

Setting a picture as tool tip:

Code (cpp) Select Expand

tgui::Picture::Ptr pic = std::make_shared<tgui::Picture>("Image.png");
pic->setSize(100, 100);
button->setToolTip(pic);

Changing the time to display and the distance between the mouse and the tool tip can be changed through the static functions from the ToolTip class:

Code (cpp) Select Expand

tgui::ToolTip::setTimeToDisplay(sf::milliseconds(400));
tgui::ToolTip::setDistanceToMouse({10, 10});

cool, that was fast.

Making the tooltip something different than a Label has been requested before.
The problem is currently the design of such functionality, the tooltip should be allowed to be a panel but it should still be as simple as it is now so that you can just set a string without hassle.

If the tooltip can be a panel then recursive tooltips are immediately supported as well.

Maybe I can make two functions: setToolTipText which works like the current one and setToolTip which takes a widget as parameter, any widget whether it is a picture or a panel.

Edit: I have been thinking about a few different ways of implementing it but all of them make using a tooltip more complex. I also realized that the recursive tooltips won't work because the tooltip goes away when you move the mouse.

Well yes, in the current implementation that would happen. But you could probably do something like check if it hovers over any child widget. Alternatively I suppose I could just try to fiddle with panels myself somehow. Probably wouldn't use mouseover in that case.

How possible do you think it would be to spawn a tooltip that can have other images in it with their own tooltips? Basically recursive tooltips. A currently functional workaround may be having a function that spawns a panel or something on mouseover that stays up but it would probably be pretty complicated.

This feature is probably more relevant for games than other kinds of applications. The Glest Advanced Engine GUI could show picture widgets in tooltips and do some other stuff but I don't think those widgets could spawn their own tooltips.

You have to set the tab size before adding anything. The resize function should ideally work any time you call it, both for obviousness since other functions work fine and in case you want to change the size. The same thing goes for the text size. It doesn't propagate to the labels or w/e they are stored as.

The TextBox is indeed way too slow in tgui 0.6.
Rewriting the class was one of the first things I did in tgui 0.7-dev, the performance problems should be solved there.

I once wrote this on my blog, to give you an idea how much better it is now:

I am almost done with rewriting TextBox, so it is time to do some performance tests. The new code is 1000 lines shorter (1600 instead of 2600), supports word wrap and fixes all performance problems.

With 100.000 characters, there was still no visible delay when inserting text (but the fps dropped to 30 while typing). Going over 250.000 characters started showing visible performance issues.

So in normal situations (a few hundreds or even thousands of characters) you should have absolutely no performance problems.

Just as a comparison: the old TextBox didn't handle more than 500 characters very well.

I just want to say that the new textbox is working like magic. Thank you so much. I hate having to spend my day off redoing callback stuff but in the end the superior textbox performance is worth it. The v0.6 textbox performance was a showstopper.

Okay, its working now.

my tabs seem to have the wrong text size

The tab class has gone through several internal changes in the last year. If you can't figure out the problem yourself then you should try to provide some minimal code that has this problem.

Not important. The real issue I have is the signals thing. I wrote:
countryPicture->connect("pressed", mapManager->setPlayerNation());

However the function wants either an int or a Nation*. I tried:
countryPicture->connect("pressed", mapManager->setPlayerNation(), mapManager->getNation(i)));

But the function always says it needs an argument. I also tried a few things google popped up but didn't help much. If you put the argument in the braces it says invalid use of void function.

Since 'widget' is an uninitialized pointer before the static create function creates one, you are indeed calling a function on a nullptr. This is undefined behavior and normally leads to an immediate crash. But it seems that since the create function doesn't access any member variables it doesn't access this nullptr so it silently works (but it crashes later on in this case since it doesn't initializes the widget, it just returns a newly created one).

Well, I was just used to the old system with constructors. In any case everything works fine now except I misplaced a couple widgets and I have to redo stuff for the new callback system. Well and my tabs seem to have the wrong text size. Other widgets have proper sizes.

Yeah, I made a typo. It shouldn't print "e", but "e.what()".
Perhaps change "tgui::Exception" into "std::exception" to catch any exception since I don't think the add function throws any tgui exceptions.

Edit: Are you sure you aren't passing a nullptr to gui.add?

Apparently, I was using widget->create() instead of widget = tgui::WidgetType::create(); The second option allows the program to progress while the first causes the problem of the program terminating.

Also neither tgui::Exception nor std::exception caught anything from the function. Presumably cause it was a null pointer.

No, but you should just try to debug it and see on which line it returns exactly.

Edit: Possibly because tgui couldn't find something. TGUI v0.7-dev uses exceptions for error handling, you should try putting a try-catch block around your code in main like this. Normally you see the contents of the exception in your terminal when you don't put any try-catch, but perhaps it isn't printing it on certain systems.

Code (cpp) Select Expand

int main()
{
    try {
        /* code */
    }
    catch (tgui::Exception& e) {
        std::cerr << "Exception caught: " << e << std::endl;
    }
}

It appears that the function causing the issue is the GUI's ::add(); function. I commented shit out until it worked, create() on a panel worked, but as soon as I uncommented ::add(); suddenly the program exits with 3.

The try catch you posted complain: cannot bind 'std::basic_ostream<char>' lvalue to 'std::basic_ostream<char>&&'.

My game is currently returning Inferior 1 (process 8688) exited with code 03; This is not something my program itself would return, it seems it must come from TGUi or SFML. Have you ever gotten any times when you returned 03?

is there an actual tutorial on the new callbacks?

Yep, all v0.7-dev tuturials can be found here (although there currently aren't many tutorials).
The tutorial for the callback system is split in three parts:
Introduction to signals
Unbound parameters in signals (limited compiler support)
connectEx function (alternative to unbound parameters)

The new loading system uses theme classes. So you first have to create a Theme object and then use that to load your widget. This allows widgets to be connected by the theme to easily make changes that appear on all widgets or even completely reload all the widgets with a different skin.

Code (cpp) Select Expand

tgui::Theme::Ptr theme = tgui::Theme::create("TGUI/widgets/Black.txt");
tgui::Button::Ptr button = theme->load("Button");
gui.add(button);

Well somewhat annoying that all those load functions I ctrl+r to create need to go back, but thank god I don't have to do them manually one by one. The theme part is probably barely noticeable for me. So the new loading system is basically a non issue. I guess I now have to learn how to use Signal based GUIs now. Probably the new callback stuff is the most painful part. I had my something like 400 lines of callbacks all set up Well that size is gonna double or triple, so if the new system requires less lines it might be a good thing in the end.