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 ... 103
The bindRight behavior is not a bug, I tested it here and having it move through the child window means you are using it wrong. If the scrollbar is added to the gui instead of to the child window then it will follow the child window around (although not at exactly the wanted pixel).

bindRight = bindLeft + bindWidth
So if you move the child window around then the left position of the window changes and thus the scrollbar will also move. But the position of the scrollbar is relative to that of the child window (since you added it to the child window), so it will moves twice (once with the child window and once because you change its position with the bind function).

Also, Bindright seems to want to bind the left side of the scrollbar on the right side of the window, wich position it out the window

would'nt bindRight just want to stick right side of the widget on left side of the childwindow ?
The position of widgets is always the top left position, so even if you use bindRight, it will position the left side of the widget on that location. The bindRight function wasn't meant for overlapping widgets, it was meant for widgets that are placed next to each other. This is why you still have to subtract the width of your scrollbar from the position to get it to the right place. In TGUI 0.9-dev there is a setOrigin function now, so you would be able to call setOrigin(1, 0) and then you no longer have to subtract the width (because the position given to the widget would be the top-right position instead of top-left).

i think that's what you're talking about with bindInnerWidth
Not really. Imagine you have a panel of size (100x100) and it has a border of 10 pixels width. The contents of that panel is only (80x80). In order to have a widget of width 20px on the right side of the panel, you must place it on left position 60. If you were to use bindSize()-20 then you would actually be placing it on position 80 (=100-20). There should be a bindInnerSize() function that returns 80 so that you can do bindInnerSize()-20.
The example that I gave uses a layout with the string "100%". This is internally translated to widget->getInnerSize() and not widget->getSize(), which is why it worked. But there currently isn't a bind function to achieve the same thing, you currently have to create the layout using a string to get the wanted behavior.

ChildWindow behaves a bit differently in TGUI 0.8, it's inner size and size are the same thing, the borders and title bar are drawn outside of its size. Since this is inconsistent with the other widgets, this was changed in 0.9-dev where there is a difference between size and inner size now.

Btw, your email provider has been blocking more than just my forum email yesterday. Before I replied on facebook I had actually send you an email, but today I received it back as undelivered. As I said in that email (which I've quoted below), was blocking the messages based on ip address (at least that was what the error claimed). Messages sent using my mail client are however send using a completely different mail provider. So either it lies in its error message and just really dislikes the "" domain name, or they had temporarily blacklisted a lot of ip addresses.
It looks like is currently blocking ip addresses from (which is where my forum emails are send from).
Sendgrid has been retrying to send the message every few minutes but it always gets a 451 error back.

I've activated you on the forum manually, you should be able to login now.

Help requests / Re: how get a widget and use it ?
« on: Today at 18:05:31 »
Code like that exists, you just need to make the "f" a capital letter (moveToFront instead of moveTofront).

If you don't need to call any function specific to MenuBar then you can skip the cast to MenuBar and have code that works for any type of widget:
tgui::Widget::Ptr widget = gui->get("MenuBar");

The bindRight behavior sounds like a bug. Which widgets are parents to each other? Is the container inside the child window? Is the scrollbar added to the container, to the child window or to the gui?

The bindRight function was intended for sibling widgets that needed to be placed next to each other. Since it looks like you want the scrollbar on top of the container, maybe you should just add the scrollbar to the container and call
scrollbar->setPosition({"100% - width", 0})

With bind functions this would be equivalent to the following, but note that you can't use this code yet as I just realized there is no bindInnerWidth function (it's sometimes equivalent to bindWidth, but bindWidth won't work correctly if your container has borders and padding).
scrollbar->setPosition({bindInnerWidth(container) + bindWidth(scrollbar), 0})

If the scrollbar really has to be part of the container then you could consider using ScrollablePanel instead of creating a scrollbar manually.

Help requests / Re: SFML drawing into a child window
« on: Yesterday at 18:35:21 »
You would have to use the Canvas widget for this.

The canvas acts like a RenderTexture (it's actually just a wrapper around a RenderTexture), so you use the clear(), draw() and display() functions on it to draw your SFML stuff on the canvas.
Since the canvas is a tgui widget, you can add it to the child window and it will display the last thing you rendered to it.
You only need to update the canvas when the SFML rendering changes, so if what you render is static then you don't have to redraw to the canvas every frame.

Help requests / Re: ChatBox : Line Spacing and selection
« on: 24 May 2020, 19:27:32 »
If a RichLabel would exist then you would easily be able to build chat box functionality on top of that widget and you would have freedom as to how each line looks. When I created the ChatBox I knew that a RichLabel wasn't going to be added soon (it was too much work), so I ended up writing the ChatBox widget to provide a minimal support for such use cases. Years have passed since then and the situation hasn't really improved: ChatBox is still the only widget with multiple colored texts and RichLabel still isn't expected anywhere soon.

Although adapting the ChatBox to display the name and text in different colors would be easier than implementing a real RichLabel class (that can change its color arbitrarily in the text), it does have similar difficulties. Single lines of texts are easy to render, but to use 2 colors you need to draw each line using up to 3 text objects which have to be carefully positioned (one for the name, one for the remainder of the line and one for other rows if the text doesn't fit on a same row).
This kind of code already exists in TextBox of course (which draws the text in up to 5 parts when multiple lines are selected), but TextBox is one of the most complex classes for a reason.

Help requests / Re: ChatBox : Line Spacing and selection
« on: 24 May 2020, 17:19:19 »
1) No, the line spacing is taken from the font. The distance between 2 lines could be controlled by TGUI code, but the distance between two rows on the same line is controlled by SFML. So you will have to use a different font.

When the renderers are changed to no longer use SFML code then this would become possible, but even if this happens then it would still require a rewrite in some parts of the code, so there won't be a fix for this soon.

2) No, ChatBox is read-only. What you are asking for is essentially a RichTextBox, and that widget shouldn't be expected anywhere in the near future (unless someone would contribute it).

Bonus) To remove the background you can call the following:

Officially that currently isn't supported.
You could get it to work by faking a mouse event though:
label->connect("MouseEntered", [=]{ checkBox->mouseMoved(checkBox->getPosition()); });
label->connect("MouseLeft", [=]{ checkBox->mouseNoLongerOnWidget(); });

That should be easily solvable by adding something like this:
label->connect("clicked", [=]{ checkBox->setChecked(!checkBox->isChecked()); });

I'll add it to the todo list, but you could just replace the text with an actual Label widget for now.

Help requests / Re: Adding widget to group crashes
« on: 21 May 2020, 18:20:19 »
Are you certain that the .dll files next to your exe are from the same place as the .a files? I didn't realize that possibility until I was creating a test here.

There is actually one more thing that we could test. I've created a project using the same compiler as yours. Could you try downloading it:
(I've used 7z instead of a normal zip because it gave a big difference in size, download button should be at top right of page)

Try to run the TGUI-Test.exe inside the bin folder (either Debug or Release). If it complains about missing gcc and dlls then copy them from your "C:\Program Files (x86)\CodeBlocks\MinGW\bin" folder and put them next to the exe.
If the exe runs then try to open the .cbp project and building the project. Check if it still runs after you build the project.

Help requests / Re: Adding widget to group crashes
« on: 21 May 2020, 17:25:01 »
I don't know what it could still be. The code works fine for others but everything seems to be set up correctly on your pc.

The only thing that wasn't normal in the things you send (except for the fact that you are receiving a segmentation fault) was the result of the call stack. Could you double check that you are running in Debug mode when you get that call stack? It shouldn't contain question marks on the top.

The only other thing you could still try is rebuilding TGUI yourself with cmake, but I fear that it isn't going to make a difference.

Help requests / Re: Adding widget to group crashes
« on: 21 May 2020, 16:30:26 »
I'm starting to run out of ideas on what the issue could be.
- Could you send me your TGUI/include/TGUI/Config.hpp file?
- In CodeBlocks in the menu under Settings > Compiler... in the "Toolchain executables" tab (in the tabs near the top of the Compiler settings window), what is the "Compiler's installation directory" set to?
- If you open a command prompt, what is the output of executing "echo %PATH%"?

Help requests / Re: Adding widget to group crashes
« on: 20 May 2020, 18:37:11 »
Everything seems to be configured correctly in the cbp file.

Could you send me your libsfml-graphics.a and libtgui.a files?

In that case it might just some driver issue. Make sure your graphics driver is up to date.

The exception that you had in ProgressBar has nothing to do with this. That issue was already fixed.
You were also getting the GL_INVALID_OPERATION error, but there are two possibilities:
- Either it disappeared together with the exception which would mean that it is unrelated to this issue report (which is a possibility since the error could be caused by multiple things).
- Or it had nothing to do with the exception that you were getting and the GL_INVALID_OPERATION error was thus never fixed (I only fixed the exception issue).

You did make me realize one thing though: fonts also use textures. So I shouldn't just be looking at my texture management but also at the font management. Although I still don't see where it would try to copy something.

When you get back to your computer, the following are what I would need to know (you can e.g. add some output in the program so that you can see when the error happens):
- Does it occur before the main loop starts? If so, when? (E.g. when creating the gui, when creating the first widget or every time a widget is created)
- Does it go away if gui.draw() is removed?
- What if you do draw but no widgets were created? What if some were created but never added to the gui (no gui.add(widget))?
- Does it occur every frame? Only once per frame, or e.g. once per widget, or multiple times per widget?

Pages: [1] 2 3 ... 103