31
Help requests / Re: button->connect member functions
« on: 24 March 2019, 17:01:12 »
Can you show the declarations of generateRW, generateCA, instance and the other parameters you are passing?
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.
32
Help requests / Re: Grid
« on: 14 March 2019, 20:02:53 »
VerticalLayout spreads the entire height among all widgets inside it, in this case just the Grid. So the height of the VerticalLayout (100% of parent by default) will be passed to the Grid. So you can just limit the height of the vertical layout:
But if you are only putting 1 widget in VerticalLayout then you don't need it and you can just add the Grid directly to the container and call that setSize function on the grid widget.
verticalLayout_->setSize("100%", 150);
But if you are only putting 1 widget in VerticalLayout then you don't need it and you can just add the Grid directly to the container and call that setSize function on the grid widget.
33
Help requests / Re: Grid
« on: 14 March 2019, 19:35:02 »
All your images are wrong for that given code actually, including 5elm-5pr.jpg.
The VerticalLayout will tell the grid what it's size should be. When a Grid is given a size, it will rearrange the widgets to fill this space. This rearrangement was broken, which caused the weird results, but even with only one line there should be space between the widgets to fill the entire width.
6elm-5pr-without-verticallayout.jpg doesn't have any extra space between the widgets because it is auto-sizing (the size of the grid is determined by the widgets inside it, as the grid wasn't given a size).
In my opinion the result of your code should be similar to my attached screenshots. I didn't write the code that adds spaces between the widgets to fill the size though, so feel free to propose alternatives if you believe it should look different.
You can download the code with the fix in Grid on github.
The VerticalLayout will tell the grid what it's size should be. When a Grid is given a size, it will rearrange the widgets to fill this space. This rearrangement was broken, which caused the weird results, but even with only one line there should be space between the widgets to fill the entire width.
6elm-5pr-without-verticallayout.jpg doesn't have any extra space between the widgets because it is auto-sizing (the size of the grid is determined by the widgets inside it, as the grid wasn't given a size).
In my opinion the result of your code should be similar to my attached screenshots. I didn't write the code that adds spaces between the widgets to fill the size though, so feel free to propose alternatives if you believe it should look different.
You can download the code with the fix in Grid on github.
34
Feature requests / Re: Resizable Child Windows/Right-Click Menu
« on: 13 March 2019, 19:51:41 »
You should show the code you are using because it isn't the same as the example you quoted.
35
Help requests / Re: ComboBox and State pattern
« on: 13 March 2019, 19:44:50 »
Using multiple Gui objects is not recommended at all, but I didn't fully understand what you meant and I was thinking the issue had to do with how events were sent.
I don't think it was possible yet to select a different item by holding the mouse in ListBox (which ComboBox uses internally) when the code was originally written like this in ComboBox. So this issue only appeared after an "unrelated" change in ListBox.
I've looked at how combo boxes work on my linux and a windows pc and they indeed only changes the value when the mouse is released. So I have updated my code to do the same. You can find the new version on github.
I don't think it was possible yet to select a different item by holding the mouse in ListBox (which ComboBox uses internally) when the code was originally written like this in ComboBox. So this issue only appeared after an "unrelated" change in ListBox.
I've looked at how combo boxes work on my linux and a windows pc and they indeed only changes the value when the mouse is released. So I have updated my code to do the same. You can find the new version on github.
36
Help requests / Re: ComboBox and State pattern
« on: 12 March 2019, 18:57:58 »
Are you using a separate Gui instance for A and B states?
If so then you should instead use the same Gui for both states and just put each state in a separate Group widget. When changing state you just have to show one group and hide the other.
Otherwise you should provide some simple example code that I can test here to get a better idea of what you are doing.
If so then you should instead use the same Gui for both states and just put each state in a separate Group widget. When changing state you just have to show one group and hide the other.
Otherwise you should provide some simple example code that I can test here to get a better idea of what you are doing.
37
Help requests / Re: Set different text colors to ComboBox items
« on: 10 March 2019, 18:34:16 »
The top example in your image would be harder to implement as it requires being able to set a different color for each item.
The bottom example can be implemented by just adding a default text. When the port becomes unavailable you just have to deselect the item, remove it from the list and set the default text.
So if it is enough for you then I'll just add a DefaultText property to ComboBox and a DefaultTextColor property to ComboBoxRenderer.
Edit: the default text was added to ComboBox (in the version that can be downloaded on github)
The bottom example can be implemented by just adding a default text. When the port becomes unavailable you just have to deselect the item, remove it from the list and set the default text.
So if it is enough for you then I'll just add a DefaultText property to ComboBox and a DefaultTextColor property to ComboBoxRenderer.
Edit: the default text was added to ComboBox (in the version that can be downloaded on github)
38
Help requests / Re: Set different text colors to ComboBox items
« on: 10 March 2019, 11:54:38 »Quote
Is it possible to set a different color to specific items?This is currently not possible.
Quote
I want to add item with grey color, which will mean that the item is not available.Would you still want the user to be able to select the item? If not then it would be better not to include the item.
Quote
how can I hide selected item from items list?In order to hide items from a list, just clear the list and fill it again with the items you want to show.
Quote
is there any function like tgui::EditBox::setDefaultText?What should the function do exactly? Place some text in the ComboBox when none of its items are selected yet?
39
Help requests / Re: Set widget to unclickable
« on: 06 March 2019, 20:01:46 »
It seems like ignoreMouseEvents doesn't do anything at all for Label, the property was added in both Label and Picture but is only used in Picture. I'll fix this soon.
Although handleEvent should return false after I fix it (unless there is another widget behind the label), what you need is the setEnabled function.
ignoreMouseEvents was added to allow a mouse event to reach the widget behind the label or picture, but to make a widget (any widget) completely ignore events, you should disable it:
Although handleEvent should return false after I fix it (unless there is another widget behind the label), what you need is the setEnabled function.
ignoreMouseEvents was added to allow a mouse event to reach the widget behind the label or picture, but to make a widget (any widget) completely ignore events, you should disable it:
label->setEnabled(false);
40
Installation help / Re: TGUI installation on Xcode gives 25 errors
« on: 05 March 2019, 08:11:24 »
TGUI requires C++14.
The tutorial for macOS don't seem to mention it, but you have to enable it in your project. Somewhere in your project (I don't know where as I don't have macOS to check right now) you have to add the "-std=c++14" flag (I'm sure you will find some information online on how to add that compiler flag).
The tutorial for macOS don't seem to mention it, but you have to enable it in your project. Somewhere in your project (I don't know where as I don't have macOS to check right now) you have to add the "-std=c++14" flag (I'm sure you will find some information online on how to add that compiler flag).
41
General Discussion / Re: New signal system
« on: 03 March 2019, 20:24:11 »
No, because the valid string depends on the widget type while the connect function is part of the base class. A virtual function call is used to find the signal that matches the name, so it can't be done at compile time.
42
General Discussion / Re: New signal system
« on: 03 March 2019, 19:28:22 »
Using enums is practically the same as "child->connect(tgui::ChildWindow::Closed, []{})", but with tgui::ChildWindow::Closed being an integer instead of string.
The function signature would still have to be checked at runtime. It would be slightly faster than using a string (but the difference isn't enough for me to care about it).
The addClickListener code gives another possibility. Instead of child->onClose.connect([]{}), we could have something like child->addCloseListener([]{}). It however has the big disadvantage that for every add function there would also have to be a remove function (and possible even some variants other than add and remove).
The function signature would still have to be checked at runtime. It would be slightly faster than using a string (but the difference isn't enough for me to care about it).
The addClickListener code gives another possibility. Instead of child->onClose.connect([]{}), we could have something like child->addCloseListener([]{}). It however has the big disadvantage that for every add function there would also have to be a remove function (and possible even some variants other than add and remove).
43
Help requests / Re: "ReturnKeyPressed" Signal on textbox widget
« on: 03 March 2019, 14:01:54 »
I see very little advantages of this compared to just defining tgui::ChildWindow::Closed as a string.
String to enum conversion is very nice and can be interesting for other parts in TGUI, but if we already use a string then we don't really need it.
Inheritance of the enum is interesting as well, but I don't think it offers anything extra in this situation.
String to enum conversion is very nice and can be interesting for other parts in TGUI, but if we already use a string then we don't really need it.
Inheritance of the enum is interesting as well, but I don't think it offers anything extra in this situation.
44
Help requests / Re: "ReturnKeyPressed" Signal on textbox widget
« on: 03 March 2019, 13:41:36 »
Can you show an example of how it would look like for the user to connect a callback?
Wouldn't it be very similar to "childWindow->connect(tgui::ChildWindow::Closed, []{});"? At least as far as I can tell it has the same advantages and disadvantages as this method.
Wouldn't it be very similar to "childWindow->connect(tgui::ChildWindow::Closed, []{});"? At least as far as I can tell it has the same advantages and disadvantages as this method.
Quote
The only disadvantage is that strings in txt file should be case sensitive.I can live with that.
45
Help requests / Re: "ReturnKeyPressed" Signal on textbox widget
« on: 03 March 2019, 13:23:24 »
I'm starting a poll at https://forum.tgui.eu/general-discussion/new-signal-system/