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 ... 99
Help requests / Re: BitmapButton change image at runtime
« on: 26 October 2019, 19:23:41 »
I use references in function headers to avoid copies, but in combination with a foreign library i fail.
To keep it simple you can assume that Widget::Ptr is a Widget* (so if you copy it then you are just copying the pointer and not the actual widget), but to fully understand how it works you would need to understand std::shared_ptr because Widget::Ptr is just an alias for std::shared_ptr<Widget>.

I know its wrong what i did. (Although i dont know why. I just read that its wrong to have global variables)
There are 2 reasons why global variables are bad. The first one is mostly relevant to larger projects while the second one is typically only relevant for classes.

The first reason is simply because it can make the code harder to understand. Global variables can be changed from anywhere in your code, so it would be harder to follow where the value is changed throughout the code. This is why having "const" variables in global scope isn't a problem, it is only a problem with regular variables that can be changed.

The second reason is because there is no guaranteed order of construction and destruction of global variables across source files. If you have a global variables A and B then they are constructed in the order they appear in your cpp file, but if they appear in different cpp files then A could be constructed either before or after B. This is only a problem if you try to e.g. initialize A with the value of B.
SFML relies on some global variables to work, so if you create an sf::RenderWindow in global scope then it is possible that it crashes because the globals that sf::RenderWindow relies on aren't initialized yet when the window is created. It is also possible to get lucky and have the SFML globals initialized before your window in which case everything works fine, but that is not something you will want to rely on (although you will always get the exact same outcome as long as you don't change your linker settings).

So having a few integers in global scope isn't really a big issue when quickly writing a small piece of code.

Help requests / Re: BitmapButton change image at runtime
« on: 26 October 2019, 18:33:25 »
Actually putting those variables in the header isn't a good solution (I'm not even sure why it would work).
When I told you to use "=", I wasn't really looking at your code. The EraserON and Hue values probably still need to be passed as references to the lambda, by using "=" instead of "&" you are making copies of them and you would be changing a local variable inside the lambda instead of the variable that you had outside. You might want to look up how lambdas work, but the "=" and "&" are just the defaults for the variables. To pass some variables by value and some by reference you would do something like
slider->connect("ValueChanged", [&,slider]() { Hue = slider->getValue(); }); // All variables passed by reference except slider
slider->connect("ValueChanged", [=,&Hue]() { Hue = slider->getValue(); }); // All variables passed by value except Hue

When you choose a tool then the button stays pressed.
When u choose another tool then this button stays pressed and the previous goes back to unpressed.
I dont know if BitmapButton is the right choice here.
You might want to use RadioButton widgets for this. The downside is that the RadioButton places its text next to the image, so if you need text on top of the button then you would have to add a Label in front of it manually on which you call isIgnoringMouseEvents() to make sure clicks on the label are passed to the button instead of absorbed by the label. I'm not sure if there are better options, but if you don't need any text then what you need definitely sounds like how radio buttons work.

Help requests / Re: BitmapButton change image at runtime
« on: 26 October 2019, 17:52:53 »
Is the issue resolved when changing the "&" to "=" in the BBTN_Erase->connect line?
You are currently storing a reference in that lambda. If the BBTN_Erase variable goes out of scope (so at the end of the function that contains the code you showed) then this reference will become invalid. This would cause a crash when trying to use the variable when the lambda function is being executed.
The Widget::Ptr is a pointer, so it can be passed by value without having to worry about performance with copying it.

Help requests / Re: BitmapButton change image at runtime
« on: 26 October 2019, 17:14:05 »
It is impossible for a program to know what variable name you used, the compiler just translates it to an address in memory, so you do need to pass the string yourself
gui.add(BBTN_Erase, "BBTN_Erase");

Help requests / Re: BitmapButton change image at runtime
« on: 26 October 2019, 14:59:19 »
Check if BBTN_Erase is a nullptr when calling BBTN_Erase->setImage. If it is then it means no widget was added to the gui with name "BTTN_Erase".
Are you passing that string as second argument to gui.add?

