f2cx, I think you’d have to call a routine that sets the position of the sliders based on their current values every time you bring up the screen… I haven’t done anything with this yet, but will have to when I add the sliders to the program I’m working on. [import]uid: 9905 topic_id: 3276 reply_id: 10932[/import]
thanks for responses
@horacebury: part of the display group is ok…
@DavidBFox: thanks in advance for your code. I hope it’s on the top of your to do list :))…
[import]uid: 8970 topic_id: 3276 reply_id: 10956[/import]
@ DavidBFox No, I haven’t made any progress as I’ve not had any time on it either, but Yes, I am working on it and I’m completely restructuring the code to provide even more functionality and ease of use. Will post the code when it’s finished. I need it too. [import]uid: 8271 topic_id: 3276 reply_id: 10977[/import]
@f2cx, i’l let @horacebury run with it for awhile… better, I think, not to have two of us switching things around.
@horacebury, I went to the Corona SDK meetup last night and was able to show the demo to Carlos and Gilbert. Both really liked it… not something they’ve implemented yet. [import]uid: 9905 topic_id: 3276 reply_id: 10985[/import]
@f2cx Hi, I’ve been working a lot on my latest version of the control and something became very apparent to me. I think the reason the slider will be in the wrong place is because the display group you added it too has moved. The slider will try to keep its position within the bounds of the viewport and that area will not move, even if the display group moves.
To explain what I’m getting at: The current problem I face is that if I add my new slider (which is a collection of nested display groups) to another display group and then move that base group, the slider itself has no way of knowing if the touch event’s x and y values are within its own bounds, because it is trying to compare world coordinates (the touch event’s x and y) against it’s own position x and y, which is based on the original of the parent display group. Of course, the parent’s origin may move, but as a reference point it is static and therefore (0,0) never changes, and so, as far as the slider is concerned, it never moves.
If that was a bit long winded and over-worked, try this: draw three rectangles inside each other; Move the second rectangle. If the inner-most rectangle always moves parallel to the second rectangle, how would it know if the outer-most rectangle ever moves?
I checked the other coordinate values in the graphics system (origina, reference, etc.) and (unless i’ve missed something) there is no way for a child of a display group to know where it is in the world, without being explicitly told.
Ok, longest post I’ve ever written ending.
Matt. [import]uid: 8271 topic_id: 3276 reply_id: 10999[/import]
Ok, so, I’ve been working on this slider and it’s still called SliderTest, but I’ve put in as much functionality as I can, minus one thing, which I’ll keep to myself til I have the time, but it’ll be worth it…
Anyway, the new code is here: https://files.me.com/horacebury/qowp06
This version:
Debugged and structured properly - now uses nested display groups,
Sliders can be variable or not - not means they will always gravitate to one end or the other,
When variable the slider can be positioned anywhere in the viewport,
When any slider is fully at one end or the other and is tapped it fully slides to the other end,
Sliders can be given a speed - this is used to always move the slider to its destination at the same speed, no matter where it is released,
The touch area can be bigger (but not smaller) than the viewport - called viewport.bleed,
The optional over image will be used when the touch is within the optional range of the viewport - called viewport.range, defaults to 70 pixels,
Focus now clears itself properly,
Multi touch is supported,
Two optional callback functions can passed in:
onComplete is fired when the slide or variable drag is finished,
onMove is fired whenever a touch event’s move phase drags the slider, regardless of isVariable value,
Both callbacks have the more useful event object passed back, including: id, phase, x position, state (3 string values, not boolean) and value,
I hope this can be useful to some and please let me know if you have any questions, problems, bugs or suggestions.
Matt. [import]uid: 8271 topic_id: 3276 reply_id: 11006[/import]
In case anyone is interested, I just uploaded a new version of the slider with rotation added. Use link in previous post.
Matt. [import]uid: 8271 topic_id: 3276 reply_id: 11010[/import]
Ok, one more for tonight…
Just added:
3 functions (see end of main.lua) to set the position of the slider by x (-ve to +ve values), value (+ve only values) and “on”/“off” state,
Debugged double “ended” state callback firing.
Have fun,
Matt. [import]uid: 8271 topic_id: 3276 reply_id: 11013[/import]
Hmm, thought I had added everything I could think of. I was wrong…
I’ve added an extra parameter to the main newSlider call. This now takes a table with values left and right. These are image file names to be attached and repeated to the left and right of the slider for when the slider image width is smaller than the viewport width.
I’ve updated the example .zip with a wide slider at the top, so to see what I’m rambling about, download and take a look. Same link as before, but here it is again: https://files.me.com/horacebury/qowp06
Feel free to use the red, green and yellow parts.
For those whom want to know, the parts get added to the display group containing the slider image and have their isVisible value set if they are within the gap between the viewport and the slider image.
Matt. [import]uid: 8271 topic_id: 3276 reply_id: 11025[/import]
Hi Matt – looks like you’re making great progress on this!
I took a look and saw a few minor issues…
In the version I gave you before, I made sure that the button highlight only activated when you clicked on the button portion itself rather than the rest of the slider, mimicking Apple’s implementation. In your version, that feature was lost. Was that intentional, or just the result of your refactoring?
I’m also thinking that rather than using a single background with a bunch of cut-outs, what about using a small cut-out that’s just the right size to mask the slider and include that as part of the slider’s group. That way you just move the entire group to where you want it and don’t have to worry about preparing the background. That should also work fine for when you want to rotate the slider. You’d then use a plain rectangle to fill in the rest of the screen as needed (behind the group).
I also notice that the top two buttons in the group of 4 were vertically too low by 1 pixel. The Y value should be y=343 instead of 344.
[import]uid: 9905 topic_id: 3276 reply_id: 11038[/import]
Ok, just one more.
This update allows multiple images to be used on either side of the slider image. To demonstrate, I’ve cut up the red, green and yellow strips into smaller images not all the same width) and provided tables of their names. The slider accepts the image names in order from left to right, so if you’re cutting up your images in that direction, just list their filenames in that order for both sides.
I’ve also fixed a bug with the ‘over’ image, so now it won’t break if an over image isn’t used and the over image is faded into view when the touch is within range of the over image/tab, not just the whole viewport.
Matt. [import]uid: 8271 topic_id: 3276 reply_id: 11039[/import]
Hi David,
Yes, I noticed the pixel problem too and fixed it in the previous version.
I’ve thought about the foreground image being part of the slider group and will put that in in the next version. I also want the rotation values and parent group x,y values to be taken into account - so the slider can be moved anywhere and not forget about it’s place in the world. This would solve the problem @f2cx was having. Funnily enough, it would also allow the root slider display group to be given a physics body and thrown around, but that’s just a side effect of being aware of it’s world location.
Lots more ideas and plans to make the scrolling popup menu using a similar mechanism.
Thanks for the feedback, I hope the control is useful.
Matt. [import]uid: 8271 topic_id: 3276 reply_id: 11041[/import]
Hi Matt,
I’m not seeing a fix to what I described about the button ‘over’ image. It should only highlight if you actually tap or touch that portion. I see it highlighting no matter where on the slider you touch.
Also, if you touch on the button and slide your finger out of the range before releasing (without moving the slider horizontally at all), the slider should not move (that should represent a “Cancel” event). The earlier versions (including mine) worked that way. That also matches Apple’s UI standards.
Re using physics… so, sounds like a game? You launch a slider group into the air and see if you can slide it before it lands? Maybe it’s an on-off switch on a bomb? (just kidding… but hey…)
[import]uid: 9905 topic_id: 3276 reply_id: 11042[/import]
Ok, no problem. My implementation shows the over image when the touch is in range of the over image. I’ll work on the improved version later…
Matt. [import]uid: 8271 topic_id: 3276 reply_id: 11043[/import]
Thanks for this work, top useful.
I found a way to keep the position of a slider on/off when changing screen; and it works! Here are changements I did:
a) In sliderOnOff.lua
–I CREATE A NEW FUNCTION
function lastPosi()
if (initon) then
img.x = img.minx
else
img.x = img.maxx
end
end
b) In screen2.lua (suppose the slider on/off is in this screen)
–FUNCTION AMENDED
function firstOption( event )
–Do something…, for example
media.setSoundVolume (event.value)
–I ADDED this code to invert value of “initon”
if (initon) then
initon = false
else
initon = true
end
end
c) In screen2.lua
–FUNCTION AMENDED
function CreateMainMenuPanel()
– create display group
mainmenupanel = display.newGroup()
– add sliders
–AMENDED, Put “initon” as last parameter instead of true or false
mainmenupanel.aslider = slider.NewSlider( mainmenupanel, “onoff.png”, iphoneDimensions.firstviewport, firstOption, false, initon)
–ADDED, to activate lastPosi
mainmenupanel.sliderP = slider.lastPosi()
end
I hope it’s clear, and maybe useful. [import]uid: 8970 topic_id: 3276 reply_id: 11109[/import]
Hi f2cx, is this a modification to my latest code or the original?
m [import]uid: 8271 topic_id: 3276 reply_id: 11142[/import]
The original (with radioactive image).
The same principe is also ok for your last version (in this case, read “function defaultCallback” instead of function firstOption".
[import]uid: 8970 topic_id: 3276 reply_id: 11146[/import]
Latest code is up at the usual url. This includes:
Some slight tweaks to the rotation code to make it more accurate,
Very slight performance increase in the touch range checking,
The addition of an onCancel callback for when the slider is left in the same position as it start and the release is made out of range,
Highlighting of the tab using the over image only when the tab is initially touched.
Matt. [import]uid: 8271 topic_id: 3276 reply_id: 11229[/import]
Matt, looks great! Thanks for the polishing it up! [import]uid: 9905 topic_id: 3276 reply_id: 11279[/import]
is f2cx’s modification in the latest version?
Would be nice for it to remember the state of the slider?
Or should I just have a global variable in my maim.lua that keeps the state of an option and do this…
if(opt_music == “true”) then
mainmenupanel.musicslider:setState( “on” )
else
mainmenupanel.musicslider:setState( “off” )
end
[import]uid: 9371 topic_id: 3276 reply_id: 11605[/import]