Xojo 2018 Release 2

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?

Xojo 2018 Release 1.1

Xojo announced the availability of Xojo 2018 Release 1.1.  This ‘dot’ release fixes a couple of glaring bugs that were introduced in 2018 Release 1.  Some of the more important fixes:

  • A NilObjectException caused by an undo in the IDE has been fixed.
  • A regression in the debugger kept some 32-bit breakpoints from working reliably.  The debugger now stops at breakpoints correctly in 64-bit and ARM targets now too.
  • In Windows, if you have a global variable it can now be viewed in the variables pane.
  • The Printer graphics.clip method now works as expected.  If you printed a Shorts document in Windows you would have run across this bug.
  • A host of Windows framework bugs were fixed.  TabPanels now draw properly with proper backgrounds.  TabPanels that contain sliders and scrollbars that caused the tabs to scroll off the TabPanel is now fixed.  The Canvas control now properly refreshes after Scroll is called.
  • iOS projects now compile when it has a launch screen with an image that has no actual pictures in the image.

If you are experiencing any of the issues listed in the release notes you should update to R1.1 immediately.  It’s a shame that it took Xojo nearly a month to get this release out the door.  I realize that XDC causes a huge disruption to their development schedule but the wait for this dot release was too long.

For those of you doing a lot of Windows development, are you still experiencing drawing/speed issues?  Or, have you determined the secrets behind making things better/faster?

Xojo 2018 R1

Xojo 2018 R1 was released today.  It’s been over four months since Xojo 2017 R3 was released in December of 2017.  By any stretch of the imagination that’s a long time between updates.  Let’s start with the big ticket items that you’ll be relatively happy about.  2018 R1 has a ton of bug fixes, enhancements, and new features.  

Windows users will find things to be happy about as Xojo has gone way out their way to reduce flickering issues in the Xojo IDE and in our own built apps.  The magic behind the scenes is not that Xojo is using double buffered windows (or anything like it) but they are now freezing drawing in the window while it’s doing things in the background.  Thus the flicker is gone but at the price of speed.

If you’ve spent a lot of time working around the limitations of control flickering in Xojo, your upgrade to 2018 R1 won’t be a walk in the park.  A number of forum users have done considerable work figuring out the best way to get things to work well together.  The basic premise is that everywhere there is a Transparent, DoubleBuffer, or EraseBackground property you should turn them off.  I’m sure in the upcoming days a more thorough explanation of the best practices will turn up on the Xojo forums.

One thing that might really turn developers off is Feedback Case #51337 where Labels look ‘fuzzy’ and not acceptable to many end users.  This appears to be caused by the difference between the Direct2D drawing engine and the old GDI engine.  Before jumping into 2018 R1 you might want to do some testing to see if this is acceptable to you.

Printing in Windows appears to be better now as you can now print with higher resolution than 96 DPI.

The other big Windows feature to make it into 2018 R1 is the ability Debug and Remote Debug 64-bit Windows applications.  This is a big deal and required that Xojo upgrade the compiler to LLVM version 6.

In late beta testing I had issues with the Remote Debugger (from MacOS to Windows) not dropping down into the debugger and AutoComplete sometimes not working but those appear to be fixed just before the final release.  If you run into issues with either please report them as soon as possible!

The EraseBackground property is now gone for Canvas and Container Controls.  Container Controls have a new DoubleBuffer property that composites the control on Windows and allows for moving/scrolling controls with less flicker.

The Currency datatype is working properly again in 64-bit builds.  In previous builds the Currency comparisons didn’t always work and precision was lost when dividing Currency values.

A host of Windows framework bugs were fixed in the Listbox. The Val function in 64-bit Windows builds now returns appropriate values.  BevelButton captions and menu arrows now work properly when the DPI scale factor is greater then 100%.  Graphics TextUnit.Pixel is no longer treated as Point sizes when the DPI scale factor greater than 100%.  Please see the Release Notes for a complete list of Windows framework changes.

The Web framework received some love too.  The WebFileUploader control works with files greater than 2 GB in size and works with files with ampersands and apostrophes in their name.  It also supports drag and drop and now has a new UploadProgress event.  It also supports file multi-select to allow users to select more than one at a time.  It also has a CancelUpload method and a new UploadTimeout property.