Feature requests / Re: Missing .pdb files
« on: 13 October 2019, 16:32:56 »
PDB files have been added in TGUI 0.8.6

Help requests / Re: Antialiasing problem with buttons
« on: 10 October 2019, 18:56:19 »
The gui builder shouldn't have different behavior.
However, the widget files created by the gui builder embed the theme in them, so they don't read the theme file when loading them. Maybe you had a changed theme file at the moment you generated the widgets file with the gui builder or at the moment you opened the gui builder? You can check this by seeing if the form file contains the "Smooth" or not, it doesn't contain it by default (since the properties are copied from the theme files which don't have it).

Help requests / Re: Antialiasing problem with buttons
« on: 10 October 2019, 18:01:40 »
Can you try adding "Smooth" behind the texture in the theme file?
So the lines in the Button section in BabyBlue.txt should look like this:
Texture = "BabyBlue.png" Part(269, 40, 90, 60) Middle(30, 0, 30, 60) Smooth;

I never really saw any difference between enabling smoothing on textures before so I just kept the default (which is false in sf::Texture).
Although I can't reproduce the way it looks for you, when zooming in on the button I can see a difference between non-smoothed and smoothed here, so this looks like it might solve your problem.

Help requests / Re: Close button
« on: 07 October 2019, 11:09:57 »
It gives the exception because you are missing a semi-colon behind "ShowTextOnTitleButtons = true".
The parser sees "true CloseButton=&Button" as the value of ShowTextOnTitleButtons, which it considers invalid since it contains an unquoted '=' sign.

Feature requests / Re: Multiple selection items for ListView.
« on: 05 October 2019, 22:17:33 »
So basically the question is what to do in setSelectedItems when setMultiSelect wasn't called yet (or when it was set to false again).

I wanted to look up how other libraries did it and I noticed that in .NET the selected items is a read-only property. Maybe we don't need to have a setSelectedItems at all?
If you do add the function then you can choose what it does, as long as the behavior is documented. When I said that the mode should not be changed automatically I wasn't thinking about a scenario like this, enabling multiselect when calling setSelectedItems with more than one item would be a valid solution. But unless someone has a need for the function maybe it would be better to just not have a setSelectedItems function.

Feature requests / Re: Multiple selection items for ListView.
« on: 05 October 2019, 19:55:55 »
1. For now we can just keep the deselectItem function. I'd have to review that in the future where I would probably rename it to "deselectItems" or just "deselect", but for now we can just keep the existing "deselectItem" function which will deselect all items.

2. I'm not sure what you mean. If multiselect is true, the user should be able to select multiple items (by having ctrl and/or shift pressed when clicking). If multiselect is false then the user can only select one item at a time and the ctrl and shift keys are ignored. The mode should never be changed automatically.

Feature requests / Re: Multiple selection items for ListView.
« on: 02 October 2019, 07:55:22 »
std::set seems like a better option, for the setSelectedItems/getSelectedItemIndices functions as well. Then you don't have to worry about sorting or having the same index twice.

Feature requests / Re: Multiple selection items for ListView.
« on: 01 October 2019, 22:29:33 »
It would be a nice addition, but you will have to implement this yourself too if you want it, I'm too busy playing video games right now :)

After briefly thinking about it, I guess for the API it should be enough to add the following 4 functions (with the MultiSelect boolean propery being false by default).
void setSelectedItems(const std::vector<std::size_t>& indices);
std::vector<std::size_t> getSelectedItemIndices() const;
void setMultiSelect(bool multiSelect);
bool getMultiSelect() const;

Help requests / Re: Using canvas
« on: 28 September 2019, 14:26:25 »
The "tgui-git" package downloads directly from github, so updating that package always gives the latest github version.

Help requests / Re: Using canvas
« on: 28 September 2019, 11:19:08 »
I didn't test to make sure that it actually works, but I have added a setView function (and getters) to the Canvas class in the latest version on github.

Pages: [1] 2 3 ... 99