The Power of Face Time

Face time is very cool. No, I’m not talking about the video conferencing technology that Apple is pushing. I’m talking about sitting across the table from someone and being able to see their body language and see what they’re pointing to. If a picture is worth a thousand words, being in the same room with someone is worth a couple of hundred thousand words.

Most of our consulting projects are small enough and simple enough that email and phone calls are usually good enough. However, I’ve come to believe that the more complex projects need something more. Complex projects take consulting to a new level. Complex business requirements almost always mean more complexity in the design, coding, testing and debugging which in turn brings more complexity in interacting with the client.

There is something powerful about being in the same room with the client. You make a connection that emails, phone calls and video conferences just can’t accomplish. It’s been my experience that these clients trust you more because they’ve spent time with you. As social creatures we pick up on little things that either lead us to distrust or trust the other person. You miss most of it when you are using electronic means.

In late April 2015 the Xojo Developer Conference (XDC) will be held in Austin, Texas. Xojo developers from all over the world will come together and talk all things Xojo. More information can be found at The early-bird special will expire the end of November so sign up for the conference now to save $200.

Xojo will be spending a lot of time talking about iOS, what’s new in desktop and web apps. Hopefully we’ll get news on 64 bit apps, the LLVM compiler, the new framework, and whatever else they’re cooking up.

If this conference is like past conferences the real value isn’t the stuff talked about in the sessions (though that’s usually really great info!), it’s the connections with the people. People looking for a Xojo developer can sit down with several potential developers and discuss their projects and look them in the eye.

Developers can share their successes and horror stories with each other and talk about what works and what doesn’t. The conferences are a great way to network. You never know exactly how those connections will work. Consulting referrals happen all the time. I’ve received leads from developers that are too busy to handle work or on projects outside of their expertise. Likewise, I’ve given leads to some developers because of the conference networking.

Email and forums are handy for storing solutions but are awful mediums because intent and body language are missing.  People that I felt were complete jerks in emails and in forum posts turned out to be really nice when talking to them in person!  Now, the next time I see their brusque or insensitive comments I can just shrug it off because I know the person. I’ve had face time with them and that’s a pretty powerful thing.

XojoTalk Podcast

I just wanted to bring attention to the (relatively) new XojoTalk podcast.  The third edition was released this week with guest Eric Gibbon.  Paul Lefebvre, from Xojo, and Eric talked about the UK Xojo Developers Conference (being held this week!), XDC 2015, widescreen displays, and a whole lot more.  It’s not just about Xojo!

I was fortunately enough to be guest number 2 for the October edition.  Last month I talked about the trials and tribulations of working from a home office, XDC 2015, working in an RV, and the Mavericks and Windows 10 releases.

I have really enjoyed these podcasts.  Paul has done an excellent job of organizing them and keeping the discussions lively.  I’ve found it interesting to hear how other developers use Xojo and how long they’ve been using the product.  I highly recommend that you check it out and give it a listen.

More information on how to subscribe to the podcast at

App Wrapper 3 [u]

Xojo makes developing Mac OS X apps very easy but getting those apps ready for distribution can be a daunting task. Apple has had the option for a while to not open applications from unknown developers using a security option that Apple calls Gatekeeper. Gatekeeper, in effect, restricts which apps a user can run on their computer. This theoretically helps protect users from installing malicious applications.

Gatekeeper has 3 settings: Mac App Store that allows only applications downloaded form the Mac App Store. Mac App Store and Identified Developers that allows Mac App Store and applications signed by certified Apple developers. Anywhere that allows any application to be launched. The default in Yosemite, is the 2nd option (Mac App Store and identified developers). Since Apple only recognizes its own developer certificates they have more control over the entire process.

To pass Gatekeeper you need to have a verified Apple Developer Account. Then use Keychain Assistant to request a certificate from Apple through the Apple Developer portal. Setting up this account costs $99 a year and it isn’t too difficult – Apple has some nice instructions for the novice developer to figure this out. However, signing your Xojo app isn’t the most straightforward thing to do, but we’ll get to that in a minute.