The WebMoviePlayer now uses a native HTML5 video player on supported browsers (I believe this means all of them) and now has a separate Stop method.  Internet Explorer 9 support was removed.  WebMapViewer only calls into the Google Map API once per browser session.

The SQLite library was updated to version 3.22.  One of the big changes is that errors when creating SQLitePreparedStatments now get a more meaningful error messages versus the unhelpful ”unable to prepare” message.  SQLiteDatabase now supports AES-256 encryption.  The SQLiteDatabase now yields to other threads when it’s busy performing a long operation and using the ThreadYieldInterval property.

For many users the upgrade to 2018R1 will be a no brainer.  However, those that have a complex UI should do some testing in Windows to ensure that drawing speed is still acceptable.  Some beta testers found that the tradeoff of being flicker free was not worth the slower rendering speeds.

The Debugging of Windows 64-bit applications is a much needed and welcome feature.  Without much time to see it working (properly) I can’t give much of an opinion of it.  The compiling speed of 64-bit apps is very slow and it appears that incremental compiling is off.  I would expect the entire process to get better over time.

With this major milestone out of the way I hope we see considerable progress on Interops, creating plugins from within Xojo, Android, and Web 2.0 in the next couple of releases.  I’m sure we’ll find out more next week at XDC.

What excites you in 2018 R1 and what gives you some concerns?

Xojo 2017 R3

Xojo 2017 Release 3 is now available.  As with all Xojo releases there is a mix of new features, big and little changes, and a host of bug fixes.  I’ll highlight some of the big items.  See the release notes for the complete list.

Perhaps the biggest change in Release 3 is that this is the first release where the IDE itself is 64-bit.  For macOS this is the only option.  In Windows the installer will choose the proper version for you system.  For Linux, the IDE is only 64-bit and will not run on 32-bit systems (note that it can still created 32-bit executables).

This is a major milestone for the Xojo IDE and is the culmination of many years of hard work by the developers.  It’s hard to imagine the work involved in taking a large product, like the Xojo IDE, that once assumed everything was going to be 32-bit only and rewrite practically every class, method, and function to ensure it works properly in 32-bit and 64-bit on Mac, Windows, and Linux.

So what is the deal with 64-bit? It lets the IDE use a lot more RAM.  In Windows especially this has been a limitation.  Some processes in the IDE, and in our built applications might be faster (emphasis on the might).  And since most computers are shipping as 64-bit these days it seems archaic to keep using 32-bit applications and in some cases for Linux it’s really hard to run 32-bit apps on a 64-bit machine.

One thing that changed because of the move to 64-bit is that the IDE Auto Saves the project before a debug run in a different way from previous versions.  Prior to R3 it used memory blocks to save this data in temporary files in case the IDE crashed.  In R3 it still saves but it’s using a much slower method.  It’s a long and drawn out explanation but it’s because of memory fragmentation that can happen even in 64-bit builds.  On very large projects this can take a LONG time and can make the IDE look like its stuck since there is no visual feedback of what it’s doing.

If this is a problem for you there is a way to get the IDE to NOT AutoSave the project before the Debug Run.  Warning:  This is for advanced users that understand the implications of doing this:

Confirm that Xojo is closed. You can set ‘Autosave Allowed’ to false the following ways:

macOS:

Edit the Xojo Preferences ( ~/Library/Preferences/com.xojo.xojo)

Add a key with either a true or false value

<key>Autosave Allowed</key>

<false/>

Linux:

Use the same key entry style as macOS inserted in ~/.Xojo.Xojo

Windows:

Use regedit to edit HKEY_CURRENT_USER\Software\Xojo\Xojo

Add a new DWORD value with the name “Autosave Allowed”

a value of 0 is false

a value of 1 is true

Another issue for 64-bit builds is the Currency data type.  According to long time Xojo developer Kem Tekinay using Currency is not recommended in 64-bit builds due to comparison issues.

The IDE now cleans up properly after a debug run.  This should eliminate the issue with the IDE showing a file IO error when trying to do multiple debug runs.

Layout Editor

