LabVIEW
Slider Control With Defined Values
Solved!
I'm looking for a control that the user interacts with which is similar to a slider control, but has defined values to step between, and has two sliders.
I want to allow the user to select a start time and date, and stop time and date, from a finite set of values. My first plan was to use a horizontal slider, with two sliders. This is close to what I want and the user can visualize the range of data and pick what they want. But behind the scenes there really only is a finite set of options they can choose from which might not be evenly distributed. So if it were possible to set the static values that the user can choose from, and have the slider snap to those positions would be helpful. In addition to that I think allowing the user to use the increment and decrement on the Digital Display could also be useful for them.
Does anyone have any ideas on how to accomplish this? I've thought about picture controls, or a hidden slider on top of the slider which changes the values to the defined options. Or having the value change event triggered which forces a snap after the drag completes. It could also check for value change on the digital display and snap as well. No idea seems like a perfect fit. If this is too difficult I'll probably just resort to having two single column listboxes of options for the user to choose from but I thought this would be a more intuitive design. Attached is a start of the control which doesn't snap to the defined values. Any suggestions? Thanks.
Okay I know I didn't let anyone reply but I have a mostly working solution. The only thing I don't like about it is when you drag a slider, it snaps back and forth between a valid possible position, and the one you have your mouse on. I tried some defer front panels, and disabling the control, but that had other issues.
Thanks for the attempt, but I don't think this approach would work for me. The UI is likely going to be resizable, and setting the slider to fit to pane would be the easiest way to handle this, and your approach relies on evently spaced times, which I don't think I'll have, and a static UI size. But to be fair I didn't mention this in my earlier posts.
But the snapping effect that a integer slider gives is what I'm looking for. I even thought about setting the increment size to what ever the next notch should be. But this only works for the minimum and maximum values, because when you are in the middle a jump up to the next won't be the same amount of jump as it is down to the previous value. If the increment size could be set for incrementing up and incrementing down I could get away with this approach, setting the new increment size after each value change. Another approach that doesn't work is using the mouse pointer location to get what the value should be, then disable the control, but keep track of Mouse Down and Up and set the value manually. Unfortunatly there isn't an invoke node for getting the value from the mouse coordinates like some other controls.
@johnsold wrote:
Resizable UI makes things at least an order of magnitude messier. Good luck.
Well my second post is really close and supports fitting to the pane. At the moment this is the method I'm going with but I need to figure out how to not fight the user so much.
@aputman wrote:
This same question popped up a couple of days ago. Altenbach made some suggestions. See if it helps you any.
Thanks, but most of those suggestions is what I'm already doing. Some of what he suggests I'm having a difficult time always doing correctly. Like for instance detecting when a user made a value change by sliding, and they are done. I can detect value changes no problem, but I can't rely on a Mouse Up event to indicate they let go, because that mouse up will be on the control and their mouse could move off of the control when they perform the release. But I guess I could try to read the mouse button status on value change to determine that, and not write to the local if the mouse is still down.
@johnsold wrote:
Here is another crazy idea. An XY Graph is resizable. Feed the array of timestamps to one axis. Set Marker Spacing to Arbitrary. Feed an equal sized array of zeros to the other axis. Create a single-plot cursor. The user can drag the cursor
I hate myself for liking this idea. Of course there's plenty of UI tricks I'd need to do to make it more usable. I'd prefer the X axis for the cursor to move along, I'd also need to code a custom control for increment and decrement, and I'd probably put a disabled slider behind it, so the user doesn't know it is a graph. But I've always found the 2 pixel spot of being able to use a cursor hard to find, so maybe it would be difficult for a user, since a slider is more forgiving.
@mikhail.musienko wrote:
Sorry for necro-ing a really old thread,
Don't worry, there wasn't a clear winner. Your's seems like a good contender but does limit a couple ways the user can interact, which to be fair I never put in as the original rules. When I think about how the user will interact with this control I think they might still want to click in any arbitrary place in the middle and have one of the sliders pop to the closest point to where the mouse is. Still I could see others thinking that the middle would be dedicated to a pan movement where clicking and dragging would move both points. Your solution at the moment discards all mouse downs and I'd have to get creative on when to discard and not, then capture mouse move as a pan.
The other thing this discard disables is the ability to move the slider by using the Digital Display. If these controls are shown I could see a user wanting to click the + or - and have it move the slider to the next, or previous points, within the bounds. Again I think code could be done to help with this, to not discard the mouse down, and then look at the Old and New values to figure out what direction and which slider to move.
And lastly the issue you already found can probably be fixed. You noticed the Mouse Move is only registered if the mouse is over the control and it is possible while moving left or right to drift up in a way that the movement stops reacting. I think this could be fixed by also looking at the mouse move on the pane, and then trying to figure out where the mouse is in respect to the slider. Still your solution works great, and fits to the pane and resizes well but does look weird if it is scaled vertically, but still is functional.
