widget switch changes position

Solar2D Widgets
#1

Hey,

I am experiencing a weird behavior with my switches.

When I enter the optional value “initialSwitchState = true” to the new switch options then the switch´s position changes - instead of using the “off” position it moves a little bit to the left and this looks really weird especially in my well organized app.

This is the standalone code that causes this behavior, just set the value to “true” or “false”:

 local widget = require "widget" local developerModeSwitch = widget.newSwitch ( { top = display.contentHeight/2 - 200, left = display.contentWidth/2, initialSwitchState = false, style = "onOff" } ) local autoUpdateSwitch = widget.newSwitch ( { top = display.contentHeight/2 - 150, left = display.contentWidth/2, initialSwitchState = true, style = "onOff" } )

Max

EDIT: This issue seems to be related to the iOS7 theme. I will fill in a bug report.

#2

I think at least 2 of us reported this bug. Its in the db and waiting to be fixed hopefully soon. 

#3

yes, shortly after I created this post I found your thread :stuck_out_tongue: I wonder why I didn´t see it when I googled and searched for this error first(?).

Anyway, I hope that this error gets fixed soon.

I guess the easiest workaround is to create the switches with initialSwitchState set to false (no matter what) and then simply use object:setState( options ) afterwards to make sure it shows the correct state :wink:

#4

No worries. Actually the more the merrier to get CL attention. 

In my splitView demo (posted on forum) I find that setState also causes the problem. Probably only workaround for now is to remove and recreate the switch.

#5

Jep, I can confirm this sadly :stuck_out_tongue:

What do you mean with “remove and recreate the switch”? How do you recreate the switch? Every method to create the switch with the correct state seems to cause this error.

#6

Oops. Sorry. I didn’t read your OP carefully. I was under the impression that the bug only affected post-creation value changes. So there is no workaround. This literally means the switch widget as is can’t be used until its fixed. 

#7

This sucks!

So what are you doing about this in your apps? Do you create your own methods for switches? With your own graphics?

Or are you using an older version of the widget library?

No switches at all?

Edit: Checkboxes are working at least…

#8

Yup. Not using them until they’re fixed. If you don’t mind mixing libraries then you can try the switch in widgetCandy. I hope CL fixes this one and other widget bugs soon. We sure have been waiting for a real long time. 

#9

I haven’t run into this but based on the description, isn’t the workaround to change the X position if the switch is isOn? So like this:

 if autoUpdateSwitch.isOn and switchFix then autoUpdateSwitch.x = autoUpdateSwitch.x + 5 end

I stuck a local switchFix = true flag at the top of the code, that way when the bug is fixed you’d only have to change that flag (although just ditching those three lines for each switch isn’t that big of a deal).

Jay

#10

Good idea but the horizontal movement occurs in both state changes and I think the amount of movement is not fixed but scaled based on resolution and device etc. You could probably get it to work but in all reality its probably not going to be a lasting solution.

#11

Tom from CoronaLabs support has just sent me a message regarding my bug report and he says that the bug fix will be in an upcoming daily build. 

If this is not an auto-generated message then the bug might be fixed soon :wink:

#12

I don’t think its an auto-generated message as I have many reported widget bugs which never got acknowledged let alone a promised fix. So this message from Tom must be written on purpose which is great news. Then again, “fixed in an upcoming daily build” could mean tomorrow or next year. Will believe it when I see it fixed. Thanks for sharing in any case.

#13

This is his original message:

"Hello,

We are aware of the issue and should have it fixed in daily builds shorty. Thanks for submitting the bug.

Regards,
Tom"

But yeah, I think they are actively working on the widget library :wink:

#14

I don’t want to get your thread “contentious” and cause it to get locked so I will say no more!  :slight_smile:

#15

I think at least 2 of us reported this bug. Its in the db and waiting to be fixed hopefully soon. 

#16

yes, shortly after I created this post I found your thread :stuck_out_tongue: I wonder why I didn´t see it when I googled and searched for this error first(?).

Anyway, I hope that this error gets fixed soon.

I guess the easiest workaround is to create the switches with initialSwitchState set to false (no matter what) and then simply use object:setState( options ) afterwards to make sure it shows the correct state :wink:

#17

No worries. Actually the more the merrier to get CL attention. 

In my splitView demo (posted on forum) I find that setState also causes the problem. Probably only workaround for now is to remove and recreate the switch.

#18

Jep, I can confirm this sadly :stuck_out_tongue:

What do you mean with “remove and recreate the switch”? How do you recreate the switch? Every method to create the switch with the correct state seems to cause this error.

#19

Oops. Sorry. I didn’t read your OP carefully. I was under the impression that the bug only affected post-creation value changes. So there is no workaround. This literally means the switch widget as is can’t be used until its fixed. 

#20

This sucks!

So what are you doing about this in your apps? Do you create your own methods for switches? With your own graphics?

Or are you using an older version of the widget library?

No switches at all?

Edit: Checkboxes are working at least…