Dragging IDE windows around with thousands of controls on the layout renders better now.  It is still recommended that you use container controls to limit the number of controls on each window.

Report Editor

Fonts on reports, especially in 64-bit builds, are now rendering at the proper size.  The Report Editor now honors locks as it should.

Code Editor

The Code Editor now highlights the lines of code blocks.  I’ll be honest, this is a totally unnecessary bit of fluff in the code editor but after using it for a few weeks I find that I like it.

The Automatic Code Reformatting now takes effect when you click away from the line of code.

Remote Debugger

The Remote Debugger Stub was rebuilt using 2017 R2.1 and thus has a speed boost.

The Mac Remote Debugger is now 64-bit and can run 32-bit applications as well.

64-bit and ARM Console debugger stub’s are included.

Lingua

Lingua now has a scripting folder where you can run XojoScript to manipulate the translated text.  This is really useful in post-processing where if your translator puts quotes around everything, or likes to put the source and translated text together.  Presumably an enterprising developer could use XojoScript to connect to a translation service.

ARM

XojoScript now works on Linux ARM builds.

Windows

64-bit Widows apps now display manifest settings in the advanced tab of Windows build settings.  This allows you to set Windows versions and privileges for your app.

iOS

Support for iOS 8 and iOS 9 has been dropped.

Xcode 9 is now supported as well as 64-bit debugging.

Web

Internet Explorer 10 support has been deprecated.

A number of bugs in the Web framework have been fixed.

Conclusions and Opinions

All-in-all, this release is an important one since the road to 64-bit has been a long and arduous process.  Xojo Inc. has missed on a number of promised deadlines this year and while some of them were under their control – many were not.  Let’s hope that 2018 is much kinder to their schedule.

I would expect the slow Auto-Save that popped up with the 64-bit IDE to be addressed at some point.  One personal opinion on this that irks me is their temporary fix for ‘advanced’ users.  Come on.  Really?  Stop treating us like children.  I don’t know about you, but in my 16 years of using Xojo I’ve only tried to use the AutoSave feature a handful of times and I can only think of one case where it actually saved me any time.  Keep in mind that you might very well never experience the issue if your project is small but I tend to have big projects and it’s a noticeable lag.

I did not like code block highlighting in its debut.  I felt that it was a complete waste of programming time.  After using for a few weeks it’s not that bad but I’m not sure it’s all that useful either.  I suppose if you have have six or seven layers if nested code it can be helpful but I tend NOT to do that.  It also might be really helpful with really long methods, and again, I tend not to do more than a page of code (I hate scrolling).

As with all Xojo releases it’s important to test your projects to ensure everything works as you expect.  I would expect a few things to shake out of the 64-bit IDE as more developers bang on it.  Xojo is a big project and the beta testers (myself included) can’t hit every single feature.  I’m not sure if I’d expect a dot release from R3 but I also wouldn’t bet against it.

Give me your thoughts!  Do you like R3?  Is it stable and reliable?

Xojo 2017 R2.1 and Updated Roadmap

I’ve had a hellacious travel schedule the past six months so I apologize that I’ve not been up to snuff on Xojo news. Last week Xojo 2017 Release 2.1 was made public and earlier this week Xojo CEO, Geoff Perlman, penned a blog post about the short-term roadmap for Xojo. Let’s dig in!

First, the 2.1 release has a mere 16 bug fixes in it. This dot release fixes some critical Linux, and Windows bugs. A few IDE bugs were addressed and the PostgreSQLDatabase plugin was updated. Many of these bugs won’t affect everyone but it’s definitely worth upgrading from R2 if you have not already done so.

Now on to Geoff’s short-term roadmap. You can read the entire blog at https://blog.xojo.com/2017/09/19/the-short-term-xojo-roadmap/. To summarize it in a nutshell: 64-bit is taking them longer than expected.

To this I say, ‘Duh’. Anyone who expected 64-bit to be done by this time hasn’t been around very long. Xojo has consistently blown their estimates for most (all?) of their big projects. The transition to Cocoa from Carbon took a lot longer than originally announced. iOS took longer than expected. The introduction of the Xojo IDE from the Real Studio IDE was also delayed (as a side note I’m still amused at the accusation that I personally caused a 6-month delay in the Xojo IDE due to a blog post).

