Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - texus

Pages: [1] 2 3 ... 110
Help requests / Re: OnSizeChange() difference
« on: Yesterday at 22:20:35 »
Is there a way to get difference of new size - old size on size change?
No, you will just have to store the old size yourself.

I dont get where this parametar goes and how to do it
Callback functions can have optional parameters. The onSizeChange member is of type SignalVector2f, which allows your callback function to either have no arguments or take a tgui::Vector2f as parameter. So both of these lines are valid:
Code: (cpp) [Select]
w->onSizeChange([](){ std::cout << "size changed\n" << std::endl; });
w->onSizeChange([](tgui::Vector2f newSize){ std::cout << "size changed\n" << std::endl; });
More information about the signals can be found in the tutorial:

Help requests / Re: Drawing Shapes within gui
« on: 28 December 2021, 22:25:33 »
Can i draw sf::RectangleShape or any other shape within custom widget?
Sure. Just look at some widgets (e.g. EditBox::draw) as an example on how they draw things.

The line you need is this:
Code: (cpp) [Select]
target.drawFilledRect(states, size, color);
The position is based on the states (it starts at the widget position at the beginning of the draw() function and you can add to it with "states.transform.translate"). The size of the rectangle is specified as second parameter.

if i make custom widget that inherits from tgui::Panel i see that i cant override draw function
I'm not sure why you think you can't, because you can just override the draw function again.
Code: (cpp) [Select]
void draw(BackendRenderTarget& target, RenderStates states) const override;(Use BackendRenderTargetBase instead of BackendRenderTarget if using TGUI 0.9)

The implementation of your draw function will look like this:
Code: (cpp) [Select]
void YourCustomWiget::draw(BackendRenderTarget& target, RenderStates states) const
    // Draw the background of the panel and all widgets inside it
    Panel::draw(target, states);

    // Draw your own shapes here

Sorry for frequent questions but im relatively new :)
No problem, I don't mind.

Feature requests / Re: Animations
« on: 24 December 2021, 13:15:37 »
i cant figure out how to make gui handle updates for it.
You can't yet, the gui only handles the show and hide animations. That's why I need to add some new functions to the Widget class.
If you just update the animation yourself then you however don't need the new functions and can already use the animations without waiting until I add proper support for them.

I've been looking at the code that has to be changed and noticed that this is annoying to handle in a backwards compatible way, so the new functions may only be added to TGUI 0.10-dev and not to 0.9

Edit: I have added the moveWithAnimation and resizeWithAnimation functions to Widget in the 0.10 branch on github.
The following example code would move the widget from its current position to x=100, y=50 over a duration of 0.5 seconds:
Code: (cpp) [Select]
widget->moveWithAnimation({100, 50}, 500);

