Another Pictslider Question

    MuShoo
    May 04 2009 | 1:45 am
    So I'm basically trying to replace an LCD with a pictslider, as pictslider has the ability to output a non one-to-one pixel ratio (IE a pictslider of screen width 200 can output 0 to 1000 in the same range, and mouse tracking can be adjusted).
    But, another part of my patch really needs to know when the user is dragging/clicking on the thing, and there's no outlet for that like there is in LCD.
    I'm toying with using Mousestate and some If/then statements, to basically only output mouse information if the cursor is in the correct screen area, but this seems like it will likely have a lot of unforeseen circumstances. For instance, when dragging the pictslider, mousestate gets incorrect numbers from the mouse, since the OS cursor is actually being centered on screen, and not tracking directly with the pictslider knob.
    • Roman Thilenius
      May 04 2009 | 1:54 am
      dragging = any change of output value.
      when the mouse scale in not 1, just scale the values likewise.
      clicking = more difficult. when you need mouseover position or when you click on the same pixel in the pictslider twice, you have a problem.
    • MuShoo
      May 04 2009 | 1:59 am
      Yeah, clicking is the problem - ideally I need mousedown vs mouse up.
    • Roman Thilenius
      May 04 2009 | 4:27 am
      MuShoo wrote on Mon, 04 May 2009 03:59Yeah, clicking is the problem - ideally I need mousedown vs mouse up.
      btw, i forgot ... in some old projects i used a simple method which might work for you here. create your pictslider as usual, but then put an ubutton over it, which is creating the actual data. it will be some work to recreate the ubutton output to give it a slider function, but at least it has mouse down mouse up by default.
    • MuShoo
      May 04 2009 | 5:08 am
      I'd actually toyed with that idea yesterday a little, but I abandoned it because it didn't seem to output data smoothly enough (and I lost the high resolution of pictslider). I think I figured out a workaround, though. Hard to explain in under like, a page, though.
    • Matthew Aidekman
      May 04 2009 | 5:30 am
      This is amazing good advice. 2 reasons:
      1: You get raw output which is good if you'd like to change the behavior of the object.
      2: It's irked me that I force UI objects to redraw twice if I have some set up where I take the output of an object, send it to the rest of the program and then the program decides to update the value. its one think if its a number box, it's another if its a huge slow JSUI. I think this is standard MVC behavior.
    • Roman Thilenius
      May 04 2009 | 6:37 am
      there is a third thing which i am doing when using the ubutton trick: the ubutton is light on CPU-for-GUI - as it does not display anything.
      so the data can get much faster from the mouse to where it is needed, all you have to do make sure the ubutton output goes first to the aim and then to the slider graphics behind it.
      behind the rtl trigger there is also the place for a [defer] or a [pipe 0.] when needed.
      the fourth advantage using ubutton comes to play when you need more than one GUI object to display the stuff you would like to see. (for example 2 picture sliders.)
      -110
      edit: not sure about "smoothly" - it could be that ubutton is 50ms and other objects are 20. i never noticed a difference but that doesnt mean there is none. just make sure you convert properly from int to int range. that means stay awas from [zmap 1. 100. 0. 250.], use [scale] or [expr].
    • Tim Lloyd
      May 04 2009 | 9:57 am
      I'm not sure whether you have this sorted or not, but I thought it was interesting so I had a go.
      Heres a pictslider patch that will show mouse-down and x-y values only when the mouse is inside pictslider. Is that what you needed?
      Might not be as cpu-freindly as using a scaled ubutton instead of pictslider, but it seems to work.
      edit : just realised it might also be useful to have a mouse-over for each pictslider
      heres the changed patch, hope its useful
    • MuShoo
      May 04 2009 | 3:12 pm
      Thanks, Tim! The mouseover feature is pretty great, this is exactly what I need! If it ends up being to slow I'll fall back to my workaround, but I think this should be fine.
      Thanks again!