The point isn’t, ‘Oh my gosh, Xojo has yet another delay’ it’s that Xojo is very bad at estimating this stuff. Some of this is on them but some of it is beyond their control. Supporting mac OS, Windows, Linux, iOS, Raspberry Pi, desktop, console, and web apps is a mammoth undertaking. I am constantly amazed at the magic Xojo performs without my knowledge. To me it ‘just works’.

Apple, bless their hearts, changes things on a whim every year at a minimum (sometimes even more often than that) and causes Xojo to play catch up. And they usually do this with little notice. The current change being that the iOS Simulator will no longer support 32-bit apps so guess who has to scramble to make it work now?

Linux distributions seem to change daily. Xojo has to scramble to catch up with those changes too. They recently updated Xojo to use GTK3 and that was a big deal. They sort of had to do this upgrade because GTK2 was pretty long in the tooth. I can only imagine the internal efforts they did for testing.

Windows doesn’t change much for better and worse. The technology from ten years ago still works but that’s not necessarily the best ‘modern’ approach for Windows. Many users complain about flicker when windows are resized. This is a valid complaint but because Windows does not double-buffer their windows like Mac and Linux the older Win32 controls flicker like mad under many circumstances.

Regardless, 64-bit is the roadblock for other things. If you were hoping for Android, interops, or plugins compiled in Xojo to be released in 2017 you’re out of luck. This is what happens with a small development team. There simply isn’t enough man-hours to work around delays in some projects. This happens in ALL software development products but with a small team this impacts everything.

The only bit of good news from Geoff’s blog post is that the Windows framework is getting a big update. This update will ‘dramatically’ reduce flicker according to Geoff. No word on what exactly they’re changing though a thread on the forums from Aug 9 might give a little clue. Changing transparency seems like a little thing but perhaps they plan on implementing a double-buffering scheme. Until we find out more it’s not worth speculating. It seems like this new scheme might make it by the end of this year. So either this has been in the works for a long time or it’s not huge from a coding standpoint.

Promising services based on a product feature that doesn’t yet exist is dangerous. If you were promising Cocoa, iOS, or 64-bit versions before they were actually released you did your customers a disservice. I remember one XDC where a database ORM (Object Relational Model), similar to ActiveRecord, was shown with a lot of interest by those attending. I’m still waiting on it. The lesson is to not depend on vaporware!

So what are your thoughts on R2.1 and the Short-term Roadmap?

Xojo 2017 Release 1.1

Xojo 2017 Release 1.1 hit the web today.  This dot release contains some very important Windows framework bug fixes related to printing and is recommended for all users.  There are a few other changes as well.

For those that are trying to print reports in Xojo this release fixes some critical bugs.  First, the Printer.Landscape property is now honored whereas before it used the default printer orientation.  Second, the PrinterSetup.Setup string is now built and restored properly and works when set.  These fixes now allow reporting tools like BKS Shorts to print properly in landscape mode when restoring the PrinterSetup.SetupString.

A couple of exceptions were fixed in the IDE.  Toggling the line number display in Windows no longer disables the cursor.  You can now toggle the line numbers in IDE scripts.  Duplicating an instance of a container control no longer create an invalid control set.

It is important to recognize the value of this dot release.  For many developers this isn’t an important release but for those of us that rely on printing this was a big deal.  2016 R4 broke printing almost entirely and it was mostly corrected in 2017 R1.  Each release of Xojo brings new features and many bug fixes it’s often very difficult to revert to an older version.  So kudos to Xojo Inc. for doing a dot release.

Xojo 2016 R4 (The Xojo IDE I Always Needed)

Xojo 2016 Release 4 hit the web today.  In many respects this is the IDE that I wish had been released three and a half years ago as a few of the more insidious features bugs have been fixed.  And, as usual, there is a plethora of new features, changes and bug fixes that make R4 a must-have release.  Let’s get to it!

First, the tabs in the IDE now work like most of us want them too.  Open an object, say a window, into a new tab.  By default this tab is locked and it will stay in that window.  The small back and forward arrows at the top of the navigator are not even visible.  To ‘use’ the tab for another object click on the lock symbol in the tab to unlock it.  It might take a click on the name of the Window at the top of the navigator but the arrows come back and you can navigate back to the project stack.  Or, as I tend to do just close the tab and open another object.

