I’m picking this up, because I noticed an issue with the button order on Android 8:
native.showAlert ("Title", "Message", { "Button1", "Button2", "Button3" }, onComplete)
This will result in the following quite random order on Android 8 (can’t test other versions at the moment):
Button2
Button3
Button1
I am using Build 3308.
Best regards!
Glad it’s not just me. Seeing similar, thought I was going mad. Can we get a fix for this? Or a timeline?
Chinning in unasked, but I don’t think Corona will change this. It would change an existing feature upon which others may depend, and it is relatively low priority compared to big ticket items and ANRs, continuing GDPR changes, etc.
You can fix this yourself by over-ridding the native.showAlert call. I’ll post a solution for you in a few minutes.
Ok thanks.
https://github.com/roaminggamer/RG_FreeStuff/raw/master/AskEd/2018/06/override_showAlert.zip
Decide the behavior you want.
Test on all targets and see what the default is.
Modify the code I provided to override behavior for those platforms that do not behave as you want them to.
Currently only modifying for Mac OSX, but I think Windows also reverses the label list, so you probably want to reverse it automatically too.
Re-test.
Done forever.
Thank you very much for your efforts! However, the problem is not that the order is just reversed - the button order is completely messed up on Android. So a potential “Close” button would appear anywhere in the middle.
Yes it’s seemingly random. Almost like it decides at run time, weird.
If you do Button1, Button2, and Button3 on Android 8 will Button3 always be the middle button or are you saying “random order” in that it may on one run be first another last, and a third run in the middle?
Rob
I’ll do some tests for you, but from memory it’s different most times, impossible to give the user safe guidance on where a button will be.
Hi. What exact version of Android are you running and what device are you running on?
Ah, I missed it. Android 8? Is that correct?
FWIW, On android 4.4.2, the button order matches the labels order passed in.
Here is and updated copy of the fix and an APK built with: 2018.3297
Buttons should come out in the order of the numbers in the labels (not the alpha parts):
https://github.com/roaminggamer/RG_FreeStuff/raw/master/AskEd/2018/06/override_showAlert.zip
For me the order is always the same at runtime, but different depending on the number of buttons:
“1”, “2” => “2”, “1” (horizontal)
“1”, “2”, “3” => “2”, “3”, “1” (horizontal)
“1”, “2”, “3”, “4” => “1”, “2”, “3”, “4” (vertical)
“1”, “2”, “3”, “4”, “5” => “1”, “2”, “3”, “4”, “5” (vertical)
So it’s seems like the problem is only with less than 4 buttons, when they are displayed horizontal. It seems like the first element is put at the end in this case. However, I can’t test how this behaves with other Android versions at the moment.
Best regards!
Not sure it’s based on the number of option, it’s one of space. On my OnePlus the buttons are always horizontal, on my Moto G5 they are always vertical but always in a different order.
The location is defined by the operating system and screen real estate, android tablets will likely always be horizontal (surely?)
Not had chance to do my tests but will asap. As you have that code working @bjoern perhaps change 1,2,3 for real world example of wording like: New Game, Save, Reply, Upload and Screenshot
Rob writes: “If we just output them in the order you provided you would have to write if statements for every native.showDialog() to reorder the buttons in the way the native OS wants them.”
It seems to me that you meant “we would”, not “you would” (since having the user write code to workaround the problem was an obvious (and already suggested?) solution.
So, using that interpretation (that you’re suggesting, and dismissing, the idea that Corona Labs fix the problem) …
Well, yes…that’s what you (CoronaLabs) should do, then: write the needed code.
When you have a problem that affects just about every caller of a function, the correct place to fix it is in the CoronaLabs code, not every user’s code.
There are at least two ways to avoid causing any backwards compatibility issues:
1. add a new function: native.showAlertNew ( …)
(documented as displaying buttons in left-right (or top-down if appropriate) order.
or, my recommended:
2. add a new optional final parameter: options
Example options: native.showAlert ( … (existing stuff) … , {left_right = true, vertical = true}
would request left-to right ordering, and that the options be listed vertically instead of whatever the default would be.
If options is missing, or {} or nil, then the actions are as they are now (even if somewhat unpredictable).
Morals:
1. work / changes should be done where you get the most bang for the buck …
sometimes that’s the Corona Labs. (And, almost always when it affects
every potential user of a function.)
2. adding an ‘options’ parameter can often extend / fix functionality in a completely
backwards compatible manner. And, it’s future-proof, as you can add more
option tags in the future. (E.g., format_bold = {1, 3}, format_italic = {1, 2}
could result in text for button 1 being bold italic, 2 italic, 3 bold … or
getting the default if the native OS doesn’t support that concept 
(I’m not suggesting adding format_*, just pointing out that an options table
allows not-yet-thought-of tags to be added later!)
Final note: no matter what, this odd ordering should be clearly documented in the manual / documentation, as documentation saves *EVERYONE* time and money … the users and CoronaLabs!
thanks,
Stan
I’m pretty sure we just hand the array of buttons to the device’s native alert code. We would have to write a lot of code for each platform to manage the button order and if the platform changes their style, we would be responsible for keeping it up. And doing so would potentially violate the platforms design rules.
However, Corona is now open source so you could download the code and address this yourself.
Rob
@Rob . thanks!
And thanks, too, for the mention of open source. I was unaware of this and will look into it for other reasons ASAP!
Stan
We just ran some tests on iOS and Android using 2 buttons in landscape, and it appears that the orders are reverse for the 2 as well. argh…
Apple products put the Okay button on the right of the list. Windows and Android would likely want to display:
Okay Cancel
But macOS, iOS etc want to display
Cancel Okay
If we just output them in the order you provided you would have to write if statements for every native.showDialog() to reorder the buttons in the way the native OS wants them. This is expected behavior.
Rob
Rob - that’s the thing that’s weird for us. We found that the Mac Simulator and the iOS devices use different orders. Attached is our test code and resulting screenshots. We are using Corona 2018.3389.
https://www.dropbox.com/s/mimg88qdlwtbejt/showAlertTest.zip?dl=0
We are OK if this is the expected behavior (vs a bug), but want to be sure before we put in our own code. Thanks.
Rob writes: “If we just output them in the order you provided you would have to write if statements for every native.showDialog() to reorder the buttons in the way the native OS wants them.”
It seems to me that you meant “we would”, not “you would” (since having the user write code to workaround the problem was an obvious (and already suggested?) solution.
So, using that interpretation (that you’re suggesting, and dismissing, the idea that Corona Labs fix the problem) …
Well, yes…that’s what you (CoronaLabs) should do, then: write the needed code.
When you have a problem that affects just about every caller of a function, the correct place to fix it is in the CoronaLabs code, not every user’s code.
There are at least two ways to avoid causing any backwards compatibility issues:
1. add a new function: native.showAlertNew ( …)
(documented as displaying buttons in left-right (or top-down if appropriate) order.
or, my recommended:
2. add a new optional final parameter: options
Example options: native.showAlert ( … (existing stuff) … , {left_right = true, vertical = true}
would request left-to right ordering, and that the options be listed vertically instead of whatever the default would be.
If options is missing, or {} or nil, then the actions are as they are now (even if somewhat unpredictable).
Morals:
1. work / changes should be done where you get the most bang for the buck …
sometimes that’s the Corona Labs. (And, almost always when it affects
every potential user of a function.)
2. adding an ‘options’ parameter can often extend / fix functionality in a completely
backwards compatible manner. And, it’s future-proof, as you can add more
option tags in the future. (E.g., format_bold = {1, 3}, format_italic = {1, 2}
could result in text for button 1 being bold italic, 2 italic, 3 bold … or
getting the default if the native OS doesn’t support that concept
(I’m not suggesting adding format_*, just pointing out that an options table
allows not-yet-thought-of tags to be added later!)
Final note: no matter what, this odd ordering should be clearly documented in the manual / documentation, as documentation saves *EVERYONE* time and money … the users and CoronaLabs!
thanks,
Stan
I’m pretty sure we just hand the array of buttons to the device’s native alert code. We would have to write a lot of code for each platform to manage the button order and if the platform changes their style, we would be responsible for keeping it up. And doing so would potentially violate the platforms design rules.
However, Corona is now open source so you could download the code and address this yourself.
Rob