Just looking at the screenshot and the first entry: Append.
Uses Dim instead of the more modern Var
Uses Ubound which has been deprecated.
Other things are deprecated. (MsgBox)It should probably made clear that this tool is for older versions of Xojo.
Can’t open it unfortunately.
Funny, I didn’t know that “GoTo” still exists … I might want to “surprise” some co-workers in the next days :-). More seriously: this might be helpful for some beginners, but should indeed be converted to API v2, or this version should be declared what it is: API v1. One column for APIv1 and one for APIv2 might be helpful as well.
I have been using 2011r4.3, because the .exe files generated by the versions after 2011r4.3 are very huge. For example, an simple application,
2011r4.3 – 4.8MB
2016r1.1 – 25.7MB
So I continue to use this very old version.
While I’m sure we all understand your reasoning, 99% of Xojo users are using 2019r1 or later so you really should make your guide for API2 if you want it to be useful.
And at some point you will need to upgrade yourself any way. I don’t know why there’s such a big difference in the size of the exe but I’m sure it is for a good reason. And anyway, the size of an app hardly matters these days.
Thanks, friend. I’m a newbie and I could use all the help I can get, minimalistic or otherwise. I’ve had this file for ten minutes and I’ve already used it. Somebody pointed out the “go to” command in your list. That’s a trip. You just know I’m going to try it right away. Haven’t typed a “go to” since VB 6 but I suddenly realize how I’ve missed it.
That was me ;-). nothing wrong with GoTo if your app works, all is fine. But when you will dive a bit more into Xojo you will soon realize that it is rather a bad idea to still using it in 2020. of course it might help while converting a vb6 project but there are more powerful ways to structure your code. the Xojo documentation of Goto shows you a few concerns.
Goto’s are famous to cause leaks due to internal flaws handling scopes. A goto jumps to places without releasing resources because the user could potentialy “jump back” and a expected value is now gone. Something by these lines, and sh*t happens at some point. How to avoid such kind of problem? Don’t use Gotos.
Very good point but I think Gotos are still important for app end users doing simple Xojo scripts that don’t have the structure of a full blown app, and in which app end users don’t really understand what a class or module is.
I haven’t used GOTO since I stopped writing FORTRAN in 1978.
Didn’t like FORTRAN. I found COBOL easier but always liked BASIC. Would you believe in 1979-81 at high school they introduced us to all three? No idea why that was necessary.
Last time I used GOTO in Atari Basic, it was 35 years ago.
For high level languages, nope. People should just learn how to structure well their code. For Assembly? Yes, “Jumps” are necessary, they mostly do the THEN and ELSE of the low level.
While I likely won’t use it myself, I applaud your effort to share and contribute. Keep up the great work!
I liked FORTRAN. Personally I found FORTRAN and BASIC to be very similar. For years after that I did mostly COBOL. You could certainly write mor readable code back then in COBOL. The one thing I hated about it was the ALTER statement whcih allowed you to change where the GOTO jumped. A real nightmare to debug.