If you are trying to distribute your app on the Mac App Store you have to worry about a myriad of things that Xojo doesn’t automatically give you. The first is code signing your application. Other issues include Retina display settings and Retina image sizes, how you interact with the system via the App Sandbox, and if you are using iCloud or other Apple online services, Push Notifications or Game Center.

That’s a ton of stuff to figure out how to add on your own to your project. For several years we had our own postscript build that called a bunch of command line utilities that did the code signing, set the proper plist entries and so on. It was a pain to maintain and move to different projects for a variety of reasons – one of them being that finding out the cause of a script error wasn’t always straightforward!

AW Open

Enter App Wrapper from Ohanaaware. We’ve used App Wrapper 2 for a while and have been extremely happy with it. It takes the guess work out of configuring your Mac OS X distribution because the utility remembers the settings you’ve used for each application. This includes remembering which code signatures to use. Since we create apps for ourselves and for clients this is particularly useful.

App Wrapper 3 has five panels to choose from. The Report tab gives an overview of everything in the application along with reasons why it may be rejected from the Mac App Store. In the example below I’m showing ARGen, our ActiveRecord utility, that is NOT in the Mac App Store. If I did try to submit to the Mac App Store it would be rejected for three reasons: first, it uses the Sparkle framework, and the eSellerate libraries – both of which are rejected by Apple and are unnecessary in Mac App Store applications. The second reasons is that CubeSQL references QuickTime in the plugin (which is surprising since it’s a database plugin).

AW General

The General tab lets you set a number of variables needed by Apple. What’s the Category, minimum Mac OS X that can run the application. The copyright information. The version information, high resolution mode (Retina), which code signature to use, registering an Apple help file, and how the app should be packaged for you (to name the highlights). This is, by far, the panel you’ll need to pay close attention to.

One thing that was less than clear to me when setting up my app in App Wrapper 3 was the About Info credits. In version 2 there was checkbox to include this in the build. In version 3 it gets put into your application. The solution is to simply clear the text field but it’s not obvious. The default text is using my name and information. If I’m creating client builds I will now have to deliberately clear this out before I send to the client. Otherwise, there will be a Credits.rtf file in the Resources directory of the bundle.

For the Mac App Store the code signing certificate will automatically set the Packing for you. For non Mac App Store distribution you have the option of no packing, zip file, or Apple Installer. For us, we distribute via disk image (DMG) so we leave it to none.

The Capabilities panel is all about the App Sandbox and how the app interacts with it. There are a number of things with Sand Boxing that will make your development life a joy. All that fun stuff is beyond the scope of this review but if you’re going to submit to the Mac App Store you should really do some research!

The Info panel is all about setting up the info.plist properly for your app. The top list is what changes App Wrapper will add to the plist and the other sections are for Document Types, URL Aliases, and Uniform Type Identifiers. Some of these are set from Xojo and others are not.

AW Wrapping

The Other panel lets you clean up the application bundle. You can remove subversion remnants, DS_Store files, language files, and whether or not to clean up some of the architecture such as removing any old PowerPC code, or restricting it to Intel 32 bit or 64 bit. You even have the ability to fine tune the files and ignore them, delete them, delete them for the Mac App Store and so on.

To actually wrap your application you have two options. The first is to do it all manually. Drag your built executable on to App Wrapper 3, set it up all up, and simply hit the Wrap button in the upper right corner. You’ll want to do this manually a time or two to make sure there are no major errors.

The second, and probably preferable way, in my opinion, is to hit the Xojo Script button and drag the script file into the Finder and then into your project and put it under the build steps for Mac OS X (supposedly you can go direct from the App Wrapper to the Xojo IDE but I couldn’t get this work). Then it’s just a matter of hitting build in the Xojo IDE. The application is built and the script will use the executable and run App Wrapper in the background. Voila! You have a code signed application that’s ready for upload to it’s final destination (assuming no errors).

