MuShoo

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.

another-pictslider-question

when the mouse scale in not 1, just scale

clicking = more difficult. when you need 

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.


Yeah, clicking is the problem - ideally I need mousedown vs mouse up.

btw, i forgot ... in some old projects i used a simple

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

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.


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.

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.


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.

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.


there is a third thing which i am doing when using the

ubutton trick: the ubutton is light on CPU-for-GUI - as

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 

behind the rtl trigger there is also the place for 

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 

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 

that means stay awas from [zmap 1. 100. 0. 250.],

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

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


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 a pictslider patch that will show mouse-down and x-y values only when the mouse is inside pictslider.  Is that what you needed?

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

Another Pictslider Question