In a somewhat related fix, the Back and Forward arrows in the toolbar now work properly per tab.  As you navigate through an object, choosing the back button remembers where you’ve been in that object.  In previous releases the Back and Forward arrows seemed to be a exercise in random number theory as it seemed to go to locations in the IDE I had never visited.  There might have been a pattern to it but usually I just never bothered to use the buttons.

If nothing else, these two changes are a compelling reason to use R4.  The locked tab feature and the back/forward buttons never worked the way I wanted to use them.  It is sad that it took this long to get it right.

The Navigator filter received some updates too.  Now you can use type’s like ‘type:property’ will only find properties.  ‘Type:shared%’ will only find anything that’s shared.  It’s pretty powerful and I recommend playing with it a bit to get used to it.

There is now a contextual menu item for Pictures to convert them to an Image Set and put the selected picture in the first image slot.  This eliminates multiple steps with the mouse and is a very useful addition.

For Windows users there has been some changes.  UseGDIPlus has been deprecated and is replaced with Direct2D drawing.  Make sure to test any of your Windows apps that use a lot of drawing in a graphics object as things might have changed a little with the switch to Direct2D.

New Picture only creates 32 bit depth pictures and this now matches what the other target platforms do by default.  This also means that NewPicture method is deprecated.  HiDPI builds for Windows are no longer beta.

Xojo cloud received a major update.  Uploads to Xojo Cloud are now much faster.  Libraries are now cached by the server so only code and image resources are uploaded.  For example, in R3 one of our largest web projects took over three minutes to upload.  The first time I used R4 it took a little over two minutes (it was caching new libraries) but every time I uploaded the project thereafter it took a mere 44 seconds to upload.  That’s a significant time savings!

The WebListbox now has a CellPicture method that allows you to assign a WebPicture to it.  The WebSession shutdown mechanism has been refactored to help keep sessions from getting stuck and not quitting.  Exceptions in Websession.close no longer keep subsequent sessions from closing.

Due to changes, especially on the Windows side, you might want to check on updated versions of your plugins.  MonkeyBread software recommends version 16.5, or newer with R4.  16.5 is currently in preview and they expect to release it next week.  Einhugur has a couple of updated plugins for Release 4 as well.

As with any major Xojo release, you should test your projects thoroughly before releasing anything into the wild.  The beta program catches a lot of bugs but it’s not a perfect program.  One such bug that got through is an Application crash when using the Super button in the Inspector.  Until a fix is released type the class super by hand rather than using the dialog.

R4 is a small, but significant release.  It moves Windows forward using Direct2D drawing, and Xojo Cloud is significantly faster for deployment, but perhaps the changes to the IDE are the most important.  The Navigator is not nearly as horrible as it was in previous releases and, in my opinion, makes it as useful, now, as the Real Studio IDE.  If you are still using Real Studio I recommend checking out R4 as I think it takes most of the pain out of using Xojo.

What’s new, changed, or fixed, that makes you happy?

Xojo 2016 Release 3

Xojo 2016 R3 was released today.  This release is a much smaller release than either R1 and R2 and despite not having any major new features has some nifty new small features and changes that will probably make your life easier.

You can now create a new event definition by right-clicking on an existing event and choosing “Create New Definition From Event”.  If you have ever subclassed a control you know what a pain this can be.  You need the Open event for your subclass, but you need to create a mirror Open event so the user could do something.  Before this release you had to create the definition manually and then hope the parameters (if there were any) matched.

Making ImageSets from existing pictures is easier.  Right-click on the picture and choose “Convert to Image” where it will create an ImageSet and put this image at the base image.  The only caveat to this feature is that you must have the Supports Hi-DPI setting in Shared Build Settings checked.  This seems like a needless restriction in my opinion.

You can now right-click an item in the Library and be able to create a new subclass from that menu item.  You no longer have to add a class and then change its super to the class you want.

