Computed Properties

Computed Properties have come up several times in the past week and in both cases, the person I was talking with was having a hard time understanding them.  They are a useful tool in Xojo in the right circumstances.  So let’s dig in.

First, let’s get this out of the way.  You don’t need to use Computed Properties.  Ever.  If you don’t want to.  They are an automation feature of the Xojo IDE.  Simply, they are a lazy way to create getter and setter methods for a private property in your class.

There are times when you want to expose your private property to the outside world but not give it unrestricted access.  Usually you’d want to do this because you need to validate the input, or perhaps something needs to be done before it can be read.

Creating your private property is no problem.  In this case we’re creating moSecurity that is a reference to our clsSecurity class.

Private moSecurity As clsSecurity

You create a Getter method that checks to see if we’ve already created an instance of it.  If not, then you load it and then simply return it.  Simple enough.

Function Security() As clsSecurity
   
   if moSecurity = nil then
      
      moSecurity = me.LoadSecurity
      
   end
   
   return moSecurity
   
End Function

If you want to change the Security object, you create a Setter method and use the Assigns keyword like this:

Function Security(assigns oSecurity as clsSecurity) As boolean
   
   if oSecurity <> nil then
      
      if me.CanChange(oSecurity) = false then
         
         return false
         
      end
      
   end
   
   moSecurity = oSecurity
   
End Function

Again, not terribly difficult to do.  It’s one property and two methods.  Notice that I didn’t name them GetSecurity and SetSecurity because I want these methods to act like a property to the outside world.

Return valuesThe Xojo IDE tries to be helpful by making a hierarchy of the methods that have the duplicate name.  You may (or may not) find this to be terribly useful.  I happen to dislike it because I can’t tell at a glance what the return value is, if anything, on either method without hovering my mouse over it or clicking on it and looking at the Inspector.  But then this is true of ALL functions – not just these types. Just one of the things that I miss from the Real Studio IDE.

SetterGetterMethods

Now repeat this sequence for every private property that you need to have exposed with Setter and Getter methods.  It’s not that it’s hard, it’s just tedious.  And if you have a particularly large class (think Formatted Text Control) that has hundreds of properties, the Method list gets HUGE.  The other drawback is that I often forget to use the Assigns keyword so I get compile errors if I attempt to use the Method as a property.

Computed Properties is a way to help make this a bit easier  We can accomplish the same thing by creating a public property called oSecurity in clsUser.

oSecurity As clsSecurity

ConvertToComputedPropertyPopupRight click on it in the Navigator and choose Convert to Computed.  You’ll see that the IDE makes a Private property called moSecurity as clsSecurity AND creates a hierarchical group for oSecurity containing a public Get and public Set method.  The default code that is in these computed properties is:

 

 

 

Get
   
     return moSecurity
   
End Get

Set
   
   moSecurity = value
   
End Set

At this point, we can modify these Get and Set methods to almost what we had before.

Get
   
     if moSecurity = nil then
   
   moSecurity = me.LoadSecurity
   
end

return moSecurity

End Get

Set

if oSecurity <> nil then
   
   if me.CanChange(oSecurity) = false then
      
      return
      
   end
   
end

moSecurity = oSecurity

End Set

ComputedPropertiesNotice that in the Computed Property version of the set we can’t return a value.  This is probably the biggest drawback, in my opinion, to using Computed Properties.  It’s almost the same amount of work but we have potentially saved some typing and we no longer have to worry about the assigns keyword because the IDE is automagically adding it for us behind the scenes (remember, we all want to be lazy programmers, right).  Thus our property is still treated as a property to the outside world.

One of the things that annoys me about Computed Properties is that now you have double the amount of Properties.  In the old fashioned (setter, getter) way you get a bunch of methods and in this second way double the number of properties.  Both, however, do mostly the same thing.