In App Wrapper 2 we used the command line option with our own Postbuild script. Version 3 doesn’t appear to allow this so we’ll have to modify our workflow a bit to use it but it doesn’t appear very onerous of a task (at this point). The benefits of using App Wrapper far outweigh the chore of setting it up.

Once your application is wrapped there are a couple of options for testing. The first is to test the application with Quarantine or RB App Checker Lite. Quarantine lets you start an application as if it was downloaded from the internet. This is handy because applications built on your machine are automatically considered ‘safe’. RB App Checker Lite from Rainer Brockerhoff lets you verify the certificate and check the entitlement settings before submitting it to the Mac App Store. Both of these tests are useful.

App Wrapper 3 has three purchase options. First is the 30-day Single User “Pay As You Go” option for $9.99 that runs for 30 days but can no longer be used at the end of the 30 days. The 1-Year Single User plan costs $20. The 1-Year Small Team plan costs $199.99 and lets App Wrapper be used by up to 10 developers. Both the Single User and Small Team options have free upgrades for a year after purchase and allow you to use the application even after the time period is up (no usage expiration).

The Pay As You Go option seems very odd. For a mere $20 you can get the Single User plan and can use it forever. I see no advantage in the Pay As You Go option and, to me, is more of a software rental plan.

[Update:] The 1-Year Single User plan is normally $49.99 but is $29.99 until the end of November.  Sorry for the error.

If you haven’t already checked out App Wrapper I recommend that you do. It is by far the easiest way to get your app ready for Gatekeeper and the Mac App Store. Without it, you may spend a lot of time figuring it out on your own. From experience I can say that Apple’s documentation assumes you’re using xCode so figuring it out for Xojo makes it that much harder.  Ohanaware has already done it for you!

For more information on App Wrapper 3 please visit

Offline Xojo Training with Xojo Trainer

BKeeney Software announces offline Xojo Training Video application.

Xojo developers have had the ability to stream many hours of video from our Xojo Training web app at for years.  Thousands of Xojo and Real Studio developers have streamed well over 10,000 hours of training video from BKeeney Software.

Now, for the first time, Xojo developers can purchase the videos and watch them on their own computer without an internet connection and with no expiration date. Xojo Trainer is available for Mac OS X and Windows and is shipped on a 32 GB flash drive. The drive comes preloaded with all of the videos and Xojo project files.Xojo Trainer

Xojo Trainer allows users to select training videos by section (matching the online version) and to search videos by keyword.  Videos can be resized to practically any size.

Xojo Trainer comes with two complete desktop projects and one complete web app project.  The projects all start from nothing and Bob shows you how to test and debug the applications.  Of course the complete projects are available for you to peruse and the source code is there for you to use in your own projects!

Pricing and additional information can be found at


For years we’ve been doing some basic checking in the WebSession.Open event of our Xojo web apps. First, we check to see how many open sessions we have and if it’s over a preset number.  The second check we do is to see how many open sessions we have for the current IP address. We set it to something low like 10 because when some joker decided a few years ago to prove that Xojo web apps suck. He opened up our training app, and then hit refresh 150 times and then complained about how unresponsive the app was (thus proving his point that Xojo web apps suck, I guess).

In our apps, if either of those conditions is met we use a ShowURL to redirect to one of the webpages on our regular website to show the user that the app is either too busy or something bad happened. It’s worked decent enough that I’ve never revisited it until this past weekend when several users alerted me to the redirect never clearing. Since I couldn’t login to my own app I restarted the server and everything was fine again.

I tend to use a log file on my web apps to track certain conditions and this morning I added more information so I could track this more. I just happened to be monitoring the app (in my browser) when my session count spiked to around 50 in just a few seconds. Looking at the new information in the log file the IP addresses were all over the place.  An attack?  I dunno but it sure seemed like it.

Unfortunately, the session count didn’t go down immediately like I expected it too and, in fact, it didn’t go down even up to an hour later. I had over a hundred open sessions before it stopped (did Xojo Cloud security close the port?).