Extract Super is a new right-click option on a class that lets you extract code items.  If you have a subclass , like the Listbox, you can now extract the super and tell the IDE which methods, properties, constants, delegates, enumerations, etc it should have.  To do this before would have been an extremely tedious and time consuming task.

Right-clicking on the Contents headers in the Navigator lets you insert things into your project.  In a similar fashion, right-clicking on a header of an object lets you add another of the same type.  If you right-click on Methods the only thing active in the contextual menu is the Add method.

The contextual menu in the Code Editor has two new additions.  You can now “Wrap in #if false #endif” and “Wrap In For Next”.  Both of these will options will wrap currently selected code in that code.  Another interesting adoption, “Convert to Constant” will take the currently selected code and bring up a Constant dialog allowing you to change the Name, Scope, Type, and Value of the constant before saving it and replacing the code with the new constant.

The icon for the Xojo Project file now has a solid color that helps distinguish it from the other Xojo text files.

The Library now has two “All” entries.  One is “All Controls” which shows every control including custom subclasses in the project.  The second is the “All Built-In Controls” which is just the native controls for the project type.  There is a new attribute you can add to a control, “HideFromLibrary” that you can add to a control subclass that keeps it from listing in the library.

If you like to have non-standard code editor colors you can now import and export color themes in preferences.  Also in preferences you can set how many “Recent Items” there are in the menu of the same name in the File menu.

As with every Xojo release, R3 has a not insignificant number of pure bug fixes.  I encourage you to look at the entire list and decide for yourself if anything important to you has been fixed.

An important bug concerning MySQL was fixed.  In the R2.x series using a MySQL connection in a thread would just ‘hang’ and never come back.

In my own testing R3 has been solid.  I did run into an issue with a web project that I opened in R3, saved it, and then tried to reopened it in R2.  I got the infamous “You might lose data” message that’s always scary.  In R2 I did an analyze project and saved it with on further issue.  So remember kids, backwards compatibility is a blessing – not a guarantee.

I enjoyed this beta cycle.  It was much smaller and easier to test.  Without major new features it seemed a less rushed cycle.  Hopefully R4 will be as good.  Will we finally see 64 bit debugging?  Man, I hope so as a current Raspberry Pi project really could use it.

Anything in R3 that you’re particularly happy to see?

Edit:  As Tiago points out in the comments section I forgot to mention the compiler optimization settings!  This dropdown in Shared Build Settings area will choose an optimization level (Default, Moderate, and Aggressive) for Raspberry Pi and any other project built for 64-bit.  Early reports suggest that it does a good job on math intensive projects as well as projects that are using a lot of loops.

It missed my initial list because we’re not building for 64-bit yet – waiting on that debugger.  I apologize for the omission.

Xojo 2016 Release 2.1

Release 2.1 of Xojo 2016 was released yesterday.  This version fixes a few bugs discovered in Release 2 and fixes couple of serious regressions regarding threads.  Sadly, it also introduces a couple of new bugs that might affect your project.

A number of bugs were squashed in iOSTable and for web apps.  If you use either I recommend checking the release notes.

I am unsure of exactly what changed in Release 2 but Threads had issues.  Release 2.1 fixes quite a few (most?) of them.  Resuming a suspended thread now works properly on sleeping or suspended threads.  Blocked threads waiting for locks will stay waiting.  Some applications were hanging when the last non-main thread exited and the main thread had recently been unblocked.

If you are MySQL user the thread issue may have affected you as well.  Certain queries that create detached threads would cause assertions.

The DMG’s distributed by Xojo are now code signed so they will open in Sierra.

A product as big as Xojo will inevitably have bugs not found during the beta process.  I usually joke it takes about thirty seconds after release for the first bug to be found and Release 2.1 is no exception.  These Windows bugs, however, are no joking matter.

If you use RTFData in a Windows application you may experience problems.  As you reload the rtf data back into the control the text sizes get smaller.  Feedback 44852.  This may be related to Feedback 44878 where using SelTextSize and TextSize results in the wrong size being reported.  So if you have 10 point text it will report back as 9.5.

I think it’s always a good idea to peruse the Newest and Recent Activity lists to see what other developers are seeing.  There are a few other minors regressions being reported as well as a couple of Windows only regressions.