In my own fantasy world (believe me, it’s scary sometimes) I’d love to have the IDE group Public, Protected, and Private constants, methods, properties, etc so that I can expand only those that I want.  In this case I’d prefer to see only the Public ones.  The drawback is that you would have an additional hierarchy layer that causes clutter and may cause some confusion.  Would having the ability to hide certain scope types help?  I don’t know.

Do I have a conclusion?  Setter and Getter methods for your properties is easy enough.  It takes a little bit more work to set up and a bit more typing.  Each method, however, makes the Navigator a bit harder to read because of the added hierarchy but then so does the Computed Property.

Should you switch to using Computed Properties?  Only you can answer that.  I guess the only thing I’d recommend is be consistent throughout your project.  Consistency makes programs easier to read.

What say you, Xojo programmers?  Do you like using Computed Properties?  Why or why not?

ARGen 1.6.3

ARGen64BKeeney Software released a new version of ARGen today.  ARGen is an ActiveRecord class generator for Xojo and Real Studio.  It allows you to generate all of the classes required to use ActiveRecord in your projects.

Version 1.6.3 Fixes a CubeSQL bug that kept the Load function from working properly.  You could get around this by using the FindByID shared method but some people prefer the Load method.

This version also modifies the ActiveRecord classes a bit so it uses the prefix/suffix preferences used in ARGen to make sure your classes have the required property to match the field in the table.  For example, if you had a field PlaywrightID and were using a prefix of ‘i’ it will now flag the developer if there isn’t a property named iPlaywriteID.  In previous versions it didn’t really matter what you used.  This is just one more developer aid.

It is recommended that all Windows users update manually since a bug was discovered in earlier versions of the auto updater.

Recordset’s are Funny Things

We have a new developer working at BKeeney Software and he’s in the learning phase of Xojo. Not only is he new to Xojo but he doesn’t have a ton of experience doing software development in general. As someone who’s been using Xojo for a long time it is interesting to see how people struggle with the language and the IDE.

Today we had one of those “teaching moments” as he was beating his head up against the wall with this bit of code in a save method. This is a simple Invoice application saving the invoice line item to an SQLite database that’s on the local machine. See if you can spot the mistake.

dim rs as recordset =db.sqlselect( "Select * From tinvoicelineitem where invoicelineitem_ID = " + str(iInvoiceLineItem_ID) )
if db.error then
   msgbox CurrentMethodName + " db error: " + db.ErrorMessage
   break
   return false
end
rs.Field("InvoiceID").IntegerValue = iInvoiceID
rs.Field("salesTax_Flag").BooleanValue = bSalesTax_Flag
rs.Update

if db.error then
   msgbox CurrentMethodName + " db error: " + db.ErrorMessage
   break
   return false
end


Have you spotted the error yet? I don’t blame you. It’s easy to miss and it took me a few minutes of staring at it to find it. The code runs with zero code errors and zero database errors. The only thing that’s wrong is that it doesn’t save any line item data.

Okay, I’ll tell you. I forgot to add the rs.edit command at the top of the method. Without telling the recordset that you’re editing it, it will never generate the SQL to update the RecordSet.


dim rs as recordset =db.sqlselect( "Select * From tinvoicelineitem where invoicelineitem_ID = " + str(iInvoiceLineItem_ID) )
if db.error then
   msgbox CurrentMethodName + " db error: " + db.ErrorMessage
   break
   return false
end
rs.Edit // IMPORTANT!
rs.Field("InvoiceID").IntegerValue = iInvoiceID
rs.Field("salesTax_Flag").BooleanValue = bSalesTax_Flag
rs.Update

if db.error then
   msgbox CurrentMethodName + " db error: " + db.ErrorMessage
   break
   return false
end


I can argue that the lack of an error is bad. Sure, I didn’t code it right, but you’d think there would be some sort of error if an update was called without a starting edit. I’ve added <feedback://showreport?report_id=35134> to the Feedback system.

To be honest, we don’t do straight Xojo database calls much any more simply because we’re using ActiveRecord for most projects. AR eliminates most of the tedious database coding and let’s you deal with the data and the UI. When you call the Save in ActiveRecord you don’t need to care if it’s a new record or not. AR handles all the gory (and boring) details for you.

