Window

[horacebury]

Sorry if this has been posted before (I went looking and couldn’t find it) but I’d really like to provide a slider option control in lieu of the native UI not providing such a thing. Basically, I’m talking about the same kind of control as used in the settings app on the iPhone/etc, as in ON/OFF. Its neat, easy and intuitive.

The problem is that, in Corona, images (as far as I can see) can’t be windowed or viewport’ed. What is needed is a way to show part of an image, while not needing to hide the rest of it behind another image. Sprite sheets are good for animation, but not here, as the image (in this case, at least) really needs to move with the user’s touch, making dynamic sprite definition difficult and CPU intensive.

Perhaps Ansca have a view on this?

Thanks,

Matt. [import]uid: 8271 topic_id: 3276 reply_id: 303276[/import]

[jmp909]

masks are in the feature requests. currently you’d have to stick an opaque overlay on top of your button the same colour as your background, but with the shape cut out in the middle

here’s an example in flash. The interaction is a bit glitchy and again it needs a mask.
[import]uid: 6645 topic_id: 3276 reply_id: 9836[/import]

[horacebury]

Ok, that’s what I thought. As I need it right now, I’m building a (fairly simple) lua class to implement this, as shown here (but for one slider): http://tothepc.com/img/2010/09/iphone-auto-correct.png

Will post code when done.

Matt. [import]uid: 8271 topic_id: 3276 reply_id: 9845[/import]

[mark.carolan]

This may or may not be useful. It takes an image and scrolls it, without requiring an overlay, for a “ticker-tape” effect. Shouldn’t take much to add interaction. [import]uid: 3953 topic_id: 3276 reply_id: 9922[/import]

[DavidBFox]

Matt, I could use this too! I was putting off building it myself in hopes that the Corona SDK would support Apple’s native controller. [import]uid: 9905 topic_id: 3276 reply_id: 9937[/import]

[horacebury]

MarkHenryC, thanks for that (I’ll have to look later - got to get to work…)

However, I just last night finished the principle work on the slider.lua, as I’m calling it. Basically, you give it an image and an area that it can be seen behind, then plonk it behind a transparent hole in another image. This is because all I’ve handled is the sliding/value return.

I will be working on it to make it more precise, better handling, but there seems to be some interest, so I thought I’d share it now. Because it’s not really complete, I’ll just post a link to my shared file, but I will post complete code later:

https://files.me.com/horacebury/u14xyb

Thanks for the interest,

Matt. [import]uid: 8271 topic_id: 3276 reply_id: 9939[/import]

[DavidBFox]

Matt, how’s your work coming on this? Would you be willing to share the code as well as the images? [import]uid: 9905 topic_id: 3276 reply_id: 10429[/import]

[horacebury]

Hi,

I did some debugging and the code is now a lot more stable and accurate. I’m now using it in my interface very reliably. Here’s the link to the shared zip of the complete demo, images and demo main.lua: https://files.me.com/horacebury/qowp06

If you just want the slider.lua here it is: https://files.me.com/horacebury/u14xyb

Basically, the slider is a simple screen grab of the one in the iphone settings, but the user can tap to change it’s state, or grab and slide it. If it is set to variable mode the slider stays where it is, but if not it will gravitate to the nearest end of the viewport.

It is essential to get the viewport size correct and remember that the viewport is not the same size as the image behind it, but only as big as the width of the image you want to show at any one time.

When the slider finishes sliding from one side to the other or left in place (whether tapped or dragged) it will optionally fire a callback with .state (true/false) and .value (0-slide width) position information. It will not report the type of motion the user performed, but I can’t see a point in that right now. If anyone does, please let me know and I’ll include it.

Also, the variable mode (ie: it will not gravitate to one end or the other) has not been rigorously tested, so if anyone notices problems there, please let me know.

Thanks,

Matt. [import]uid: 8271 topic_id: 3276 reply_id: 10467[/import]

[DavidBFox]

Hi Matt,

I spent some time looking at your slider, and also comparing it to how it works on the iPad/iPhone. I just uploaded my changes to your code. You did a great job on this, and it was fun to tweak things to make it a bit closer to Apple’s version.

You can download mine here:

http://www.ElectricEggplant.com/corona/OffOnSliderTest.zip

Here’s what I changed:

if isvariable is set to true, I get an error:

Runtime error ...rona SampleCode/Interface/OffOnSliderTest/slider.lua:82: attempt to call global 'TapComplete' (a nil value) stack traceback: [C]: in function 'TapComplete' ...rona SampleCode/Interface/OffOnSliderTest/slider.lua:82: in function <...rona samplecode><br> ?: in function <?:186><br>

so, what is TapComplete? I ended up commenting out that line:

<br>--TapComplete( nil )<br>

I created a light grey screen background with anti-aliased cutouts so the sliders fit a lot better.

I changed it so that if you move the slider at all from its starting point, it goes to the other endpoint. This seems to match Apple’s sliders on the iPhone (rather than only doing that if you moved it at least half-way across).

I added an “over” state to the button portion of the slider, but only if you click on the button part. (to match Apple’s)

If you click on the button part and then drag off the button, the highlight goes off when you’re 10 pixels outside (adjustable) and comes back when you’re in range.

Fixed it so if you click outside the viewport, the button no longer moves (before, clicking to the left or right, depending on where the slider image was, would trigger it to move)

Previously, if you click on a slider, event.target.isFocus is true. After that, you were able to swipe in from off the button and onto it and it would still react (but only the button you last clicked on). Now fixed.

I also ended up changing the initial caps of the function names to lower case… seems that’s the standard that others are following here. I also added a capital letter in the middle some of the names to make them easier to read.

I’m sure there’s probably a much more elegant way to code all the things I changed… I’m still learning, so just figured if it works, that’s good for now. [import]uid: 9905 topic_id: 3276 reply_id: 10745[/import] </…rona>

