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 - billarhos

Pages: [1] 2 3 ... 7
Help requests / Re: ChildWindow change position when title changes.
« on: 15 January 2019, 09:46:33 »
Check some "dot net" windows forms. When you create a form with a size, created form is always less than the requested size. We are talking about normal windows. So the title bar and borders are inside the calculated size of window.

I removed "setKeepInParent" function and replaced it with "setPositionLocked" and that works for me since my actual size of new window is always same size of parent window.

What happening when "setKeepInParent" is declared and the form size is bigger than parent size?

Talking for myself, there is no need to change something with title bar height and window size. If your main thinking was to add the title bar size to form size is still ok with me now that i am aware of it.


Help requests / Re: ChildWindow change position when title changes.
« on: 14 January 2019, 22:26:37 »
Borders and title bar should be inside the windows size. You should not add the title bar size and the borders size to window size. If i want a 800x600 window then 800x600 should be. May be you can consider title bar and borders as two additional widgets. Just a thought. Give me some time to get to sleep. I come back tomorrow. I 'll dig up what happening with microsoft windows style and we can talk about it.

Help requests / Re: ChildWindow change position when title changes.
« on: 14 January 2019, 21:21:35 »
 If window is 800 and child window is 802 pixels then border sizes should be removed from the actual child window size.

Help requests / ChildWindow change position when title changes.
« on: 14 January 2019, 17:57:42 »

When i change the title of a child window the windows moves a bit inside the main (windows) form. I change title text because i am using more than one language.
This happening when height of child window is smaller than main window (570). However if the child window has the same height with form (600px) the the title tongle between visible and invisible.

Using github version

Code: [Select]
mWindow.create(sf::VideoMode(800, 600), "Sfml + Tgui example", style, contextSettings);

tgui::ChildWindow::Ptr pWindow = tgui::ChildWindow::create();
pWindow->setSize(800, 570);
pWindow->setPosition(0, 0);

