Hello guys,
I need to input a time interval (period not a daily time) so I use a Notifier.ShowText dialog. If I press OK everything runs well but if I press the button "Annulla" (Cancel in english) it produces this error:
The operation * cannot accept the arguments: , ["Annulla"], [3600000] Note: You will not see another error reported for 5 seconds.
it does not insert the time pressing Annulla also if I enter a valid time period so it basically works but the error is visible both on PC (using companion) and on the smartphone and this is not so good.
Any known workaround?
You need to show all your relevant blocks, what about the after text input block ? What are you doing with the output from the text input ? What does msecToTimeString look like?
The other parts are OK, used in many apps. To test the behaviour on TextInputCanceled there is a ShowAlert "Annulla pressed". But seems I found the problem. AfterTextInput is executed always, also when I press the Annulla (Cancel button) and, unfortunately, the response parameter reflects the i18n string of the button... so it may be Annulla, Cancel and whatever else in other languages... to don't execute the AfterTextInput I have to add an if to check if response differs from Cancel/Annulla/whatever else in other languages supported by the app. But, honestly, I think AfterTextInput should not be executed if I press Cancel/Annulla. Only TextInputCanceled should be executed.
In this particular case I could validate the input using a regex, in this way I can overcome the problem to check for several strings eqyivalent to Cancel.
I do not know if it will be deprecated, actually it is an event of Notifier.
This is not optimal but it solves the problem, I will change it introducing input validation using a regex instead of testing for Annulla:
I believe that the change that was implemented for the next version will solve this problem for you. Originally, only the AfterTextInput event existed, but because the label is internationalized it made it difficult to create apps used in multilingual contexts. The TextInputCancelled event was added to help with this but for backward compatibility we originally decided to trigger both events to allow people time to migrate to using the new event when handling cancels. The change in question will now only run AfterTextInput blocks when the dialog is cancelled if and only if the TextInputCancelled event isn't defined (for backward compatibility with older apps where this event didn't exist).
The point of the separate event is to not have to worry about handling special conditions like that. If anything, the invocation of triggering the AfterTextInput when the input is cancelled violates the semantics of the name (i.e., no text was input so why is there an "after").
Yes, the violation of the semantis is evident, if AfterTextInput will not be fired in any case it should be better, so in this way the response will always contain the data input by the user. There is no need to fire it always, also if TextInputCanceled is not provided. Initially I did not implement the TextInputCanceled event and the if response != "Annulla" inside AfterTextInput because I supposed AfterTextInput was not fired pressing Cancel/Annullla button. I did that to solve the problem.