Should you upgrade to R2.1?  If you are already using R2 you most definitely should as R2.1 fixes some serious issues..  If you are on an earlier version it’s a bit more murky.  The answer is a definite maybe but only after some doing real testing – especially if you are using threads or MySQL.

What say you Xojo friends?  What do you think of R2 and R2.1?

Xojo 2016 Release 2

Last week Xojo 2016 Release 2 was unleashed to the masses.  There are a lot of changes and tweaks in this version and if you are creating web or iOS applications there is a lot of like about this release.  There are also a myriad of changes and enhancements that should satisfy most developers.

iOS Stuff

The biggest changes in R2 is for iOS and these are things that developers have been requesting since its initial release.  Support for iOS 7 has been dropped because its market share is less than 20% and the minimum required version is now iOS 8.  This also means that Xcode 7 or Xcode 8 needs to be installed.

The Xojo engineers added iOSScrollableArea which allows you to view and display content that is larger than the view.  This is a very welcome addition and is worth the upgrade for this feature alone.

R2 also adds the iOSLocation class that allows your application to request location coordinates as well as get updates from the device.  Once your application gets permission to access the device location you receive changes via the LocationChanged event that gives you latitude, longitude, altitude, course and speed parameters.  An Accuracy property lets you change the desired accuracy.  In addition to iOSLocation Xojo has added the iOSMotion class that allows developers to access the accelerometer and gyroscope.

iOSTable was arguably the most useful and least powerful control in iOS for Xojo and this release definitely gives it some love.  You can now embed controls in the cells of iOSTable by using the iOSCustomTableCell class.  This allows you to create some very rich and powerful UI that lives in the cell of an iOSTable.  I guess the best equivalent in desktop and web terms is that the iOSCustomTableCell is a specialized ContainerControl you can put into an iOSTable cell.  I’m looking forward to using this.

They’ve also added support for Row Actions in the iOSTable.  The new ActionsForRow event passes in the section and row and you have to supply the iOSTableRowAction array.  The iOSTableRowAction has a title, an Auto tag and a Style.  The style can be either Normal or Destructive with Destructive changing the background of the Action to red (does this ever vary? – not sure).

The new iOSSharingPanel allows you to share pictures, text and URL’s with any registered system service or app.  That’s a fancy way of saying you can share this data between applications.  It’s the iOS version of the clipboard available to desktop applications.

The iOSPicturePicker class allows you to select images on the device or take pictures with the camera.

To avoid confusion for users, the old SQLiteDatabase class for iOS has been renamed iOSSQLiteDatabase.  The corresponding recordset class is now named iOSSQLiteRecordSet.

Non-IOS stuff

The Web framework is now HiDPI capable.  It works similarly as desktop apps in that it queries the browser for the scaling factor.  Then, the application serves up the proper image if it can.  You can change how this works by changing the Supports HiDPI in the Shared Build Settings.

In Windows there are a number of significant HiDPI changes that make it work better in Windows 8.1 and 10.  Perhaps the biggest Windows change is that Xojo.Net.HTTPSocket is no longer much slower than HTTPSecureSocket.  I have not had a chance to look at this one in detail yet so if you’ve had success or failure with it, please leave a comment below.

Always check the release notes that are in every release.  I’m just hitting the highlights out of hundreds of line items and you never know what might be there that affects your application.

As with any new release it’s better to test your project against it before releasing it into the wild.  In my own testing I had some instability with converting an old web project (started around the very first public beta of Web Edition) to use HiDPI graphics.  This involved adding an ImageSet and adding the 1x and 2x graphics, deleting the old graphic, and then fixing it in all locations in the project.  I was able to crash the IDE but all of the crashes were different and, of course, none of it was reproducible.

The Future

The 800 pound gorilla in the room is a 64 bit IDE and 64 bit debugging.  Things like XojoScript are holding back the IDE from being 64 bit.  I would also imagine that not having an integrated debugger available in 64 bit is holding back that as well.  I know we are avoiding releasing some 64 bit projects because of these limitations. We’ve also been playing around with the Raspberry Pi and it’s definitely not very useful without the debugger.

We need the 64 bit debugger.  Let’s hope that R3 provides us with some relief in that area!

How has your experience been with R2 so far?