What say you my Xojo friends? Do you get bit by this type of thing when doing database coding?

Naming Conventions

If you don’t have standard naming conventions in your Xojo (or any other language for that matter) project you need to start NOW.  I mean it.  Open your IDE of choice and start looking at your variable names.  Can you tell at a glance what type of variable it is?  Better yet, can you tell what it does?  Or do you have a bunch of x, i, y, and z’s floating around in your code?

What about your TextFields?  Do you name them so you can tell their function or do you simply use the default name that the IDE gives you?  How do you tell the difference between TextField1 and TextField2?

Literally, the first thing I do when handed an OPC (Other Peoples Code) project is to look at the control names.  If I see TextField1 and TextFieldX I will almost always turn the project down.  But if I see txtName and txtAddress I know that I can figure out the code without constantly having to look at the Layout Editor.  The point is that controls are referenced in Xojo code all the time so if you’re naming your controls so that their function is obvious, the code will be obvious too.

The same goes with variable names.  I will prepend arrays with ar so that an array of MyClass will always look like aroMyClass.  My dictionaries always have dict in the front.  Colors always have c prefixes and so on (see chart below).

Do I use the occasional i, x, y and so on?  Absolutely, but they are throw away variables that are inevitably part of a loop of some sort.  If I’m using that variable for any other reason I will always name it something useful.

Variable names are important.  Rarely will you see me using iTemp as integer.  Instead, I’ll use iTempIndex which will at least tell me something about the variable.

I dare you to look at a project you did a year ago and open up any random method in it.  Can you read the code without referring to the Layout Editor?  I know that I’ve refined my own coding standards because of this.  If you’re not learning from your past mistakes why keep doing what you’ve always done?

I can hear some of you now.  Standards…Pft!  I don’t need no stinkin’ standards.  Think again.  I’m not here to tell you what those standards are just that you have them and that you are consistent about them.