When that happened I started looking at code. Some of this code I hadn’t looked at in a year or more. Basically the code did the two checks in the WebSession.Open even and if the function returned true I immediately tried to call WebSession.Quit.

Guess what happens when you do that? If you guessed nothing you’d be wrong. It generates a Nil Object Exception first with the following stack trace:

Function WebSession._WaitingForSync() as boolean


Sub _SessionShutdownThread.Event_Run()

And after that then it does nothing. The WebSession never quits – ever – until something kills the app.

My solution was to put a timer property into the Session and if I meets my quit conditions start the timer and in the action event (using AddHandler) quit the Session. Seems to work as expected now.

This is filed in Feedback <feedback://showreport?report_id=35794> and it appears that it’s been verified. There are some additional details on their response. They know why it’s happening at least. Let’s hope this one gets fixed sooner rather than later.

I’ve seen various people have issues with WebSession.Quit over the years. This might be the root cause of some of those.

Subclassing vs Extends vs Containers

Xojo is really powerful because it gives you multiple ways to create really powerful controls.  Today I’ll discuss subclassing, extends, and containers.


First, subclassing a control is really easy to do.  Create a new class and set the super to the control you are extending.  A great example of this is the Xojo ListBox.  In its raw form it’s powerful, but limited, in its functionality.  To have those awesome alternating row colors we subclass the ListBox and put our code in the CellBackgroundPaint event.

One of the things that people forget to do when subclassing the control is to repeat the events that that they are using.  Because I’ve used the CellBackgroundPaint event it’s not available to any instances of the class.  Sometimes this is desirable, but sometimes you want the control to still have those events.

The solution is simple.  Define a new event named CellBackgroundPaint and use the same properties and return value.  This means that you, the developer, can have the alternating colors in your listbox but also still have the opportunity to override those colors if you need them.

The other powerful thing about subclassing is that you can continue to subclass them all you want.  In one of our projects we have the following Listbox hierarchy:  ListBox -> AlternatingRowListbox -> CustomCellListbox -> RecordsetListbox.  Each one is still a Listbox, but each gets all of the events and properties of its supers so this means that the RecordsetListbox automatically gets the alternating rows even though it specializes in loading the listbox by using a Recordset.


Sometimes, though, you only want to add a single method to a class.  Creating a subclass to do this might be overkill, especially if you have to go back and and retrofit this change in a lot of places.  A good example of this the PopupMenu where you often have to set the text of the PopupMenu to some value.  The code is often like this:

for i as integer = 0 to pm.ListCount-1
   if pm.list(i) = sSomeValue then
      pm.ListIndex = i

It’s not hard but after you’ve done this several dozen times you come to the realization that this should be automated somehow because it’s a lot copying and pasting and if you find a better way in the future you’ll hate yourself (trust me, I’ve done this).  You could easily subclass the PopupMenu and go through and change the Super of all existing popupmenu’s, but there is an even simpler way of doing this:  Extends

Extends lets you create your own method that acts like it’s part of the class.  If we were to take our code above for the PopupMenu and put it into a module (it won’t work in class objects like Windows) our code would look like this:

Sub SetText(extends pm as PopupMenu, assigns s as String)
   for i as integer = 0 to pm.ListCount-1
      if pm.list(i) = s then
         pm.ListIndex = i
End Sub

Same code, just using the extends.  What’s great about this is that using it super easy.  It becomes part of the AutoComplete list and is a ‘dot’ extension (just as if it was a subclassed item).  So calling it is like this:

pmFont.setText = sTheFont

I don’t remember when the Extends method was introduced but since it was introduced the number of Subclassed items in our projects has dropped dramatically.  Using Extends fails in one area and that’s Properties.  If you need a property for the additional functionality, you’ll still need to subclass the control and add the property to the subclass.


