Messages

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.

https://docs.microsoft.com/en-us/dotnet/api/system.windows.forms.listview.beginupdate?view=netframework-4.7.2

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'.

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.

Yes, i agree with you, if you must go with "label" and "scrollbars" then go (for 0.. 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.

I am working with touch monitors (like ELO https://www.elotouch.com/ ) 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

Done with sf::Events

Code Select Expand

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.

1. I forced to use textbox exactly because it has scrollbars. Sometimes text is more than a page.
2. Imagine you have a textbox filling the whole area. When this textbox appears it is easier for the user, and even more easier when this app running in kiosk machines
with touchscreen monitors, to touch (left click simulation) somewhere inside this textbox when he/she wants to close this form with the textbox.
The text usually contains help info.

Basically, the first one it is not such a problem.

I managed partially do that overriding "global mouse enter" but then it is completely useless in normal pc machines.

Hi.
Using a textbox widget to display some info text, i came in front of two obstacles.

1.Even using "setReadOnly" function, in "editbox" you can still select some words or lines.
2.I was unable to find a way to catch a mouse left click on "editbox", in order to close my help form.

I am using 0.7.5 version.

thanks for reading

Ok Texus thats great.
Talking about performance, have u made any performance test between 0.7 and 0.8 versions?

Ok,  i downloaded 0.8 and saw that buttons now using text. Just to clarify, lines in labels in 0.8 version keep center align accordingly to each line chars?

For example is it like this?
       Line 1
     My line 2
Ok this is line 3

There are a lot of cases when translating a text from one language to another, texts can be much bigger. Setting auto the size can do the trick but the text can be
not-readable. In my case this is happening in button text very often.

Hi Texus.

The center alignment when more than one lines exist, in my case in "buttons" but i can think that the same happening in "labels" also since "buttons" uses "labels", has not
correct align. All lines keep the first line start position. But each line has different count of chars.

It would be great if this would be implement at least in the new version of tgui. This, it would give me an extra motivation to start using 0.8 version sooner

cheers

Yes, it was my mistake, sorry again.

I should use "WS_EX_OVERLAPPEDWINDOW" style, since i was dealing with 'exstyles' and not "WS_OVERLAPPEDWINDOW".

This little silly mistake produce wrong mouse events.

Cheers

Sorry, texus it is not a tgui poblem. I am getting wrong mouse cordinates when changing the view. It is a sfml issue. Invastigating.

Sorry again.

I test the hitting by additing two breakpoint inside the "connect" signal functions of the two buttons. When i hit the 'back' button the program stops on the breakpoint into the
'ok' button and vice versa. Also, there are colors the down state in buttons .

Hi,
i found a strange bug. Really can not say if this is sfml or tgui problem but is is happening on button widjets when changing size and view on sfml form
along with changing the alpha color of form.

here is the repro project
http://www.mediafire.com/file/d2nadgdqb9wstw9/Tgui.rar

Code Select Expand


sf::Uint8 alpha = 80;
HWND hwnd = mWindow.getSystemHandle();
SetWindowLongPtr(hwnd, GWL_EXSTYLE, (GetWindowLongPtr(hwnd, GWL_EXSTYLE) | WS_OVERLAPPEDWINDOW) | WS_EX_LAYERED);
SetLayeredWindowAttributes(hwnd, 0, alpha, LWA_ALPHA);


if i use the above lines then when i hit the left button the signal goes to the right button and vice versa. Strange, isn't it?
Hope Texus u come with any idea.

thanks