[horacebury]

Hey, nice work, really didn’t expect anyone to run with it that much. Thanks for the and isFocus fixes especially, I hadn’t really tested it to breaking - only as far as I need. Awesome work!

Matt. [import]uid: 8271 topic_id: 3276 reply_id: 10746[/import]

[DavidBFox]

Glad I could help! In your version, what is TapComplete()? Is that a function you hadn’t created yet? [import]uid: 9905 topic_id: 3276 reply_id: 10747[/import]

[horacebury]

TapComplete used to be a direct callback to a passed in function, but should now be the same as the onComplete call performed by the transition.to, just below it in the second half of that same if statement. It is there to pass back the values to the calling code, but it looks like I forgot to implement it properly when refactoring. It should probably just say:

img:onComplete( nil )

Btw, when did you get my .lua file? The latest version I put up was on Nov 8th, but from your posts it sounds like you got that version, so it should be fine.

Thanks for the great work, I’ll implement your version in my code!

Matt. [import]uid: 8271 topic_id: 3276 reply_id: 10748[/import]

[horacebury]

Btw, again, have you thought about integrating CheckViewports into the slider.lua class, rather than having it separate? It would be nice to have all the functionality seated in one place.

Matt. [import]uid: 8271 topic_id: 3276 reply_id: 10749[/import]

[DavidBFox]

Matt – I downloaded it right after you posted the zip version that had the images with it. Yes, looks like it was on the 8th.

For the blue slider I’m using, I got that from a screen grab off my iPhone. I’m also using your orange version.

My code with the overlay button isn’t very general purpose… it probably will only work with the Apple style sliders.

Next thing I’m going to need to do is figure out how to get these sliders into a vertically scrolling interface so I can turn on/off several parameters…

Also, need to make it work for iPad and iPhone 4 with their different resolution. [import]uid: 9905 topic_id: 3276 reply_id: 10750[/import]

[DavidBFox]

I actually did try to put the CheckViewports into slider but it broke several things, so I reverted… I wanted to get a version uploaded tonight. But yes, it does make sense to move that. Do you want to take a stab at it? I’m not going to be coding tonight or most of tomorrow so I won’t be able to get to it until Friday. [import]uid: 9905 topic_id: 3276 reply_id: 10751[/import]

[horacebury]

My thoughts exactly - however, have you thought about passing all parameters regarding images etc in as a table, then the slider won’t need to worry about resolution.

Also, what about having an ‘isVisible = false’ rectangle (display.newRect) over the viewport hole ( basically exact same location and dimensions as the viewport) and setting that to have ‘isHitTestable=true’ and setting the touch/tap event listeners to that. Then the focus can be set to the slider after the touch has started.

I was going to try to implement everything you’ve implemented in my own code, as that’s how I learn from others - and I can really frok other’s code without mangling it in my own head. But I have to get into the office now… goodbye Costa Coffee for another day.

It would be great to have this slider as a fully debugged, de-facto standard for corona devs, with all the horizontal and vertical options available. So, thanks again for your hard work

Matt. [import]uid: 8271 topic_id: 3276 reply_id: 10752[/import]

[horacebury]

One last thought, actually. The touch area should probably be slightly larger than the viewport itself, as I’ve noticed the sliders in my iPhone’s General Settings section seem very easily hittable with my thumb, but not so my slider, because of the size. I’m thinking the invisible rectangle used to detect the touch could be made “viewport size + bleed parameter” to make the slider a bit more hittable. This should not present a problem when sliders are close together, because they never should be, in a touch environment!

Matt.

Ps: I’m trying to think about how to implement proper scrolling in popup menus like the iPad has. I’ve made a couple of posts on this around the place. If you have any ideas on this, I’d love to hear them. The big problem is that because Corona can’t provide viewports itself, any scrolled content has to hide somehow, of course, and in a popup menu this is near impossible, without massive borders. [import]uid: 8271 topic_id: 3276 reply_id: 10753[/import]

[f2cx]

Very nice work ! Thanks a lot.
Question/help: I put this slider on screen2 of an application (cf. director class to change screen) to switch on/off a sound volume.
When I go to screen 1 and then back to screen2, the position of the slider is lost (img.min.x or img.maxx), but sound on/off is correct and kept.
How to amend the code to keep the position? Thanks in advance for your help and an example. I lost a lot of time with this.
[import]uid: 8970 topic_id: 3276 reply_id: 10881[/import]

[horacebury]

The sound state will have been kept because that won’t change unless the event handler (touch/tap) is fired. I would assume the slider is not part of the display group which shifts on/off screen…?
I’ve not used the Director code from the sample pages, I’m afraid. [import]uid: 8271 topic_id: 3276 reply_id: 10897[/import]

[DavidBFox]

Hi Matt – sorry for the delay. Have you done any more work on this yet? I haven’t been able to do much.

To answer your questions…

Interesting idea about using a rectangle for the viewport. Have you tried it yet? Seems like it would be a good solution, and might make it easier to move the sliders around (especially if the rectangle were part of the slider’s group).

I’m thinking we might have to pass on popups, unless the rest of the screen is covered, or you cleverly position the sliders so the hidden parts will never show.

As far as size of the touch area… when I tested Apple’s sliders on the iPhone and iPad, the touchable area matched exactly with the actual image. Are you testing on an iPhone 4? If so, then that could explain it since the slider would be 1/4 the size it should be. I have some changes I made in my version so I could test on an iPad and it’s perfect.

What I’m hoping, though, is that Ansca will make all this moot by giving us access to the real Apple iOS controllers, in which case this was all a really good learning exercise. [import]uid: 9905 topic_id: 3276 reply_id: 10931[/import]