This final method may confuse some people.  Using a container control isn’t a subclass nor using the extends.  Containers are incredibly powerful controls in Xojo, though, because they allow you to create combinations of controls (and their subclasses) in unique and reusable ways.  A great example of this is a typical Save/Cancel pair of pushbuttons on a dialog or window.  On Macintosh OS X the Save button is on the right and the Cancel on the left.  On Windows it’s opposite.  In Linux, it’s the same order as Windows but the buttons have a different height.

There’s nothing stopping you from adding code to every window that has this Save/Cancel combination so that they’re in the proper location and height.  But why?  This is Xojo, a modern object oriented language!  Plus, I hope you’re as lazy of a programmer as I am because that’s a lot of work.  Use a container!

Create the container, add the pushbuttons.  I named my buttons Left and Right because their function is determined at runtime depending on the platform.  I add an Open event and in that event I add code like this:

#if TargetMacOS then
   btnRight.caption = kSave
   btnRight.Default = true
   btnRight.cancel = false
   btnLeft.caption = kCancel
   btnRight.Default = false
   btnLeft.Cancel = true
   btnRight.caption = kCancel
   btnRight.Default = false
   btnRight.cancel = true
   btnLeft.caption = kSave
   btnRight.Default = true
   btnLeft.Cancel = false

The kCancel and kSave are dynamic constants holding the proper strings.  In the ActionEvent of the buttons I have code like this to raise an event to tell the parent container (a window or another container) what happened:

Sub Action()
   #if TargetMacOS then
      RaiseEvent Action false
      RaiseEvent Action True
End Sub

Sub Action()
   #if TargetMacOS then
      RaiseEvent Action true
      RaiseEvent Action False
End Sub

And finally the Action event which I’ve defined is:

Event Action(bSave as boolean)

It’s really as simple as that!  No matter which platform I’m on the Action event from this container tells me if the user pressed save or cancel.

Why did I include Containers in this article?  Good question!  It’s because you can think of Container Controls as a way to subclass Windows or WebPages without it being a window/page.  You can reuse Containers as many places as you want and when you change the original it changes the children (be aware though that there are some caveats with this statement – especially with WebContainers).  And even better is that you can dynamically add and remove containers at runtime.  Adding them is simple by using the EmbedWithin commands and to remove them use the Close method (I always set their visibility to false first).

We use a LOT of containers in our consulting work.  We find that it tends to simplify the code (remember being a lazy programmer isn’t a bad thing).  We’ve had windows/pages that have thousands of control and hundreds of controls visible at any given time but with a UI that complex we like to break them out into Containers.  So rather than having a Navigator with a listing of thousands of controls (and their labels!) we break it out logically into containers and the Navigator has maybe a dozen containers instead.

Each container has Save, Load, Validate set of methods (sometimes this is using an Interface) and whatever other methods are required but the point is that the overall window/page doesn’t need to know, or care, what the individual controls are and how to load, save, and validate their data – it only has to know enough to call the Load, Save and validate methods in each container.

With Xojo for Web, containers are even more important because you can create ‘repeating rows of controls’ that are very complex.  We wrote an entire accounting application for a client in using Xojo for Web and as you can imagine creating an Invoice Line Item row that needs Qty, Price, Amount, Sales tax and the necessary UI to add and delete the row, void a row, make it non-taxable can be complex.  Sure, we could have come up with a UI that doesn’t have that in a list, but frankly, it’s not that hard using WebContainers.

Containers are very powerful things and a great way to combine controls into one unit.  It’s also a way to create a dynamic control that can easily be added a runtime.  Rather than using a ControlSet (i.e. control array) and cloning an existing control (and having to keep track of the index) you can dynamically place your container that holds your one control.  We don’t use this technique very often but it does come up every now and then.


Subclassing a control in Xojo is pretty easy but sometimes overkill.  Using the extends method works great if you’re adding methods to a class/control and don’t need to add any properties.  Containers are powerful constructs that let you combine controls into a reusable object that have their own events and that can be added dynamically.  As a Xojo programmer you should be familiar with all three methods.

