We join our intrepid developer on his continuing adventure into updating his WebDev app to take advantage of the latest browser code enhancements and new native controls.
In today’s episode, we take a look at a very subtle “bug” with string slicing in Version 2 of browser code.
We have a fairly simple browser procedure that formats the date a specific way so that it matches some other things we are doing. To be honest, I suspect this could be replaced with a simple DateToString function now, but that is yet another topic for another day.
PROCEDURE BrowserDateToString(inDate is string ) Months is array of strings = ["January", "February", "March", "April", "May", "June", "July", "August", "September", "October", "November", "December"] RESULT Months[inDate[[5 TO 6]]] + " " + Val(inDate[[7 TO 8]]) + ", " + inDate[[1 TO 4]]
The procedure is being called and passing in the value of an edit control, that edit control holds a date (20190730).
After a whole lot of trial and error, starting with the fact that it was 2 day before we even knew we had an issue, we discovered it was the above procedure. And with a bit more trail and error I found a simple solution. Just make the incoming parameter Local
PROCEDURE BrowserDateToString(LOCAL inDate is string ) Months is array of strings = ["January", "February", "March", "April", "May", "June", "July", "August", "September", "October", "November", "December"] RESULT Months[inDate[[5 TO 6]]] + " " + Val(inDate[[7 TO 8]]) + ", " + inDate[[1 TO 4]]
In case you are not aware, most programming languages parameters are passed by value by default, and by address only if specifically coded that way. WLanguage, on the other hand, is just the opposite, parameters are passed by address unless specifically coded to be local. BTW, there is also a double ( syntax to make the parameters local.
I am not sure if this is “By Design” or a “Bug”, but I have submitted it to support and will let you know once I hear back from them.