Xojo released a video today of Geoff Perlman talking about Xojo. This is mostly information that would have been given at the Xojo.Connect keynote address but, well, we all know that it isn’t normal times. I urge you to watch the video and come back. I won’t bore you with repeating what Geoff said but I’ll give some thoughts on each section.
Last 12 Months: Pretty typical recap of the last year.
In The Works – Big New Features:
Xojo Cloud: Makes sense to go to all 64-bit and to make them stand-alone apps. Having the built-in load balancer is really nice for those that don’t want to mess with it themselves.
Feedback: Web based. Yay! It’s about freaking time to get away from the stupid desktop app. I guess my question is will it improve the responsiveness of Xojo actually fixing bugs that are reported?
Web 2.0: Telling me you have great looking controls and not showing me anything to prove that makes me doubt the claim. Session restoring should be a nice feature assuming it works as required.
Really, you want to add 10,000 rows to a ListBox? I’d say that’s a bad example as that much data should be ‘paged’ but whatever. Users will do stupid stuff like that all the time.
What they didn’t say was that the conversion to Web 2.0 is a one-way trip. Make sure you backup your project before you do that.
iOS: Notifications, SearchField, Application Shortcut Items, Custom URL Schemas are all basic features and should have been in the product long ago.
iOS plugins will be good news for MonkeyBread and maybe one or two others. No idea if this means the plugins are still C++? I’d assume so but no details given.
Having String and Variant instead of Text and Auto is a good change. Mobile classes to replace iOS makes sense with Android sometime in the future. No timeframe makes it hard to guesstimate how excited anyone should be.
API 2.0: While it’s cool that a desktop, web, iOS, and Android projects can now use the exact same code it’s a shame that we can’t have all of those projects from a single project with different targets. I know I’m being petty but that seems like the next logical step.
Desktop Controls will be replaced to use the API 2.0 events. This is the way it should have been done from the beginning. It completely eliminates the train wreck that we all experienced with the now non-existent Xojo 2019 R3 release.
Android: The fact there’s an Android version of the Conference app in Google Play Store is a good sign that it’s coming along and fairly well advanced. Hard to say exactly how far along but is but still. The Android video should be interesting.
Graphics: Having XojoScript be able to do graphics is a really nice feature. I’d love to know what the refresh rate can be. I don’t have any idea on what I’d use it for, but I could see that being used to create control plugins made in Xojo.
PDFDocument: It’s a great beginning. I suspect that most people will be disappointed because it looks like it’s graphics only. Meaning that the PDF can’t be searched. I might be wrong but that will be the first thing that I’ll check. Without that it’s pretty minimal feature set and not what many people want.
Worker Class: A good discussion on why threads are hard and why using console helper apps makes use of multiple cores whereas a normal thread only uses one. Geoff might be using App.DoEvents in the only permissible place to use it but even then, I wouldn’t use it since too many people use it as a crutch and abuse it.
The Worker class looks really cool and is probably the best thing that Geoff discussed. I have many questions on how the class and its events work. For example the JobRequested and JobRun events only uses string. Is that the only datatype we can use with that? I suspect it is because it’s creating a console app in the background. Regardless, it really takes the work out of working with console helper apps.
Also no talk about what’s the preparation time. Would it be easier, in the long run to simply create your own helper console apps? My guess is probably but the details are important here.
Overall: It’s nice to see progress on things in the Xojo universe and a few surprising additions (Worker class). What we don’t know is when these things are going to ship (and be useable). The thing I could use today is the Worker class and I suspect that it will be the last thing introduced (sorry for being pessimistic). This has always been the most frustrating thing about going to XDC and being told about something really cool and then having to wait a year (or more) before we see it.
Last week Xojo 2019 Release 3.1 hit the internet. This small bug fix release is a critical update and is recommended if you are using one of several areas. Let’s get into the details.
One of my biggest issues of concern with API 2.0 is with a dangerous memory leak in the DatabaseRow class. Doing practically anything with a database would quickly eat of RAM until it brought your machine to its knees. R3.1 fixes this issue and also a memory leak when using ODBC.
A couple of iOS bug were fixed in this release. R3.1 fixes a regression that caused iOSTextAreas to overflow their bounds when the border was set to None or Regular. iOSView headers no longer show the previous view during the PushTo animation. Xojo added the Operator_Compare to the ColorGroup so that it can be compared against a color value.
A number of API 2.0 bugs (besides the database bugs noted above were fixed):
TextArea.SelectionAlignment now accepts enum values.
String.IndexOf now properly matches its signature when you leave off the startPosition but include ComparisonOptions or Locale.
If an empty name is used in the TimeZone constructor it will create an instance for the current timezone.
String.LastField now works
SerialConnection.Connect no longer raises an Error event. It now throws an exception as expected.
DateTime no longer reports a Nil TimeZone
In Windows, having multiple HTMLViewers on a window (or multiple windows) no longer continuously switches focus.
In MacOS setting FolderItem.Visible no longer inverts the visibility.
The Plugin SDK now lets you access the new API 2.0 string extension methods.
The burning question that everyone wants to know: Do I think that Release 3.1 is safe to use? The answer is a definite maybe. Let me explain.
I’m still not sold on API 2.0 being completely stable. A few additional bug reports were filed after R3.1 was released including a GenerateJSON bug with Variant arrays (Feedback 58940), and a DatabaseColumn.Value bug where value always returns a String value (Feedback 58934) where it should be bringing back the correct data type. Both of these bugs are marked as fixed and ready for 2020 R1. Unfortunately we don’t know when R1 will drop but if I was a betting person I’d guess sometime in March either the week of Xojo.Connect or maybe even later.
If you’re using Classic API then I believe R3.1 is safe(ish). I’ve experienced some oddities in the Constants Editor but I can’t replicate an issue where it reverts the value with no intervention on my part. The new ColorGroup Editor for iOS projects just seems sluggish but that may just be the result of the new ColorPicker. If you’re doing iOS projects you pretty much have to use R3.1 to stay up to date.
I have migrated a few projects to R3.1. A few that I’ve attempted have had compilation issues and I haven’t gone back to determine if they were plugin or code issues and frankly I’m not that big of a hurry to upgrade. R1.1 is still working fine for me and I don’t need the hassles involved with major Xojo upgrades.
So my advice is to test the heck out of your projects if you upgrade to R3.1. I say this every release (because its true) but if you’re using API 2.0 then massive testing is a necessity. I put it this way: do you want to bet your company and/or product on trusting a new API?
What is your experience with 2019 R3.1? Is it worthy? Are you holding back and, if so, why?
Xojo 2019 Release 2.1 hit the web today. If you are using R2 and any of API 2.0 this dot release is a must for you. I almost would have almost preferred this release to be called R3. The biggest change in Release 2.1 is that the API 2.0 events have been dropped from API 2.0 entirely. There are also quite a few other changes and bug fixes that might impact your projects too.
Removal of the API 2.0 events was a concession to the 3rd party Xojo market (myself included). There really was just no tenable way for Xojo developers to support both the old and new events simultaneously and after much lobbying and teeth gnashing they were removed.
If you had implemented the new Events the R2.1 IDE will rename them back to the old events. This is a good feature, but I’m always leery of the IDE changing code on me without my knowledge. I recommend making a backup of your project before using this release.
Not everything is perfect with API 2.0 as it’s still hard to provide backwards compatibility with versions of Xojo prior to R2.1. All of the new API 2.0 Properties and class Methods are significantly different and permanently change your source code that is not compatible with pre-API 2.0 versions of Xojo. To help with this Xojo has added a new compatibility flag under the Gear icon in the Inspector that works with classes and properties. You can check if the Object, Method, or Property is API 1 or API 2 compatible.
Really, these flags should be titled XojoVersion < 2019.021 and XojoVersion >=2019.02.1 to make it more clear. But in reality this means that a Xojo developer must be using Xojo 2019 R2.1 or better to take advantage of these flags. To be honest I’m still unclear on how these flags really work and the documentation regarding them is sparse.
Another change is a new menu option called Analysis Warnings under the Project Menu. This dialog lets you pick and choose which warnings to see when you Analyze your project. If you set “Item X is deprecated. You should use Item Y instead,” to false you will no longer receive the API 2.0 deprecation warnings. This is set to false by default so you won’t receive the deprecation warning unless you go looking for it.
The FolderItem class has new methods: CreateFolder, CopyTo, MoveTo, and Open that now raise exceptions.
Window.Controls is now Iterable and you can use them in a For Each Loop to iterate through all controls on a window.
The DateTime class now has an optional parameter that lets you specify the TimeZone.
There are ton of bug fixes. Here are some of the highlights:
The IDE no longer crashes on macOS 10.15 (Catalina) when clicking on a color swatch in the Inspector and then navigating to another control before closing the color picker.
RemoveAllRows no longer crashes the application under certain circumstances.
The Database Editor no longer throws exceptions when dropping table columns.
They fixed a number of memory leaks. This includes (but probably not limited to) ODBCDatabase when binding parameters to prepared statements, MSSQLServerDatabase when using Prepared statements. When database objects go out of scope or are set to nil.
There are numerous examples of Deprecations with Replacement warnings now working properly with various classes. Constants have been replaced with more enums and so on. There’s just a boatload things working better with API 2.0.
In general if you are already using R2 then you MUST upgrade to R2.1. If you’re not using R2 then I still suggest waiting for at least another cycle since more bugs will be found and probably a few more things tweaked.
If you feel like you’ve wasted your time with R2 I feel your pain. The whole R2 cycle was really long yet API 2.0 was rushed through without much thought about the existing Xojo community and ecosystem despite attempts at communicating this information. I just don’t see the benefits of disrupting the entire user base, 3rd party ecosystem, not to mention 20 years of documentation, internet search engine results and so on, for what, in my opinion, are arbitrary and meaningless name changes. Some of the name changes make little sense but that’s a different argument that I’ve made before.
Personally, I would have appreciated the approach that they took with the URLConnection class that replaced HTTPSocket. It was a new class and you didn’t have to use it. It is using the new style exceptions rather than relying on error codes and it is a complete break from the old class. They did this with DateTime and RowSet and I’m fine with those. But having FolderItem (and other classes) now doing double duty depending on *how* you create them is a long-term support disaster.
So there you go Xojo coders. Xojo 2019 R2.1 is out and it’s better than R2 and has major changes that make our lives a little easier. What are your thoughts about Xojo 2019 R2.1?
[Edit] Apparently the Analysis Warnings dialog is NOT new. I’ve just never noticed it and, until now, I guess I’ve never needed to care.
In my search for Xojo alternatives I was pointed to Lazarus https://www.lazarus-ide.org which is a cross-platform IDE that uses a Delphi-compatible language (i.e. object Pascal). I was pretty happy to see that it has a Mac version of the IDE and I will freely admit that I prefer to work on MacOS for a variety of reasons. Among them is usually ease of installation and Lazarus completely fails on this count in my opinion.
Let’s start with installation. The Lazarus website takes you to a SourceForge repository that has three downloads. fpc is the compiler, command line tools and non-visual components. fpcsrc is the sources of fpc and its packages and you need that for code browsing. And then finally there is the lazarus IDE itself with visual components and help files.
First issue is that none of the Package files are code signed which means you automatically have to work around Apple’s security. Not hard but still it doesn’t give you warm fuzzies right off the bat. I forget which step made me do this but I had to upgrade to the latest version of Xcode and install the Xcode command line tools.
Then there was the issue that the Lazarus downloads doesn’t included a Mac version that will run on newer Mac systems. So you end up going to the Free Pascal Compiler repo on SourceForge to get it to install.
Finally, you get to the point where the Lazarus IDE installs and then you get to the configuration screen. As you can the FPC sources can’t be found. But wait, wasn’t that part of the big three downloads I did to begin with?
In the long run no amount of reinstalling or internet searching could solve this problem. There does happen to be an entry in the ComboBox at /usr/local/share/fpcsrc and when you use that option a dialog warning you “Without the proper FPC source code browsing and completion will be very limited.” But it lets you ignore it and actually open the IDE. For now we’ll ignore that the debugger doesn’t appear to exist either.
A blank project appears including a blank form (Form1). The component library window is spread across the top of the window with 15 tabs to break it up. In the Standard tab double click on the TLabel adds it to the form. From there you can drag the control to the location of your choice.
Things go very downhill from here. The label is selected and the eight handles appear and the mouse cursor changes when hovering over them. One would think that you can simply grab the handle to resize the control. Alas, I could not with the label even though I could with the other controls. I couldn’t even change its width from the properties list.
The properties list is pretty standard. All of the properties are listed in alphabetical order which I can live with but I definitely appreciate the grouping that Xojo does (although I still prefer the older Real Studio properties list to the Xojo Inspector). Logical groupings make life easier in a properties list.
A tab control on the properties list also shows the available events for the control. If you click on the right side of the event I immediately get an error “Error: include file not found ‘typshrdh.inc'”. Um…sure. Anyway, at this point I can’t do much more without getting these setup properly.
After spending a couple of hours over the course of three days I’ve given up. My Google-Foo is pretty strong but I keep getting nowhere. The directions I’ve found are pretty minimal and I’ve done what they say I should be doing to no avail.
All of this tells me several things. The lack of documentation, particularly for MacOS, tells me that that it’s not well maintained for MacOS and I don’t think it’s used by Mac developers very much. And this is long before I get into evaluating the language and libraries that are available for it.
For ease of installation and getting that first Hello World application up and running Xojo is by far the clear winner. Look, I don’t expect an open-source project to be as easy to setup as a commercial tool so perhaps it’s not a fair evaluation. But it is one of my criteria because I have clients that take over development of their projects after we do the initial work. So if I’m having these types of problems I can’t imagine a less skilled developer having any less.
If you’re using Lazarus on the Mac I’d love here from you. Drop me a line at firstname.lastname@example.org and perhaps we can get me past this hurdle so I can do a real evaluation of the tool.
Xojo 2019 Release 2 arrived this week, and to say that this is a massive release would be an understatement. Among a large number of bug fixes and IDE enhancements is the first release of API 2.0. With every release I say that you should test your projects thoroughly, but in this case it needs to be mandatory.
API 2.0 is Xojo’s latest attempt to make the framework consistent across all the classes and should be easier to learn and use than the old framework. The properties, methods, and event names of practically every single class have changed. Some have changed in subtle ways, and others in a bash you over the head fashion. What might be even more important is that classes that used to set an error bit or error code will now throw an exception.
Some of the most basic things in Xojo have changed. Declaring a variable has changed from using the Dim keyword to the new Var keyword. Declaring an array is the same but resizing it is now accomplished like this:
//Declare the array
var arNames() as string
//Set it to a new size
//Clear the Array
Every Window and Control that comes with Xojo 2019 R2 has new events. Open, which admittedly can be confusing, is now replaced with the equally confusing Opening event. Close is Closing and so on. I have yet to find any direct mapping document of old events to new events and that’s a crime.
A complex control like the Listbox has dozens of events, properties, and methods and nearly all of them are renamed. Some make sense. ListBox.ListCount is now ListBox.RowCount. But ListBox.EditCell is now ListBox.EditCellAt. To append a row to a Listbox you still use ListBox.AddRow, but to insert a Row you substitute ListBox.InsertRow with ListBox.AddRowAt. I simply don’t see why AddRowAt is easier to remember than Insert (I could argue that InsertRow makes more sense).
Some changes I strongly disagree with. For example, Arrays in the old framework were simple enough to add items to:
dim arMyArray() as integer
arMyArray.Insert 0, 2000
With API 2.0 the Append and Insert methods are replaced with AddRow and AddRowAt. Again, one can argue that removing Insert and replacing with AddRowAt is simply a poor use of the English language.
Pre-API 2.0 Projects
The good news is that existing pre-API 2.0 projects will work with only a few modifications. In our projects (Task Timer, Shorts, ARGen) there were little to no changes required to get them to compile in R2. And the good news is that you can continue to use the old API in R2. The Code Editor AutoComplete will show you the old API and the new API with the old API call in Red and show you the new API 2.0 method or property.
Starting a new project in R2 will only show you the new API and events. Certainly one of the drawbacks is that Xojo projects created in R2 are not backwards compatible. Xojo has never really guaranteed that newer versions would be compatible and this is one of those cases where it’s simply not possible (theoretically if you never implement any events it will work).
My advice: Treat R2 with kid gloves and make backups of your project files before you play with it.
Let’s talk about events for a bit. I’ve already hit on the Open event that is replaced with Opening and Close that is now Closing. I find nothing wrong with the new event names, per se, but anyone with an older project, or someone taking an older class and putting it into R2 must be extremely careful. The old Open and Close (and other) events will fire as expected – until someone implements the new API 2.0 event like Opening. Once you do that the old event no longer works. This has the potential of really messing with legacy products that use the old Events and new users not knowing the difference and implementing new events and crushing functionality.
Frankly I find events to the most problematic part of API 2.0 since I, as a provider of 3rd party code, can’t enforce that a Xojo developer use the new or old events. It’s going to be a nightmare for the next couple of years (maybe forever?) as new people find old classes and implement them in their new R2 projects. Events cannot be coded out with #if statements. There is simply no way to control which events to use in a mixed environment.
If you’ve created your own control subclasses with custom events let’s hope you don’t have naming conflicts with the new event names. The only way to solve this is to change your Event definitions in a pre-API 2.0 version of Xojo.
Despite being a great idea, the Text datatype from the Xojo framework never really caught on. As part of API 2.0 many of the Text methods have been brought to the String datatype. As with all the other classes nearly every method and property name has changed in some way, shape, or form.
The biggest change, and perhaps the most problematic, is that the string functions are now zero-based. The first character of a string is zero and no longer one. The InStr method has been replaced with IndexOf (bad name in my opinion) and instead of returning a zero if the search string is not contained it will return a -1. Don’t get me wrong, this is a good change in the long run, but when developers are converting their projects from pre-API 2.0 things like this are going to bite a lot of developers as it’s not a direct replacement. You can’t just simply use IndexOf to replace InStr because it will break your code. Expect some grumbling about this from the greater community.
Date and DateTime Classes
Xojo has deprecated (not removed) the existing Date class and has created a new DateTime class. This is mostly a rehash of the Xojo.Core.Date class but it uses Strings. The new DateTime class is not a direct replacement for Date since the DateTime class is immutable. In effect if you’re doing any sort of date math you’ll need to use the new DateInterval class. The DateTime class also does not have TotalSeconds but instead has a SecondsFrom1970 property. To get a New DateTime you use the Now shared method instead of creating a new instance of it.
The FolderItem class was significantly updated on macOS and uses Apple’s more modern API’s. This should make file operations significantly faster on newer versions of macOS. FolderItem.AbsolutePath has been removed (it’s been deprecated for a while now).
Because of these changes you really need to be careful with URL Paths with query parameters. The behavior between R2 and earlier versions of Xojo has changed significantly.
The database classes have some welcome changes that have huge implications. Besides new classes, methods, and properties for everything to do with the database, any interaction with the database has the potential of throwing an exception. In the old API you had to explicitly check for the Error property. Now it will throw an exception that you have to capture and handle. This is both good and bad.
With ActiveRecord and ARGen we’ve been throwing exceptions for years when we found the database error property to be true. So not a big change for us, but for anyone that’s ever checked to see if a RecordSet is nil will be surprised when the exception is thrown. This is guaranteed to get your attention (many people never checked for the db error anyway!) but it will be a pain for many developers. Database code will need to be in a Try-Catch block, and doing this in a proper Transaction will cause some structural changes to your code.
RecordSets are deprecated. Long live the RowSet! RowSets are returned from Database.SelectSQL and instructions are passed through Database.ExecuteSQL. This is in contrast to the old SQLSelect and SQLExecute methods respectively. I can guarantee that I will mix the old and new versions up for many years to come.
PreparedStatements are no longer needed as they are built-in to the SelectSQL and ExecuteSQL statements. You no longer have to Bind the DataType and Value as the class does it for you. This is similar to what iOSSQLiteDatabase has done for years and hopefully this gives everyone more incentive to use them. PreparedStatements were a pain to use and this new method is considerably more streamlined.
One word of caution to anyone that uses the MBS SQL plugin: You must update to the 19.4 version as the database class changes required the plugin to be updated. Older versions of the plugin will fail silently and may cause other plugins to not load properly.
URLConnection received some updates. In Windows 7 and 8 it picks up proxy settings. It also no longer hangs a Windows application when downloading large files or content. In Linux a ResponseHeader that no longer exists doesn’t crash the application. They also made the ResponseHeaders an iterable function allowing the use of For-Each loops.
They (finally) added BeginTransaction to the Database class. It’s silly that this hasn’t been part of the framework for the past decade.
The Code Editor received some interesting changes. Pressing Shift-Return on an existing If-Then or If-Then-Else will now break the statement into multiple lines. On a comment line holding the shift key and pressing Return automatically adds another line of comment.
The Layout Editor has some changes too. It now has a control to switch between Light and Dark modes.
There is now a number of new Refactoring Tools available and they fixed a number of bugs in the refactoring tools. They added a new code assistant for wrapping the selected code in an #if XojoVersion block (handy with all the new API 2.0 changes). The Add Event dialog has been updated to allow adding deprecated events when a checkbox is selected (deprecated events are in red). In the same light you can right-click on an event in the Navigator and choose to convert it to the newer API 2.0 event.
The FileTypes editor and Associated File Types editor have been combined into a single editor. File Type Roles have been renamed to None, View, Edit, and Execute. For MacOS you can set if the File Type is unique to the application.
Catalina may force many developers to upgrade sooner rather than later. The SelectColor function was updated in R2 to no longer use an outdated API function. Using SelectColor with an app built before R2 will reliably crash on Catalina. The only solution is to build with R2 or use NSColorPanel yourself with declares or the MBS plugin.
Maybe I’m just an old school person and a curmudgeon but I find the lack of Old to New documentation extremely disappointing. Xojo has a Deprecated list at https://docs.xojo.com/Category:Deprecated but I find it worthless. I’d like to look at a single class at a time and have all of the events, properties, and methods showing the old name and then the new name along with any comments. I realize this is a lot of work but I’m surprised that Xojo didn’t create this documentation BEFORE doing any coding to use as their coding bible.
Any old example, sample project, old forum post, Google search result is now obsolete. BKeeney Software’s 65+ hours of Xojo training video that covers a good chunk of the Xojo framework is now practically worthless. I will be shutting the doors of the training site because it’s not worth my time (at this point) to redo over 200 videos. Xojo needs to convince me otherwise.
Deprecation Items That Have a Replacement
The Xojo IDE tries to be helpful in converting your projects to API 2.0. There will probably be a handful of things that will flag compiler errors in your pre-API 2.0 projects. If you Check your project you will get a rather large list of items that are deprecated that have a replacement. This list can be overwhelming and I recommend NOT doing global search and replace on these items because the code is sometimes quite a bit different. Good luck!
If you have an existing project I would be very carefully with R2. Sure, try it out on a *copy* of your project, but don’t expect to use R2 right away. I’m almost sure that there will be changes to fix bugs and strong community objections to certain things. We already know that Reporting and XML was NOT done for R2 and I’m sure we’ll find other things along the way too.
For developers using R2, please be patient. Get used to the question: What version of Xojo did you start with? The community is going to struggle with the changes for a while and we have no idea that his means.
All in all I think there are some good changes to Xojo 2019 R2 but I also think that there was a lot of change merely for the sake of change. I’m not convinced that all the changes were for the better. But really, only time will tell.
IDE received quite a few tweaks
Lots of bug fixes and enhancements
API 2.0 is mostly consistent with naming (with some oddities for sure)
Lots of bug fixes and enhancements
Exceptions now thrown instead of having to check for error codes
FolderItem significantly upgraded for macOS
DateTime added as a replacement for Date class
API 2.0 is not entirely done yet with more changes to come
Change for the sake of change in some cases
Exceptions for common and expected errors is not ideal
New String methods are not drop-in replacements because they are zero-based
API 2.0 event handling prevents API 1.0 events from being raised
Documentation woefully incomplete
All existing documentation, examples, videos are obsolete
What topics would you like for me to talk about with API 2.0? What do you like and dislike about API 2.0?
Markdown is a popular text formatting syntax in use all over the web. Markdown was designed to be human readable in plain text, and formatting parsers are available for many different formats.
There are a few different parsers for Xojo, available in both add-on and plugin format. Garry Pettet provided MarkdownKit for us to look at and review. MarkdownKit is written entirely in Xojo code, is fully CommonMark compliant, and generates HTML.
MarkdownKit is implemented with both String and Text versions, and is designed for both Desktop and iOS projects. MarkdownKit is provided as full source code, and includes documentation as well as examples.
With everything provided, MarkdownKit is very easy to use. It really is as simple as one line. dim sHTML as String = MarkdownKit.ToHTML(SomeMarkdownString) The output can then be passed into an HTMLViewer and displayed. This can all be done so fast you get near live rendering.
The way MarkdownKit renders the input is impressive. A MarkdownKit document is parsed into a syntax tree so that an implementation of the rendering interface can walk the document. What we get from all that is a fast and accurate Markdown renderer. And wow is it fast. The demo application really illustrates the speed of MarkdownKit.
Overall MarkdownKit has proven to be speedy, well documented, easy to use, expandable, and CommonMark compliant. MarkdownKit is a great Markdown renderer written entirely in Xojo code. If you don’t yet have a Markdown renderer in your toolkit, MarkdownKit is a solid option.
A dot release for Xojo 2019 Release 1 was released today. Xojo 2019 R1.1 has several significant bug fixes. This release is highly recommend for all users.
Perhaps the biggest bug fix is related to ListBox.CellbackgroundPaint and Listbox.CellTextPaint events. They no longer leak memory 64 bytes of memory each call.
In Windows URLConnection received some attention. They sped up socket requests and decreased the CPU usage. Authentication no longer hangs when there is request content present. The events for URLConnection are no longer re-entrant. This is fancy way for saying that some events, like PageReceived would get called a lot rather than just once and could cause some issues depending upon usage.
Changing the case of label now changes the text in Windows. For example if you set the label1.text = “lower” and then tried label1.text = UpperCase(label1.text).
Also in Windows, TabPanels embedded within another TabPanel no fires the Changed event multiple times.
One new thing made it into this build. iOS projects now add default plist entries for NSLocationWhenInUseUsageDescription, NSLocationAlwaysUsageDescription (for iOS 10) and NSLocationAlwaysAndWhenInUseUsageDescription (for iOS 11+). These can be overwritten by user plist files.
I am glad to see this dot release version of Xojo. I know we like to beat up on Xojo Inc for various things but I think they generally do the right thing for the community.
Xojo 2019 R1 was released today. This is the 2nd release in a row where there is not a dramatic number of new features but quite a few bug fixes and enhancements. Let’s dig into what’s changed in this release!
The big change in this release revolve around the URLConnection control. The HTTPStatusCode property is now available for both the Send and SendSync calls. The control now appears in the library. It now yields to other threads. Send requests are now closed before the ContentReceived and FileReceived events are fired. The string encoding for the ResponseHeaders is now consistent across platforms. It also now automatically handles compressed content-encodings in Windows and Linux (just like MacOS does). The TimeOut property now works (before it always did 30 seconds). Error messages are no longer empty in Windows. The ReceivingProgressed event now correctly reports the total bytes. The response headers are now updated property when a request is made. The SendSync no longer intermittently returns empty strings in MacOS.
The licensing has changed for Raspberry Pi. The license for Desktop and Console applications on the Pi is now free!
There are some other new items. The list is small but significant. The first is that 32-bit Windows builds can now set HiDPI and supported versions properties in the manifest file.
The TextArea control for Windows 8 (or newer), and Linux now support system spell checking. This matches the behavior on MacOS.
The Text datatype now has target appropriate EndOfLine properties. If you use Text you’ll no longer have to create your own EndOfLine constants.
The IDE added the ability to switch between Computed Properties and manual Getter/Setter methods. There is a new menu item when right-clicking on a property. In addition to the standard Convert To Computed Property there is a new menu item called Convert To Method Pair which creates two overloaded methods. For example, if you have MyProperty as Integer and select the Convert to Method it will create one MyProperty method that returns the integer value and another overloaded method that accepts an integer value with an assigns. So it looks like to consumers of this property as if nothing changed.
The constants setting has been changed from Dynamic to “Localized.” This creates a new grouping in the Code Editor called “Localized Strings”. It’s still a constant but it better reflects that it’s localized and should make it easier to visually see if a string is localized or not as there was no easy way to tell before.
There are 25 changes and 162 bug fixes for Xojo 2019 R1. Here are what I feel are the significant items:
The ODBC Database plugin now works better with 64-bit builds. Date fields in MacOS now work properly. In 64-bit Windows updating a binary/image column no longer fails with an invalid precision error.
The MySQLCommunityServer plugin no longer crashes when has certain field types and originated from a PreparedStatement.
The SQLiteDatabase no longer crashes when out of memory situations arise – an error is now generated.
Calling an OpenDialog from within a thread now properly raises a ThreadAccessingUI exception. I’m actually surprised that this wasn’t flag a long time ago.
StringShape rotation is no longer incorrectly offset. The original Feedback report was for Linux but it appears this affected other targets too.
The Window/Canvas Backdrop picture now draws correctly in HiDPI. This doesn’t affect me directly but this is the first time in several years where Canvas drawing in Windows seems really solid. I’m in testing right now with a client app that had been held back in 2017 R2.1 because of Windows drawing performance.
GroupBox caption in Windows now properly draws the size, bold, italic, and underlines styles instead of ignoring them.
A bunch of work was done in the Code, Constant, Layout, and FileTypes editors. The Inspector and Library received a little love too.
So far I’ve found this release to be solid and the major updates to URLConnection now appear to make it worthy of investigation. I’ve not used it enough, yet, to recommend it but I think most of the major bugs are worked out. The number of bug fixes and enhancements makes R1 a worthwhile upgrade.
I think this version is worthy of your time and effort to try out. As always, you should really test Xojo out on your projects, in all targets, to make sure it works as expected. Some of the bug fixes in this release might mean you have to get rid of some workarounds you’ve come up with (thinking of the StringShape rotation fix here).
Let’s hope that the major new features (like API 2.0, Web 2.0, and Android) can be staggered so there there isn’t a flood of new things in a single release. Too many new things makes it hard on beta testers.
Have you found any showstoppers? What are you most happy about in this release?
Xojo 2018 Release 4 hit the internet this week. This relatively small (84 bug fixes, 21 changes, 5 new items, and 11 doc and example changes) update is a nice end of year release that may or may not satisfy your Xojo dreams. Let’s get into the highlights.
Of the new items list the big one is the new URLConnection class. The URLConnection class works with the HTTP 1.1+ protocol and works with http and https connections. This is a replacement for the Xojo.Net.HTTPSocket and brings back one of the things many developers missed about the old HTTPSocket class – Synchronous communications – using the SendSync method.
SendSync is a concession by Xojo with the caveat that the application may appear to freeze while running this method. The regular, and probably the better, Send method is asynchronous and does not freeze the app. Admittedly the async way is the better way but for many developers the synchronous method is easier to implement and ‘good enough’ for their use. Still, consider using the async method.
The Screen class now has the ScaleFactor property. There are two new global constants: AppSupportsDarkMode and AppSupportsHiDPI that are pretty self explanatory.
iOS builds now use the iOS 12.1 SDK. macOS builds now use the 10.14 SDK for 64-bit builds.
There are couple of changes that are noteworthy. The first being that the Windows IDE can now successfully build large projects for Linux 64-bit and ARM targets (frankly I didn’t know this was a problem but I bet that ‘large’ is the key word). Any remaining threads are now killed after the app.close event (possibly a reason why some apps in macOS crash after they quit?). EnableMenuItems no longer fires needlessly on every keypress in Windows. Lingua and Remote Debugger Stub have been updated to work with Dark Mode on macOS.
There are 84 bug fixes in this release. The more important ones (at least in my opinion): The Build folder is properly emptied between build runs. Remote Debugging to a Raspberry Pi no longer randomly crashes when stopping at a breakpoint. Browsers that have disconnected from the web app will now reload the web app so they don’t appear frozen. There are also a couple dozen IDE bug fixes to the Inspector, Navigator, Find & Replace and a number of the editors.
As with any new release you need to thoroughly test your projects before doing a public release. It was noted during the beta period that the Einhugur Search Control didn’t work properly in Mojave but has since been fixed. We had one large project not work when remote debugging from Mac to Windows but I haven’t had time to track it down. If you have found any new issues with R4 please submit a Feedback report right away!
Xojo 2018 Release 2 is now available.This release is heavy on fixes with some for the IDE, for Windows, Linux, and some new features for iOS.
In iOS, the iOSTable now supports Pull-To-Refresh.iOSTable now does a better job with variable height rows by setting the UseDynamicHeight property and lets the row height be determined by the content of the cell.The inserting and removing of rows and sections is now animated if they are in the visible section of the table.The IOSHTMLViewer is now using WKWebView instead of UIWebView.A fix to the AutoLayout editor now tries to keep you from making constraints that could cause crashes.
Windows received a ton of love in this release but the biggest change is related to drawing.Xojo 2018 R1 introduced a new way of drawing in Windows that effectively eliminated flicker but it also severely limited the speed of drawing.R2 appears to have mostly fixed this issue by calling additional Paint events rather than caching pictures.As always you should test the Windows versions of your apps to see if the drawing speed is acceptable for you. Many of the old ways to eliminate flicker actually make drawing really slow now so test, test, test!
Besides the drawing issues there were plenty of other Windows changes as well.Printing in no longer limited to 96 DPI.BevelButton, HTMLViewer, Listbox, Xojo.IO.TextOutputStream/BinaryStream, Xojo.Net.HTTPSocket, Sliders, Object2D, OpenGLSurface, ContainerControls, and TabPanels were all touched in this release.
Linux and Raspberry Pi wasn’t ignored in this release either.BevelButton, Listbox, HTMLViewer, and GroupBox received updates to fix various bugs.Of note, the HTMLViewer on the Pi no longer hard crashes the application.
A change that could affect some people is that Graphics API now takes Doubles instead of Integers for better precision.It probably won’t be a big deal for many developers but you will definitely want to try your drawing in non-HiDPI and HiDPI modes to see if anything has changed.I did a quick test with Shorts, Formatted Text Control, and Tab Control and didn’t notice any drawing glitches so it’s possible that the average developer will be unaffected by it.
Another graphics change is a new AntiAliasMode property that controls the quality level when drawing scaled pictures.There are three modes:Low, Default, and HighQuality.Default Quality, I think, is simply what we have now.The documentation (AntiAliasMode is missing from the built-in documentation but is online) is unclear as to how Default compares to Low and High Quality.Testing should reveal this.Also unclear from the documentation is how this affects speed but one can presume that High Quality will be a little slower but I have not tested this.
There are two new functions added to the SpecialFolder class.The new Resources function returns the appropriate platform specific resources directory if it exists.The new GetResource takes the passed in name and returns the file (if found).Neither of these new functions are found in either the built-in or online documentation.
As always please review the Release Notes to see if anything affects you or interests you.
Documentation and examples are one of those things that no one likes to do.But given the audience that Xojo caters to (the Citizen Developer) I am always amazed that things that are added to the framework often don’t have an example project.I might be wrong (because I didn’t check every single example) but the new IOSTableRefresh and new animations don’t have an example project.Nor is there anything for the new AntiAliasMode.
The new SharedFolder.Resources and GetResource methods aren’t in any of the available documentation (other than release notes) but at least Resources is used in the SpecialFolderPaths project.However, that example isn’t listed in the Release Notes as being changed.
The documentation not being available at release is simply unacceptable.Each new feature should have an easy to find example project demonstrating its use (preferably available during the beta period too).I also recommend having a folder for each version that has shortcuts to all of the examples that are new or modified for the current release.Every release this list changes so the examples list doesn’t get loaded up with folders from old releases.Regardless, I’m very disappointed the documentation in this release.Xojo needs to do better.
Anything in this release that you’re happy, or unhappy, about?