Xojo 2019r2 & API 2.0

There’s a lot of changes in R2

There are some that are very minor. Like making VAR a synonym for DIM. You can use it or not. It functions no differently.

Some of them are very welcome like updates to URLConnection for one. The JSON Parse and Generate methods seem to work a LOT faster now. And there are a pile of useful extensions on various types. And a lot of fixes in the IDE to make it faster.

The navigator draws a little differently but seems a bit snappier.

Folderitem was updated significantly on macOS to use much more modern API’s. The newer APIs used should make folderitems operate a lot faster on newer versions of macOS. They no longer use the slow code path that Apple had in place that could make APSF volumes really slow with older versions.

A number of things that have been deprecated for a long time are removed so you will have to update code to fix those if you’ve avoided them until now. If you still need to use this code in an older version you can use an #if XojoVersion conditional compilation directive around the old code and it will compile without issue.

That’s the easy stuff.

There are a couple changes that may cause problems as they are silently going to happen just by opening your project in 2019r2.

If you placed TCPSockets, UDPSockets or instances of any of their subclasses on layouts at design time then be aware that the Error event will get a new parameters when you open in 2019r2. This _should_ not have any effect or cause any issues.

If you create folderitems using URL’s check all your inputs to the constructors. I’d strongly recommend you analyze your project and look for deprecated folderitem constructors. If you happened to write code that uses an URL Path with a query portion to get a folder item this behaviour has changed between older versions and 2019r2. The old and new constructors both get this changed behaviour. If you had code that did something like

Dim file As FolderItem = SpecialFolder.Desktop.child("Hello World")
Dim urlpath As String = normFile.URLPath + "?key=value"
Dim resultfile As folderitem = GetFolderItem(urlpath,FolderItem.PathTypeURL)

You’ll find that the result you get in 2019r1.1 and earlier is quite different that what you get in 2019r2. Xojo chose not to fix this behaviour change or introduce a new FileSystemItem class to segregate the old and new behaviour like they did with Date and DateTime. While I understand their issue with updating the entire framework to use this new FileSystemItem or duplicating every function to have old functions returning folderitems and new ones returning FileSystemItems its still disappointing that this reasonably silent behaviour change has happened. I’d be surprised if a lot of people used URL paths this way. I do know its more than zero that did and they’ll have to update their code to deal with this difference.

Another thing that may make updating difficult is that a fairly large number of events and properties got renamed. When you open your project in 2019r2 the renamed events are not automatically updated to their new names so both the old and new event names exist. This may not affect you. The issue I’ve experienced is that if you happened to subclass controls and added events to your subclasses the new names Xojo is using might conflict with the ones you defined previously.

The really hard part is that to fix this you have a hard time doing it 100% accurately in a large projects in 2019r2. Xojo can’t help you because the old event name is still legal to use and instances can implement it. Its just not the event you defined previously in your subclass. Its now the one Xojo defined. If you find you’re in this position make sure you do whatever updating and renaming of your events in 2019r1.1 as the 2019r2 compiler can’t help you find them.

For example if in 2019r1.1 you created the following

Class CustomTextField
Inherits TextField
		Sub TextChange() Handles Event
		  
		End Sub

		EventDef TextChanged()
End Class

and then put an instance of this class on a window layout and Run everything is fine. Save this project and reopen it in 2019R2. You should get a compile error

CustomTextField.TextChanged Declaration
 This property has the same name as an event. You must resolve this conflict
 Event TextChanged()

Xojo added a new TextChanged event to TextField. And now the event definition you had in your subclass now conflicts with the Xojo one. If you alter your TextChanged event definition to be DoTextChanged and run everything seem to work. Your project compiles and runs but TextChanged in the instance on the layout is NOT going to be the DoTextChanged event that you defined before. Nor will it get raised when you expect.

Now the TextChanged event is the implementation of the framework event because the name was taken over. And, since R2 takes this name over, you have a hard time being 100% sure you have fixed all your implementations and all the code that raised that event. It all still compiles without error. So if you have this situation fix these errors in 2019r1.1 which WILL complain if you miss one or don’t fix the code that raises your custom event.

So what CAN you do about this if you do not want to do a LOT of work right now but want to get the fixes for other items ?

That will have to be a whole new column on dealing with the differences as it definitely depends on your circumstances and whether you need to support backwards compatibility with oder versions of Xojo.

R2 deprecates a LOT of methods. Things like Mid have been renamed to Middle. The renaming is fairly innocuous. However an analyze of one of my clients projects resulted in more than 15000 deprecation warnings. Theres just no easy way to deal with that many.

Be careful about just updating with the suggested replacement without examining your code. The reason is that in many cases the old method might have used 1 based indexes and the new one uses 0 based indexes. So you not only have to replace the name you also have to examine the code to adjust for the different indexing or you will cause a lot of off by one errors.

And, as soon as you do update to use the new methods, you are going to need to handle exceptions they may raise. API 2.0 is switching everything to using exceptions rather than error codes. We’ll have to see what the net effect of this is but exceptions are slower than error codes when you have to deal with a lot of them.

There are pros and cons to this approach. Runtime errors of any kind can’t be “ignored” by failing to check an error code. You can ignore the exceptions but then your application will just crash or quit with an unhandled exception. Now you MUST write code to deliberately catch, and maybe ignore, whatever exceptions that get raised. Hopefully these all get well documented so you dont just use

Try
   // some new API 2.0 code
Catch exc as RuntimeException
End Try

I’d advice against a “catch all errors” kind of usage. You should never catch more than the errors you CAN actually deal with and let the rest bubble on up.

2019r2 is, for me, a mixed bag. Some welcome stuff. Some serious pain points. And some stuff that I have to just not use if I want to make code that still compiles in older IDE’s (which for some clients has to). There are things to like in 2019r2, and things that are going to make for a LOT of rework. For me there just arent enough nice things to warrant moving to it for my day in day out work at this time.

Your mileage may vary.