Do what makes sense to you.  I looked at hungarian notation (http://en.wikipedia.org/wiki/Hungarian_notation) and I can see why people call it a different language.  While I’m sure it has many fine qualities it seems to make more work for me in figuring out what the variables are doing.  It’s way too complicated for Xojo.  For me, at least, simpler is better.  Plus, I’m not sure that a strongly-typed language like Xojo is in need of such strong naming conventions.

Using naming conventions for your controls and variables is an easy way to simplify your life and your clients’ life (if you’re handing code over).  Remember, you’re not just coding for the here and now, you’re coding for someone that will look at the code 6 to 12 months from now.  That someone might just be you!

Below is values right out of our new developer introduction document:

Variable Prefixes
Datatype Prefix Example
string s sName as string
integer i iCnt as integer
double d dAverage as double
dictionary dict dictNames as Dictionary
date dtm dtmModified as New Date Assumes I care about the time
date dt dtToday as new Date assumes I do NOT care about the time
class reference o oMyClass as new clsMyClass
color c cHighlight as color
folderitem f fPic as FolderItem
private property m miCnt as integer
boolean b bVisible as boolean
memory block mb mbBuffer as MemoryBlock
window win winMain
class name cls clsMyClass
array ar arsNames() as string ardAverages() as double aroMyClass() as clsMyClass
Control Prefixes
Control Prefix Example
Pushbutton btn btnSave
Label lbl lblCaption
Listbox lb or lst lbPeople or lstPeople
StyleGrid sg sgPeople
TreeView tv tvSections
TextField/TextArea txt txtPassword
CheckBox cb or chk chkEnabled
BevelButton bb bbSelect
ComboBox cbo or cmb cmbUserType
PopupMenu pm pmState
ProgressBar prog progUpload
Scrollbars see example common practice to use vScroll and hScroll
Radio Buttons rb rbOption1
Canvas cvs cvsGraph
TabPanel tab tabMain
Toolbar tb tbMain
PagePanel pp or page ppSection
Menu menu menuPopup
Container Control cc ccDetails

Xojo 2014 Release 2.1

Xojo 2014 Release 2.1 was released this week. This maintenance release is huge in several important ways.

This is the last version of Xojo that will build Mac Carbon apps. The upcoming changes to the framework for iOS and 64bit (and who knows what else) have made it impossible (or at least unfeasible) for the engineering team to keep supporting the Carbon framework. So long Carbon, we have to split up. It’s you, really, not me.

Since this will be the last version to support Carbon some nagging bugs were fixed in the Carbon framework. The hard crash that occurred when creating a new instance of the XMLDocument has been fixed. In addition a bunch of plugin issues for Carbon were fixed.

Cocoa apps that use RegEx will now pass submission to the Mac App Store.

For web app developers a big change was made to HandleSpecialURL that breaks everything that depended upon how the old, incorrect way, WebRequests were handled. I know this affects Web Custom Controls and it may also affect Studio Stable Web Essentials (unconfirmed). More info in a Xojo blog post at http://www.xojo.com/blog/en/2014/08/handlespecialurl-changes-in-2014r21.php

A few other web bugs were fixed. WebSession.Quit now properly clean and close the Session. A bug with WebContainer.EmbedWithin used in a open event (never a recommended way, if you ask me) that would cause WebLabels and WebLinks to offset was fixed.

There were several of database class changes too. SQLite now uses FTS4 with unicode61 tokenizer on Mac OS X. MySQLCommunityServer SQLExecute and Prepared statements no longer assume the statement is UTF8 encoded. The ODBCDatabase DatabaseRecord.Insert no longer inserts the wrong value.

As always, read the release notes for additional information and Feedback ID’s.

This dot release is critical for those developers still building for Carbon. iOS will (presumably) be out in Release 3 in at least beta form and the new framework is causing changes in a big way. I’m sure some of those changes will be subtle but some will be a smack to our collective faces.

To paraphrase Game of Thrones, “iOS is coming.” Sorry, couldn’t resist. :)

PDF Classes 2.5.0 Beta 1

pens128BKeeney Software has introduced the first public beta release of BKS PDF Classes for Xojo. The PDF Classes are 100% native Xojo classes that allow developers to create PDF documents via code in their Xojo applications. The classes work for Mac OS X and Windows. Linux is currently unsupported.

The PDF Classes are for creating a PDF document. Others means must be used to display PDF documents from within a Xojo application.

Version 2.5.0 Beta 1 is the first public release of these classes. The classes cost $200 and contain the full source code. This introductory price is for a limited time only.

More information, including Windows and Mac OS X downloads, is available at http://www.bkeeney.com/allproducts/pdf-classes/

Users that have a valid Fireye Software PDF Classes license can contact BKeeney Software at support at bkeeney dot com to receive a discount.

Xojo vs Xamarin

Last week when I was the guest speaker on Xojo’s webinar on consulting, I fielded a question regarding Xamarin.  The basic gist of the question was if I felt that Xamarin was a threat to Xojo.  At the time I had heard of Xamarin and read a few articles on it but that was about it.  In the week since I’ve been doing more research on the topic.

Xamarin is an interesting development tool.  To sum up what it is in a sentence or two probably does it some injustice but here’s my take.  Xamarin takes the C# language and .NET framework and has ported it to Mac OS X, iOS, and Android.  This allows developers to use the Visual Studio IDE on Windows, and Xamarin Studio users on Mac OS X and Linux to create native Mac OS X, iOS, Android apps, in addition to Windows desktop and Windows Phone apps.

I threw Mac OS X in there since it’s listed on their website but it appears to more of an afterthought since the focus seems to be on mobile applications.  Indeed, their mantra is that they want to make the best development experience for mobile applications.

