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.