Feature requests / Re: Animations
« on: 23 December 2021, 08:34:19 »
I thought using texture for boxshadows, but now that you added rounded panels this cant be used (i think).
The method would still work if you can create an image with such rounded borders. I wonder if this can be done easily in GIMP by using a few careful selections and radial gradient fills (I don't have time to check right now).
Edit: I've attached a file that I think could work (you would have to create it yourself depending on how much rounding the corners have). You can show it with the following code:
Code: (cpp) [Select]
auto pic = tgui::Picture::create({"RoundBorders.png", {}, {9, 9, 2, 2}});
pic->setSize(100, 100); // Any size you want

The file was created in GIMP by creating a 20x20 image with transparent background, adding a radial gradient fill of a circle with a diameter of 20px and then selecting a circle of diameter 10px in the center of the image and deleting those pixels (i.e. making them transparent again). This results in an image that can be used around widgets with 5px rounded corners, and the shadow is 5px thick. You can change the image size (same as outer circle diameter) and the inner circle diameter to adapt for different rounded corners and shadow thickness.
The middle rect when loading the image is always {imageWidth/2 - 1, imageHeight/2 - 1, 2, 2} for this situation.

This is of course only one way of doing it, you can do it yourself with vertices and sfml (which have the advantage of not needing a different image for different shadow thicknesses and rounded corners) or with some other tool.

This is the first time i see braces for implicit conversation tbh.
My explanation about what the line does is technically wrong, the brackets aren't doing an implicit conversion.
The function expects a Layout2d object which can be implicitly converted from tgui::Vector2f. The tgui::Vector2f class can be implicitly converted from an sf::Vector2f. Since c++ doesn't do 2 implicit conversions in a row, it won't accept the function call if you pass an sf::Vector2f. The line I gave is in reality equivalent to "widget->setPosition(Layout2d(pos))" which would then use an implicit conversion from sf::Vector2f to tgui::Vector2f to pass to the Layout2d constructor.
The "widget->setPosition(tgui::Vector2f(pos))" call on the other hand would do an explicit conversion of the Vector2f types, but then do an implicit conversion to Layout2d. The end result is the same, but this is technically not what happens when writing "setPosition({pos})".

Feature requests / Re: Animations
« on: 22 December 2021, 22:52:12 »
Is it possible to add animations on setSize() and setPosition()?
You could look at MoveAnimation::update in TGUI/src/Animation.cpp to see the few lines that are needed to implement it. Now that I looked at the code myself, I realize that it looks like it already does exactly what you need though. I though that it would be more limited, but it accepts any start position or size, the only limitation is the functions in the Widget class itself. So maybe I'll have a look soon if I can add some additional functions to Widget to create a move and resize animation.

That looks difficult to do properly, I'm not even sure where to start with that (even if I had the time for it). Maybe you can emulate it by placing a Picture (which would contain an image of the shadow) behind the widget? If a "middle" rectangle is provided when loading the texture then 9-slice scaling is used so that you can give the picture any size without stretching the shadow. So as long as all shadows have the same width (e.g. 10px at each side of the widget) then you can do this with a single image.
Something like the following (code was not tested).
Code: (cpp) [Select]
// shadow.png is 25x25 image with center 5x5 pixels as fully transparent and the pixels around it are the semi-transparent borders of width 10px
auto shadow = tgui::Picture::create(Texture{"shadow.png", {0, 0, 0, 0}, {10, 10, 5, 5});
shadow->setPosition({otherWidgetPos.x - 10, otherWidgetPos.y - 10});
shadow->setSize({otherWidgetSize.x + 20, otherWidgetSize.y + 20});

Can you add sf::Vector2f support for setSize() setPosition() as well?
They have an overload that takes a tgui::Vector2f type. Although I suggest you change your sf::Vector2f into a tgui::Vector2f in cases where you are only dealing with TGUI, there is actually an implicit conversion between the sf and tgui classes. The conversion doesn't happen automatically here because a Layout object is required, but all you have to do is put braces around your sf::Vector2f:
Code: (cpp) [Select]
sf::Vector2f pos;
widget->setPosition({pos});  // equivalent to widget->setPosition(tgui::Vector2f(pos));

Feature requests / Re: Rounded borders for containers
« on: 15 November 2021, 22:44:21 »
The setRoundedBorderRadius function has been added to PanelRenderer in TGUI 0.9 and 0.10-dev.

I did notice one other limitation though. Since TGUI can only clip rectangles, widgets inside the panel can still be drawn outside the rounded corners (if you place a widget there).

The 0.10-dev downloads on the download page have been updated. If you don't use Visual Studio or want TGUI 0.9 then you will have to build TGUI yourself (with the source code from github).

Feature requests / Re: Rounded borders for containers
« on: 15 November 2021, 19:09:12 »
It's not in TGUI yet, but it indeed shouldn't be hard to add.

I didn't want to add rounded borders to all widgets because with the current design it would be a lot of copy-pasting work and requires changing each individual widget. The idea was to first redesign the widgets so that they are rendered with reusable components. Adding rounded borders then would immediately make it available for all widgets. But the redesign had some issues and was delayed.
Because all previous requests about rounded borders were about the button widget, I decided to add setRoundedBorderRadius to the button renderer to at least allow using it for the most common use case.

Do you only need it for the Panel widget?
Does it matter that the mouse events still treat the widget as a rectangle for now? (Because ignoring the mouse events when on the corners seems to be only implemented when using textures, even for the button widget)
Then I can quickly add that to TGUI.

Help requests / Re: Replacement for tgui::Canvas in SDL backend
« on: 07 November 2021, 14:28:51 »
For anyone that sees this in the future: the situation is now completely different.

SDL 2.0.17 has added a SDL_RenderGeometry function which makes it possible to use the SDL_Renderer for all rendering instead of requiring OpenGL directly.

TGUI 0.10-dev now also has an SDL_RENDERER backend which makes use of this functionality. A CanvasSDL class has just been added to this backend to which you could draw SDL_Texture objects:
Code: (cpp) [Select]
SDL_Texture* imgTexture;  // The image to render to the canvas

auto canvas = tgui::CanvasSDL::create({400, 300});

SDL_SetRenderTarget(renderer, canvas->getTextureTarget());  // Let drawing happen on the canvas instead of the window
SDL_RenderClear(renderer);                                  // Clear the contents of the canvas
SDL_RenderCopy(renderer, imgTexture, NULL, NULL);           // Draw an image to the canvas
SDL_SetRenderTarget(renderer, nullptr);                     // Let further drawing happen on the window again

setSize is implemented in Button while isMouseDown is implemented in the Widget base class. If the first one crashes while the other does not then it may imply that the object is a Widget but not really a Button.
Since your code works here, I'm starting to wonder if there might be some library incompatibility that causes the Button class in your code to be different from the Button class in TGUI code.

Did you compile SFML and TGUI yourself or did you download precompiled versions from the websites? Which visual studio compiler are you using exactly? Are you certain you aren't linking to Debug libraries while in Release mode, or vice versa?
I noticed you mentioning debug mode but also mentioning tgui.dll, which is the release dll. Make sure to use the library with "-d" postfix in debug mode (for both SFML and TGUI).

What is the contents of startMenu.txt? Are you certain it contains a button with the name "loadFromFile" or "a"?
The access violation happens on a nullptr, which is what the get() function returns when no widget exists with that name.

Help requests / Re: ChildWindow close
« on: 01 October 2021, 12:46:17 »
The behavior in TGUI 0.8 was too surprising for a lot of people so it was changed to a new system.

When the close button is pressed, onClosing event is triggered which has a boolean as parameter that you can set to true to prevent the window from being closed.
If there are no signals connected to onClosing or none of them set the abort parameter then the onClose event is triggered. After this event the window will be "destroyed" (i.e. removed from the parent with parentGroup->remove(childWindow)).

Instead of toggling the visibility you could just call group->add(childWindow) again when you need to show the window again.

Alternatively, you can prevent the window from being closed in the onClosing event and change the visibility there:
Code: [Select]
childWindow->onClosing([=](bool* abort){
    *abort = true;

Help requests / Re: Group events
« on: 24 September 2021, 12:24:16 »
That function was never intended to be used directly in previous versions of tgui.
If your group is part of the gui then gui.handleEvent should pass the event to the correct group.
In what scenario do you think you need to pass the event to the group directly?

Help requests / Re: ListView removeItem error
« on: 02 September 2021, 22:26:01 »
removeItem apparently shouldn't throw out_of_range even when a wrong index is provided, but I did notice something else in the code that could go wrong.

removeItem() will remove the selected item and thus cause the selection to change. The onItemSelect is triggered halfway through the removeItem() call, so your updateGui is called while removing the item. I'm guessing the updateGui function probably does something with the list view which causes the error.

Help requests / Re: ListView removeItem error
« on: 02 September 2021, 18:17:25 »
What is the value of listView->getSelectedItemIndex() inside the onMousePress function? Is there any chance that it is -1 when it throws (which is the case when no item is selected)?

Help requests / Re: What do i need to know to use TGUI ?
« on: 09 August 2021, 16:43:43 »
Understanding std::function and lambdas is useful for the signals in TGUI (since examples often use lambdas to keep the code shorter).
Understanding smart pointers (e.g. shared_ptr) is useful to work with TGUI widgets (since Widget::Ptr is just an alias for std::shared_ptr<Widget>).
Other than that, a basic understanding of c++ is required, but you might be able to learn it as you go.

The tutorials ( and example codes ( provide some useful information.

menu->connectMenuItem("File","Exit",[&]{ window.close(); }); should work fine. Do you have a case where it doesn't work?

Pages: [1] 2 3 ... 110