I am not a C# developer but like most modern languages it’s not the language that’s difficult to learn it’s the framework and .NET is arguably one of the biggest and most advanced frameworks around.  Having the .NET framework available for iOS, Android, and Mac OS X is a huge advantage for anyone already familiar with it.  Theoretically it should make the transition from Windows developer to cross-platform developer very easy.

Xamarin uses native platform user interfaces and compiles to native applications for each supported platform.  This is good in that you get the best of each platform.  The not so good is that it appears that you’ll end up coding each user interface separately (see Xamarin.Forms later on).  I can see the arguments going both ways on this whether this is good or bad.

Unlike Xojo, Xamarin does not have a built-in forms editor.  They give the option of building Cocoa and Cocoa-touch applications strictly via code or by using Apples Interface Builder.  You either stay in Xamarin to build everything via code or you exit to Interface Builder to design your UI.  I can’t imagine that’s very efficient but Interface Builder wasn’t always integrated in Xcode either.  As a developer you have to roll with the punches.

The Xamarin framework has some cross-platform calls to make life easier, but when it comes to iOS and Mac OS coding it appears that most of it is similar to Xojo’s ability to make declares into the native OS.  Again, you might call this a strength as you get the Apple methods but it also means that you’ll need to know each target OS in detail which can be a rather large learning curve.

Xojo abstracts as much of the platform as possible which means that a TextField on Mac OS has mostly the same capabilities as a TextField in Windows and Linux.  The strength in Xojo means that you don’t need to know the details of each platform but it also means that you generally get a compromise in functionality.  This is where system declares can really aid the Xojo developer.

Web Presentation

Xamarin’s website is gorgeous.  Nearly everywhere you go there are very helpful tutorials and videos explaining how to do things.  It’s also laid out in such a way that you can quickly find things.  The Xojo website is okay and relatively easy to find things but Xamarin goes out of their way to convince you to use their development tool.

The tagline on the Xamarin home page is “Create native iOS, Android, Mac and Windows apps in C#.  Join our community of 687,765 developers.”  Practically everything about the website screams, “Use me and you’ll make a great applications!”  It’s very professional looking and it’s all business.

The tagline on the Xojo website reads, “Create powerful multi-platform desktop, web & web-mobile apps.  Fast development.  Easy deployment.”  It’s not that Xojo doesn’t attract professional developers but their emphasis is on different things.

One thing that surprised me quite a bit was under the Support/Consulting Partners menu of the Xamarin website.  It’s a listing of Xamarin consultants and they are listed by tier (authorized or premier), by geographical region, and by expertise.  The Xojo website has the Find a Developer page.  The first says that it’s a serious language with a lot of software development partners and the other says that it’s a smaller community.

IDE Comparison

The Xamarin IDE is fairly simple and seems to be a hybrid between Xojo and Xcode.  Their Solutions pane is not nearly as complex as the Navigator and is far simpler and easier to use, in my opinion.  The Solutions list only shows objects unlike the Xojo Navigator that shows everything (methods, properties, constants, enums, etc) as you drill down into the object.  As you select an object in the Solutions list the source code editor loads all your source code.

If I had a major beef with Xojo is that they try too hard to dumb down the IDE.  You can’t just start typing away like you can in practically every other language/development environment I’ve ever seen.  Instead, you are forced to add methods through the Xojo UI.  You’re forced to do the same thing with properties, events, constants, enums and so on.  While this is great for people just starting out in Xojo it’s a limiting factor for more experienced users and forces you to use the mouse – a lot.  This means you can only see one method at a time unless you open up multiple windows whereas the Xamarin source code editor shows you everything in the source code.  Method definitions are defined via text in the code editor and not by a specific user interface.

Xamarin has the prerequisite autocomplete in the source code editor and appears to be work roughly the same as Xojo’s.  One thing that I REALLY liked about Xamarin was a tool tip showing you what the current parameter was.  As the user types the code editor recognizes where it is and provides a tool tip with a hint on what it’s currently expecting for the parameter.  This was one of my favorite features from VB6 and sadly, Xojo’s source code tip is an antique by comparison.