pButtonLoad = tgui::Button::create();
pButtonLoad->setSize(150, 50);
pButtonLoad->setPosition(800 / 2 + 50, 600 / 2 - 20);
pButtonLoad->connect("MousePressed", [=]()

Feature requests / Re: "opacity when widget is disabled
« on: 12 January 2019, 16:25:01 »
Yes may be is that. I found the issue with 8.2. Then i download from "github" (8.3) that obviously this issue was fixed.

Feature requests / Re: "opacity when widget is disabled
« on: 11 January 2019, 07:15:33 »

The OpacityDisabled property has been added to the version on github:

Thanks Texus. That was really quick.

Could you show some code for this? I can't reproduce it.

I made a tiny example but i can't reproduce either. I will investigate and i 'll come back.

Feature requests / "opacity when widget is disabled
« on: 10 January 2019, 12:23:25 »
Hi Texus. Happy new year.

Good news. I started using 0.8.2.  I finished one of my big projects. I done all the changes and now i am changing the little details in order all widgets looks like before.
Thank you for the great work you done.

I was thinking if a "opacity when widget is disabled" property in all widgets can be added. Right now, when i want for instance a check box to be disabled i set the manually the opacity to 0.3. So the user can easily understand that this widget can not be touched-changed. Ii should be great if we can have this out of the box!

Also, if i run "setOpacity" other than 1.0f before adding widget to gui manager the opacity does not apply. It works if i first add the widget and then apply new opacity. I tried this with "button".


Feature requests / Re: Checkbox future improvments
« on: 30 December 2018, 13:14:27 »
Didn't know or think both of them. Thank you Texus.

Feature requests / Checkbox future improvments
« on: 30 December 2018, 12:29:32 »
I am trying to set initial value to checkbox without sending to me back a signal event. This is happening on initializing. It is important for me this two callbacks not to be triggered
in initializing progress. Only to set the visible part of checkbox (On/Off).

Now it is ok because i am using some booleans to avoid this.

This can be prevented by adding a "SetState(bool onOff)" function without triggering any callbacks in it.

Code: [Select]
pCheckBox = GAME_MANAGER->getGuiTheme()->load("CheckBox");
pCheckBox->setPosition(GAME_MANAGER->layoutWidth(450), GAME_MANAGER->layoutHeight(280));
pCheckBox->setSize(GAME_MANAGER->layoutWidth(100), GAME_MANAGER->layoutHeight(50));

pCheckBox->connect("Checked", [=]()
//do something here but only when user check this

pCheckBox->connect("Unchecked", [=]()
//do something here but only when user uncheck this

if (MEMORY_MANAGER->readDataBool(MemoryMain::checkBoxStatus))

Also a general callback with the name "changed"  it would be a good idea.

thank you

Feature requests / Re: Clickable textbox
« on: 23 December 2018, 11:33:45 »
I'm not sure whether I should go for a simplified port of the windows ListView control (with only supporting the "report view" at first) or whether I should just create a MultiColumnListBox class though
Can not say. But the report view is the most wanted. Also keep in mind that dot net list box has a BeginUpdate() method, that prevents the control from drawing until the EndUpdate() method is called. In this way when you can add items in listview very rapidly.

Feature requests / Re: Clickable textbox
« on: 22 December 2018, 15:56:32 »
Ok then. I am happy that at the end everybody understood. In future, i 'll keep in mind to add screen-shots.

The best option for label's scrollbar, if it should be enable or disable is to add an 'enum' Scrollbar State = {enabled, disabled, auto} along with a 'setter' and a 'getter' functions but maybe that requires a lot of work. In this way you can catch all future requests.
By default, it should be disabled and if someone uses long text then he should enable scrollbar at the beginning.

While having this conversation i always hesitated to ask you to go for the multi-column list box. Is a 'must' widget. And after the 'treeview' widget you added, there are no more big work to be done. And i really need it because i wand to rewrite an olf dj-music program i made (dot net, 10 years ago)
And after that, i will have no excuse of using the latest version of 'tgui'.

Feature requests / Re: Clickable textbox
« on: 21 December 2018, 06:45:10 »
Great news. A plus for me to use the newer version. In fact, i am planning to go for it, as soon as the visual studio 2019 for community pop up. I am stuck with 2015 for so long...

The thing that made me want this click callback is that i wanted a full screen text-info-help widget. And the only way to close this info-screen is to click on it when you finish reading. Kiosk machines normally can have a few physical buttons but sometimes there are no buttons. The other devices you can see on those machines are note and coin acceptors, money hopper, pos printer, card reader, scanner and camera.

Click on scroll bars has nothing to do with what i want. The area on scroll bar is to scroll the text. In my case i want a click on label's clean area.
Or, we can have both callbacks, one for scrollbar and one for text area. But, i can not think where it can be useful in the case of scrollbar.

And yes the example with dialog you mention, is pretty much like my case.

Feature requests / Re: Clickable textbox
« on: 20 December 2018, 20:07:22 »
Yes, i agree with you, if you must go with "label" and "scrollbars" then go (for 0.8). In my case, i would never used "textbox" in first place if i had a "label" with "scrollbars". I never wanted to write something (aka textbox). Yes, forget everything about i said for the textbox.

But on the other hand the label must have a click event (has it?). In future, maybe me or someone else will face the same experience when he would try to catch a click on a label. In my mind, focus events does not "connect" with click events. And in the physical point of view, we have a touch/click event. The focus event is an after-effect. Yes, i understood that it happening before the actual click event. And on the other hand, in my mind, when i make visible a widget (or adding it, into the container) it tells me that gain instantly focus as long is the top most widget, but obviously not.

As i said, right now you don't have to do something. I have already implemented what i wanted.

I am sure that this kind of discussing make things better.

Feature requests / Re: Clickable textbox
« on: 20 December 2018, 17:25:56 »
I am working with touch monitors (like ELO ) since 2000.

I do not think that i can miss a press event. If i miss a press event then something is not working correct. After all, a press event is a pre-event than focus event, so i am a bit faster. LOL

Right now the help screen closes without any problem by touching/clicking on any point in "editbox".

There is no need to implement something in 0.7.5 right now. However in the 0.8, i think that adding some features in widgets, like disabling select text without disabling the whole "textbox" widget or adding some extra callbacks is a plus, in this 'almost' (lol) perfect library.

After you added the "treeview" widget, i have one more motivation to start using the newer version.

thank you Texus

Feature requests / Re: Clickable textbox
« on: 20 December 2018, 16:19:47 »
Done with sf::Events

Code: [Select]
if (event.type == sf::Event::MouseButtonPressed
For the record, touch screen in kiosks just behave as mouses. The default settings have mouse emulation, that normal is left click down and up. However you can change that
with right click down and up.

Pages: [1] 2 3 ... 7