11-04-2019 12:45 PM
If I am missing something, not googling correctly, please let me know, as I cannot find, and don't think there is a solution, unless there is some special secret INI key I do not know about.
Background:
I am using a multicolumn listbox whose first three columns contain symbols for various "DAQ" actions. In the picture below, there is a record, stop, and edit task symbol.
Unfortunately you cannot "merge" column headers for a multicolumn listbox. The "Actions" label is a free floating decoration that sits on the listbox.
Here's the problem:
There is a horizontal scroll bar at the bottom of the listbox, when the user scrolls I want to move my decoration label like it is part of the listbox column headers.
Problems:
Any suggestions or workarounds?
Thanks.
Cheers,
mcduff
11-04-2019 01:25 PM
@mcduff wrote:
...
Any suggestions or workarounds?
Thanks.
Cheers,
mcduff
Invoke node >>> Point to row Column
?
Ben
11-04-2019 01:31 PM
11-04-2019 01:45 PM
Property >>> Top left visible cell
?
Ben
11-04-2019 01:59 PM
@Ben wrote:
Property >>> Top left visible cell
?
Ben
Yes, you could use that in combination with the Active Cell Property. Get Top left visible, set it to active cell, and get its left position. However, it is easier to "pick" an known active cell as a reference, get its left position and adjust from there.
This works. However, ...,
the property is only updated on a mouse down or mouse up event.
So assume, I mouse down on the scroll bar, I get an Event update, I do not let go of the mouse down while scrolling. I get no updates until a mouse up event. So while the user is holding down the mouse and moving the scroll bar, I cannot adjust the decoration position on the "fly". It can only happen at the beginning and ending of the event. This is why in my initial post I mentioned this solution as clunky.
Right now I am leaning towards making a custom scroll bar that moves column to column. Then I can monitor the value change event continuously. What I don't like is I will have to modify my tree control to have the same behavior as the listbox as I want "consistency" for the UI.
Thanks
mcduff
11-04-2019 02:27 PM
I don't know how it is possible to have symbols in multiple columns, I think it's just one per row.
Can you send your VI to help me understand a bit?
Cheers,
Jimmy
11-04-2019 03:33 PM
@JICR wrote:
I don't know how it is possible to have symbols in multiple columns, I think it's just one per row.
Can you send your VI to help me understand a bit?
Cheers,
Jimmy
It is possible but unsupported(?).
Look at this thread on LAVAG.org. Basically all you need to do is add an INI key to your LabVIEW INI file. Sorry for being vague, not sure about the rules for posting here, like telling people to use unsupported features, etc. Anyway you can get all the information your need on that thread.
mcduff
11-04-2019 05:33 PM
I am going to leave this post open in case a better solution comes up, but I made my own horizontal scroll bar and now move the listbox column-by-column.
But let me gripe a bit, the solution is odd.
I have a tree control right above my listbox control. (See photo) For the tree I have both scroll bars on, vertical and horizontal. For my listbox if I turn off its horizontal scroll bar the vertical one extends and that little square with the arrow pointing to it is gone. So to have my controls look similar, I need to keep the horizontal control for the listbox on, and place my own control over it, so I still have a square there. Hopefully it doesn't lead to any interesting race conditions between scroll bars. 🙂
mcduff
There are two horizontal scrollbars in the listbox, on top of each other.
mcduff
PS I don't want to make a square decoration and move it. I did briefly consider it.
11-05-2019 09:42 AM - edited 11-05-2019 09:49 AM
Oh man I remember this, and it was a pain. And even with the source open I'm having a hard time explaining what I did to make it work.
So I had a similar situation. I wanted glyphs in each column of a tree, but I also wanted the glyphs to be larger and some to toggle when a user clicked them, and another column that would slide over other options. Depending on what elements of the tree are shown (opened and collapsed as well as vertical scroll) would mean some would be shown and not. I also later added another 2D picture control which would essentially show goto operations and that would be shown with arrows that would need to be redrawn if some items were shown and not. The best solution I came up with was to have a 2D picture control over top of the column, and then draw the pictures at the right locations, to make it look like it was in a column. I'd capture the mouse down and see what part of the 2D picture was clicked then change the glyph that way. The code got more complicated when someone might scroll down, (now glyphs need to move), and scroll over (now the 2D control needed to move, or be hidden). I also had other UX interactions which complicated this.
The key I found was using the Active Column Number, which would show the column width and Active Cell Position Left. Using this along with the control position I can know if a whole column was being shown, or partially shown, and where it was, relative to the whole control. Attached is a quick video which I admit doesn't look the greatest when the window is being resized, I could probably do something more elegant like hide the pictures while resizing, then show after resize is complete, or continually reposition things as you are resizing, but at the moment it gets fixed on a mouse over.
Edit: I added the code to update while resizing, and it helped but still isn't great since your mouse can move faster than the VI server calls to move objects around. Hiding things would probably be best but users of my software don't really resize often, they usually just leave this window maximized. I was only resizing it in my video to demonstrate scrolling right.
Unofficial Forum Rules and Guidelines
Get going with G! - LabVIEW Wiki.
16 Part Blog on Automotive CAN bus. - Hooovahh - LabVIEW Overlord
11-05-2019 10:11 AM
I am sure you already know, but if you limit the number of event generated on a resize event, it can make it a bit smoother.
(I only mention it because I recently discovered this option... and it might help others.)