Xojo has a built-in forms editor.  Not only that but it has a reports editor, menu editor, database editor, as well as specific editors for a bunch of one-off items.  Xamarin shows objects and source code – that’s it.  So this forces you to either build all the UI via code or via an external editor.  While the Xojo editors aren’t perfect they are there and easy to use.

If you purchase the Xamarin Indie subscription (or better) you can use the Xamarin.Forms module which allows you to build iOS, Android, and Windows Phone screens from a single code base and it should speed up development.  However, I think Xamarin faces similar hurdles to Xojo in that a bug in their framework requires a new release so it’s no panacea.  And, you still build the UI via code not through a GUI editor.

Pricing

Xamarin comes with four different subscription options.  The Starter Subscription is free and is good for individual developers and allows you to deploy Android, Windows Phone, and iOS apps to a device and to their respective app stores.  Apps are limited in size and you are forced to use the native UI builders.

The Indie Subscription costs $299 per year, per developer, per platform.  If you were interested in iOS, Android, as well as Mac OS X this would cost $807.30.  Apps are unlimited in size and can use Xamarin.Forms.

The Business subscription costs $999 per year, per platform, and per developer.  This gives you Visual Studio support, “business features”, and email support.  The same Android, iOS, and Mac bundle jumps to $2,697.30.

The Enterprise subscription costs $1899 per year, per platform, and per developer.  This adds Prime Components (pre-built UI assemblies), guaranteed response time of a day, hot fixes, an individual manager, a bunch of support and code troubleshooting options.

Xojo pricing is much simpler by comparison.  $99 for an individual platform license with a $99 1 year renewal.  $299 for all desktop apps (Mac, Windows, Linux) with a $150 1 year renewal.  $399 for web apps (running on Mac, Windows, or Linux computers) with a $200 1 year renewal.  $999 gets the Pro license which gives you all desktop, web, database server, and console/service apps, consulting leads, and beta program access and the 1 year renewal is $500.  The Enterprise license at $1,999 is everything as Pro with an additional day of custom training and the 1 year renewal is $1,999.  All of the licenses are for a single developer.

Xojo is considerably less expensive but the Xamarin pricing is inline with what professional developer organizations are used to paying for their tools.

Conclusions

If I were a C# developer I would be all over this product – especially if I wanted to my apps running on non-Microsoft computers and devices.  I believe this is where many of the nearly three quarters of a million developers are coming from.  I’m sure there are plenty of other developers that were tired of developing their mobile apps on one or possibly even three separate development tools too.  Xamarin makes the development process easier  by using a single tool.

Xamarin is really pushing mobile app development.  Based on the forum activity I suspect that Mac OS X isn’t in the limelight but because iOS is so similar I can see why it was added.  It’s another notch in the capabilities checklist for a growing tool and user base.  If you can do all of your development with one tool why wouldn’t you?

Xojo really isn’t competing in the same space as it’s for only desktop and web applications (an iOS version is currently in alpha testing and should be released this year).  Xojo has been doing cross platform desktop and console applications for nearly two decades and has transitioned through 68k, PPC, and Carbon to Cocoa on the Apple side as well as all the Windows and Linux variants and versions.  Web apps are relatively new but the framework is very much the same as the desktop side.

From what little we’ve seen of the iOS version (remember that it’s in alpha testing right now) it has a built-in forms editor and uses pretty much the same framework as the desktop and web (with specific differences, of course).  It promises to make developing for iOS extremely easy.  However, Xojo has no current plans to support Android or Windows phone.  This might be the one key difference that might make Xarmarin an attractive development environment for many.

Will this consulting company be switching from Xojo to Xamarin anytime soon?  No.  The cost of migrating to a new tool, retraining, and getting involved with consulting in a new environment is considerable.  If Xojo went away tomorrow I know which tool I’d look at first.

Xojo Webinar: Xojo Consulting