Did I forget anything?

New Video: ServerSockets

As a companion piece to the video from earlier in the week we added a new 38 minute video today on using a ServerSocket that allows your Xojo application to communication with multiple client apps that are using TCPSockets.  It turns out that it’s incredibly easy to use if you understand TCPSockets (which hopefully you know better now with that video).

I was chatting with an old developer friend this morning that I wish I had made this video a number of years ago when I was beating my head up against the wall on a big project that was using TCPSockets and ServerSockets.  Hopefully this gets you over the hump and you get some use out of it.  My pain is your gain in this case.

In this video we create a TCPSocket subclass on the ‘server’ that handles all of the communication details with the client apps.  The ServerSocket is a pretty dumb object (since it knows nothing about about our communications protocol with the client apps) but it is a pretty powerful class since you don’t have to do much to communicate to the clients other than provide a socket.

Our client apps can send a command, a single file, or a folder full of files.  Each client could potentially send a file with the same name and it would keep track of it properly.  We wrap up the video with having the server app send a message to all of the connected clients.

Direct link for subscribers:

New Video: TCPSockets

Today, I added a new video to our Xojo training area. This new video guides you through the steps to using TCPSockets in your Xojo applications. In this nearly 90 minute video we create a sender application and a receiver application and by sending some simple data (a command and data) to the receiver to make sure we’re processing everything properly.

Then, we send a file (of any size) from the Mac sender app to the Windows receiver app. We do some basic file metrics to make sure the file we receive is the same as we sent. In the video I forget to unpack part of the data properly and it’s this file checking step that finds the problem (sometimes doing something wrong is instructive in these videos)!

Screen Shot 2014-10-08 at 10.16.38 AM

After that, sending a folder full of files is no big deal and in the video we clearly see that the sender has a queue of files that it’s going to send in multiple data segments, and the receiver only has a few of the segments yet.

Finally, we create an acknowledge message that gets sent back to the Sender application proving that we can have two way communication between the applications.

We now have over 55 hours of training video of Real Studio and Xojo.  Since we rewrote the training area using Xojo for Web we’ve served up over 8,700 hours of streaming video to thousands of developers around the world.

Data Paging Control

A lot of Xojo developers don’t give too much thought to how much data they’re loading into a listbox. For many desktop apps a couple of thousand rows is not uncommon and, frankly, not a big deal. Push that to ten thousand rows and things start to get dicey and when you get to a million rows you’re talking some serious wait time for all million rows to get added to a list box.

For web apps it’s even worse. When the server gets the request to load a WebListbox with a million rows it has to build all of the HTML, first, on the server, push it down the internet connection to your browser, and THEN the browser has to reconstruct those million rows of HTML into a display. Any time you deal with strings there is a performance penalty and needless to say a million rows of data is huge hit to performance.

Trying to show the user a million rows is bad on multiple levels. First, your application is slammed with unnecessary string handling and second, the user can’t possibly handle a million rows of data. The listbox scrolling alone would be a nightmare! Just don’t do this!

Web apps have been using paging controls for years to limit the amount of data the user sees. I’ve seen some web sites limit this data to 100 rows and some to even less unless the user specifies more. That way the onus is on the user for the webpage being slow.  And more recently I’ve seen more desktop apps limiting the amount of data too.

Data Page Control

Today we released a new 48 minute training video showing you how to build your own paging control in Xojo desktop and web apps. We build the Paging Control using a Container Control and standard controls and then use it control a listbox. Then it’s a matter of using the SQL keywords LIMIT and OFFSET to control which records are returned. Of course the video comes with a desktop and web project file with source code you can use in your own projects.

The running example of the web app is at

This video is available to subscribers at

If you’ve not looked at our training videos you might find some interesting things. I invite you to take a look!

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
   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
   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.


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:




     return moSecurity
End Get

   moSecurity = value
End Set

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

     if moSecurity = nil then
   moSecurity = me.LoadSecurity

return moSecurity

End Get


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

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?