For some time now Xojo has been doing webinars on various topics.  It’s a great way to learn about Xojo.  In addition to being live (where you can ask questions) they are recorded too.  As time goes on the webinar archives become a really nice resource for new Xojo developers and even experienced developers can learn a few things too.  If you’ve never been to the archive, check it out!

Join me at the next Xojo webinar, Tuesday, July 22,  where I’m guest host!  I will share my 13+ years of Xojo consulting experience.  Learn some of the great things (and not so great things) about being a Xojo consulting.

Come prepared with questions!

Register now at http://xojo.com/support/webinar.php

Xojo and the End of Carbon Support

In a blog post this week Xojo announced that they were dropping support for Carbon applications in Release 3 which is due in roughly 3 months. Furthermore, their reasoning for doing so was because the Carbon framework was causing interference with the ongoing iOS work.

At first blush, the decision kind of stinks. We still have some of our own applications and some client applications still using Carbon. Why are we still using Carbon? Mainly because of inertia. They work just fine as Carbon apps and we’ve identified enough items of concern (mainly threads) that will require some rework. Nothing that we haven’t done in other apps but for various reasons we (or the client) just haven’t bitten the bullet yet.

On the other hand, Carbon was deprecated over a year ago. If you haven’t tried to get your apps working in Cocoa by now I would say you have not been very proactive.

In other words, there was plenty of notice that Carbon was going to die a long slow painful death. Carbon bugs just aren’t going to get fixed unless they were critical and the definition of ‘critical’ gets less and less as time goes on. So it makes sense to just kill it and move on.

What about the iOS part? Well, that’s an interesting twist, I must admit. I can only speculate that getting iOS to work properly with all of the existing platforms was going to cause some major work (and future maintenance) in the Carbon framework. Why do all that work for a deprecated target?

This means that we should all be beating the hell out of our Cocoa applications to make sure bugs are squashed or decent workarounds found. If a Cocoa bug has been keeping you from moving to Cocoa and you haven’t reported it yet it’s your own damned fault. Now you have no excuse.  The clock is ticking.

For us, we have to have the discussion with our clients. Either they move to Cocoa and stay more or less in sync with the latest Xojo or we stick with an older version for Xojo (or Real Studio). The pain can be modest now or major later. From experience the more out of sync you are with the current release the more painful it is to update a project to the current version.

The good news is that Xojo Release 2 should work for many years so if you have to support Carbon apps it’s possible. The bad news is that you never know what Apple’s yearly updates will do to Carbon.  It’s probably just a matter of time before they kill Carbon but whether that’s one year or five only Apple knows.

I don’t see this is a huge deal for Xojo developers. The writing was on the wall for Carbon applications for a while. And honestly, Cocoa isn’t a huge transition for most applications and the end result is a much better application.

What do you think about the end of Carbon support?

Xojo 2014 Release 2

Xojo 2014 Release 2 was released this week.  This release has around 200 bug fixes and enhancements, some new features, and some licensing changes.  A good portion of the changes and enhancements are in the Web framework which will make web developers very happy (I know I am!).

Licensing Changes

New Single Desktop licensing.  A new license is available for a single desktop platform (Mac OS X, Windows, Linux) at $99 each.  This is helpful if you are only dealing with a single platform and have no need for the other two.

Pro license is $100 cheaper.  A new Enterprise license is now available that gives you everything that the Pro license gives you plus 8 hours of custom video training.  The Enterprise license costs $1,999 for both new and renewal.

Changes

Users can now add plist items into the plist generated by the IDE at build time.  This takes the form of an XML file that is added to the project.  If this is something you’re interested in take a look at the Platform-Specific/OS X/PList/EnableRetina example.  If you were using an IDE script or PostBuild script on the Mac side to do this already I’m not sure that this is a better solution.  However, I think this will be hugely beneficial to Windows and Linux users that are building for Mac OS X.

The PostgreSQL database plugin now has an SSLAuthority FolderItem property that represents the root SSL certificate file.  This lets you connect to your database server using SSL.

Xojo Cloud users can now use the StageCode to create different builds for the server.  Final is the same as it was in the previous release but Beta, Alpha, and Development stages add a -Beta, -Alpha, and -Dev postfix, respectively, to the app name and upload them to the Xojo cloud server.  This should make it easier to test Xojo Cloud applications.  The only drawback I can think of is that smart users might figure out the URL postfix and use the newer version rather than the release.

Speaking of Xojo Cloud, release 2 seems to have finally fixed the hang on upload during large projects.  During the beta cycle I went from 1 out of 5 successfully uploading to a nearly 100% success rate.  Those that did fail didn’t require a restart of the IDE which was a royal pain in Release 1.

AddHandler and RemoveHandler now work with Web controls after they’ve been sent to the browser.  In previous editions you had to use AddHandler before it was sent.  For example, if you added a dynamic WebDialog you had to implement the AddHandler after it was created but before the Show method was called.  Now you can do that after the show.

The WebListBox received some love in this release.  A new SelectionStyle property now lets you set the WebStyle for row selections.  In addition to that, there is a new HeaderStyle and HeaderColumnStyle properties that let you select the header and column headers, respectively.

WebTextArea now has a ScrollPosition property that allows you to set the, wait for it, scroll position.

The WebToolbar has become more useful in that it allows you Append and Remove items.  This has been wanted for a while now.

In one of the bigger bugs that’s affect me for a while, they fixed the WebRequest.QueryString on cgi builds.  This now lets cgi builds to work the same as standalone builds.

WebContainers added via the EmbedWithin method now no longer have exponentially increasing delays.  This is very helpful to developers, like us, that use WebContainers a lot.  This change will let dynamic displays to be more responsive over time.

A bunch of Web framework items no longer leak memory.  Of note is the WebPage when closed and dynamic WebDialogs (i.e. created in code not placed on a page at design time).

A change was made to the Web framework to prevent ‘clickjacking’.  Clickjacking is an attack that tricks the web user into clicking something that is different from what they perceive.  This can potentially reveal malicious or confidential information or even allow taking control of the computer.  As far as I know, this attack has never occurred in a Xojo web app but it’s nice to see that they’re proactive on these things.

StyledText RTF parsing speed is improved.  This is a good thing since it was pretty much a dog before.

A number of console app memory leaks were fixed.

Some database changes:  SQLite is updated to use version 3.8.5.  The MSSQLServerPreparedStatemnt.SQLExecute no longer crashes.  MySQLCommunityServer no longer causes failed assertions when SQLSelect/Execute are invoked while other threads are running.  The Recordset.Update/Delete now works in SQLite databases when he primary key has special tokens (like single quotes) or BLOBS.  The error returned by SQLite databases using a bad encryption key is now the proper error.

Windows and Linux MsgBox and MessageDialog modality is now consistent.  This means that MsgBox is always app-modal but it depends with MessageDialog.  If called with ShowModal it is app-modal but if used with ShowModalWithin it is window-modal.

The IDE has a bunch of changes and improvements.  The long standing issue of changes in the Inspector not being retained unless you tab out of the TextField seem to be fixed.    Changes to non-text properties also commits the changes.  The Inspector has been compressed a bit to reduce scrolling.

In general, the IDE seems a bit snappier – at least on Mac OS X.  Sometimes it’s very hard to tell about fit and finish on the other platforms simply because I don’t develop on those platforms.

Conclusion

Xojo 2014 Release 2 is very much about the Web.  The memory leaks getting squashed, the WebListBox additions, and security improvements are all welcome.  Xojo Cloud is now functioning better and is now, in my opinion, worthy of being used on a day to day basis.  We’ve moved all of our training apps to Xojo Cloud during this beta cycle and are happy with the performance.

If you are not a Web developer than this release still has some changes and fixes that might be important to you. Unfortunately, in a review like this I can only comment on changes that seem important to me.  Check the release notes out!

 

What did I miss in the review that you thought was important?