Are You Still Using Real Studio?

Xojo has been out for about a year and half now.  Based on comments in the forums and on this blog I’ve come to the conclusion that a fair number of people are still using Real Studio.

For some it might be the Navigator.  For some it might be supporting older operating systems that Xojo doesn’t support.  I am curious on what your reasons are for sticking with Real Studio and not going with Xojo.

Thanks for the comments!

Civility in the Internet Age (Part Two)

Back in 2007 I wrote a post about Civility in the Internet Age.  I think it’s even more appropriate today as more and more things go online and it’s practically the only way to communicate with each other.

One of my goals as a blogger is I *try* to be sensitive to the feelings of others.  I *try* to imagine the person I’m talking to is sitting across the table from me because there are things that I would never say if I were face to face with that person.  I would hope that our conversations are spirited, sometimes loud and boisterous, but we can go have a drink and joke about it afterwards.  If an apology is needed I’m not above that either.

I am a passionate person.  I tend to jump into things both feet first the not worry about the consequences until later.  Firing off a heated response on a forum or an email is not a good way to handle things.  Slowly I’m learning that no response is sometimes the best response (I’m still working on this).

I try to not make things personal.  I mainly blog about Real Studio/Xojo developer issues and have since 2007.  For my company to succeed I need Xojo to succeed.  I can be critical of the product and company AND be a supporter at the same time because at the end of the day, I need the best product I can get.  It supports me, my employees, and our respective families.

I’ve been involved with the Xojo community for over ten years and I count most of the people that work at Xojo Inc as friends.  I have no grudge against them and if anything I’m in their corner because I figure if the product makes my life harder it must be doubly so for them as they’re ‘eating their own dog food’, as they say, since the Xojo IDE is written using the Xojo IDE.  In my opinion, that’s quite an accomplishment, and one of the reasons why, despite the warts, I’ve been a Real Studio and Xojo developer and supporter all this time.

In the past six years I have generated a lot of responses from my blog posts.  I’ve received hate mail as well as some where people felt my analysis was spot on but couldn’t say so publicly.  I have been accused of being a shill for the company, inciting a mob, for personally delaying releases, and having an ‘agenda’ or two.  I find it hard that I am all of these.  Maybe I’m simply just a blogger saying what is on my mind (and occasionally on the mind of other developers).  If you disagree, that’s fine, I respect your opinion, because we all have one.

Why I Hate the Xojo Navigator

I’ve been using Xojo since it was first released to Alpha testers in early 2013.  There are many things I like about Xojo but the Navigator isn’t one of them.  In fact, the more I use it the more I despise it.  The reasons are many and varied and in talking with other long-term users they have their own hot button list.

Lets give a little history of what the Navigator replaced.  In REALbasic and Real Studio there was always one tab that could not be closed – ever.  This was the Project Tab and it only contained the project items in your project.  This included windows, menubars, the application class, any classes or subclasses you created, interfaces, Build Automation steps, etc.  You can then organize however you wanted by recording them and adding folders for organization.

The interface was simple.  You double-clicked on an object and it opened in a new tab into whatever editor was required.  Very simple but many developers, myself included, commented on what a pain it was to manage the resulting tabs.  You’d open objects and eventually you’d run out of tab space or the tabs were so tiny you couldn’t read the names of them.

But there were built-in ways to help manage tabs.  Contextual menus let you close other tabs, or all tabs (except the Project Tab) and, in general, it wasn’t difficult to deal with.  It was simple and there was a very clear division.  The Project tab always had objects and once you double-clicked into it you were taken to an editor.  That might be the Layout, Code, or Menu editor where you got into the details of that object.

In Xojo they introduced the Navigator and it was supposed to make our lives easier and eliminate those pesky tabs.  It contained every item in your project.  Not only all the objects, but you can expand the object to see every control, method, event, constant and property.  As you double-click the object tree it exposed more level of detail.  Click on a control on a Window or Page and it opens the Layout Editor.  Expand the control to show an Event and click on it and it opens the Code Editor.

All-in-all it *sounds* like an improvement, right?  In my not so humble opinion, absolutely not.  Any project of any size will contains hundreds of objects.  Each of those objects could have dozens or more other objects and depending upon what the object is (like say a module) it could conceivably contain thousands of additional objects.

Meanwhile, this simple hierarchical list keeps getting larger and larger as you keep expanding objects.  The scrollbar thumb keeps getting smaller and smaller until it’s as small as it can get.  This means your list is freaking huge!  Conceivably you have all your widows in a single folder but now the listbox subclass you’ve been working on is somewhere in this huge list.  Good luck finding it by scrolling through the list.

Despite the fact that tab management was a factor in designing the Navigator, Xojo still lets you put objects in tabs.  There are two ways to do this.  The first is to contextual click on the object and say open in new tab.  The other way is to set it in Preferences to open double-clicks into a new tab.

Currently, double clicking on headers (like Events, Methods, Properties, etc) also opens into a new tab rather than just expanding that section (in the same tab).  Tab locks are supposed to keep you from navigating away from the object but this doesn’t work in R1 and R2.  Presumably this will get fixed at some point but these two bugs make tabs less than ideal and difficult to use.

After months of working with Xojo I find myself getting lost a lot and trying to ‘find’ where I am.  In the effort to make this easier they added filter field so we can easily find our objects in the list.  It works but there’s a caveat.  If you’re trying to find that lisbox subclass buried in the list searching for ‘list’ will bring up every object, method, property, etc., that contains ‘list’ in the name – and you’ve lost the hierarchy so you’ve lost context even though the name is fully resolved.

Because the Library doesn’t hold your control subclasses (like the old Real Studio control palette) you have go hunt them down in the Navigator.  If anything, this is the one spot where the filter works well…assuming you know the name of your control.  For us this isn’t a big deal because we (mostly) adhere to fairly strict naming conventions but I know plenty of people don’t and if you’re using 3rd party controls who knows what their naming conventions are.

One of the nice things about the Navigator that the old Project tab couldn’t do was cut, copy, and paste multiple items.  The Project tab only let you manipulate one object at a time where the Navigator theoretically lets you do multiple objects at once.  I say theoretically because it doesn’t always work.  Practically the only way I can get it to work (consistently) is if I use the contextual menu to manipulate the items.  Use the keyboard shortcuts (helpfully listed in the contextual menu) and you might be duplicating an event (thus causing it to become a method and thus a compiler error later on).

The old Project tab showed you the super of all of your subclasses and showed you the interface if it had any.  These were shown in columns to the right of the object name.  Sadly, this was left out of the Navigator and the only way to see what the super and interface of an object is to hover the mouse over the object until the tooltip shows or select the item and view it in the Inspector (assuming its open).  Even then, interfaces require yet another click to get that information in a separate dialog.

The Navigator is broken down in to three distinct groups:  Contents, Build Settings, and Run.  Run is only shown when the user is attempting to debug an application.  You’d think this wasn’t a big deal but unfortunately finding that Run section in a big list can be challenging.  One quick hint is to click the Resume button so it switches to the proper tab and highlights the Run section.

The Contents section is mainly what we’ve been talking about.  You can collapse this section but I have to wonder what the point of allowing the user to collapse and expand the entire contents of the project really is.  I can think of no legitimate reason other than to say that it’s possible.

The section that really burns me is Build Settings.  When you click on an item in this section it forces the Inspector to open displaying the settings for that item.  The Shared Settings used to be in the Application object.  While one could argue that the application object wasn’t the right place to put them, they were only slightly obnoxious there.  Putting them in a list that gets outrageously hard to deal with make it an odd choice.

The pseudo looking checkboxes are indeed checkboxes (no where else in all of Xojo is this control used) to control which platforms you build for.  If you’ll remember this used to be in a separate dialog called Build Settings.  You typically used it sparingly because how often do you need to change your app name?  Again, putting this in the Navigator seems like a choice that started with the sentence, “Wouldn’t it be cool if we put dialog type information IN the Navigator?”  The answer should have been a resounding no!

In Real Studio the Build Automation settings had their own object.  In Xojo, they are now in the Build Settings section.  This sort of makes sense as the platform choices are already there.  However, when you add a Build Step to you project it’s placed in the Contents section and to use it you have to drag it into the target of your choice.  This is not an immediately obvious choice.  Presumably if you don’t drag it to the target of choice it performs those Build Steps for each platform (I have not tested this).

Add on top of all this is the animation in Mac OS X.  Change a selection and the highlight bar gracefully transitions from the old selection to the new one.  Expand an object and you can see it populate.  Eye candy pure and simple and completely superfluous to me as a developer.  I highly encourage you to turn Animation off.  All it does is slow it down.

I remain unconvinced after half a years worth of use that, in its current form, the Navigator is worth the time and effort Xojo Inc put into it.  A lot of effort went into the animation effects when basic functionality is either missing or currently broken.  All-in-all the Navigator is a good concept that falls far short of expectations in the rigors of all day use on medium to large projects.

Am I wrong or do you agree?  What do you love or hate about the Navigator?

Xojo Calendar Classes 1.0.3

WeekViewWe released a minor update to our Calendar Classes today.  In version 1.0.3 we fixed a bug that prevented multiple day events from drawing properly.  We also added a new event so users could use their own localization on the Hour formats.

The BKS Calendar Classes is canvas subclass allowing you to have Month, Multi-Week, Week, and Daily Views (24 hour view) calendars for your Xojo and Real Studio applications.  We have two versions, the Standard license is an encrypted set of classes and for those needing to get to the full source code we offer the Professional license.

More information at http://www.bkeeney.com/calendar-classes-for-real-studio/

RB Code Reports Updated

appicon64We updated RB Code Reports today after we realized that it wasn’t reporting properly against Web Edition projects.  The Statistics Report now shows Container Control, Web Container, and Web Page counts.  It did not before.

We also added a preference for the Signature Report so that you can now specify the scope of the signatures you want in the report.  For example if you wanted only Public, Protected, or Private methods/properties you can now filter on them.

It’s interesting.  Our big Web Edition project is now getting rather large.  228 Web Pages, 173 Web Containers and a little under 65,000 lines of actual code.  I estimate that we are less than 50% done.  We are definitely pushing the edge on Web Edition.  Fun, eh?

RB Code Reports Version 3.0.5 is a free update for all registered version 3 users.

For information at https://www.bkeeney.com/rb-code-reports/

BKeeney Shorts Progress

picAppIcon256It’s been a little over a month since BKeeney Shorts, our Real Studio/Xojo reporting classes, were released to the general public.  All I can say is thank you!  The response has been tremendous and has exceeded my wildest explanations.

We’ve been working on a few updates this week.  First, we can now search a report for specific instances of a string.  This wasn’t on our radar but during the Xojo Developers Conference someone blurted it out during our training day and it got me thinking.  It turns out it was really easy to implement.

One of the things that Shorts does is has all of the pages available to the document and all of the objects on the page available to search so it ended up being an incredibly easy thing to do.  We don’t really ‘render’ the page until it’s called for.  In the demo app we added the search function and also created a list to show which pages the instance is on.  I think you’ll be really happy with it.

The second thing we accomplished this week was to get RTF Text blocks mostly working.  RTF is a particularly troublesome format to deal with because you have to convert from RTF into something that Xojo understands (StyledText) and then figure out how to draw it because we can’t use the standard TextArea.DrawInto command because our Page display can zoom in and out and also deal with Retina display on Mac OS X.  What a pain and I’ve already been able to get it to fail if I make the RTF even remotely complicated.

The conversion to HTML and PDF has gone relatively smooth but there are some minor glitches to work out there too.  Few conversions are 100% perfect and the trick is to get it close enough so most people are happy with it (or at least don’t send angry emails).

So what else is coming up?  That’s always a tough question to answer.  One of the things we really need to get into the product is automatic text block height calculations.  You provide the string, block width, and characteristics and it returns the height.  You can do this on your own now but it’s not nearly as easy as it could be.

The second thing that I really think would be cool for a Xojo application is runtime interaction with your report and receive events when a user clicks on a report object.  Imagine if you will an account balance report.  You see that account 10100 has an unusually high balance and rather than go back to the report screen to create a report on that account you simply click on the account.  The Shorts viewer receives an event, and the smart developer responds to the event and automatically creates a drill down report on account 10100.  I know of no other reporting tool in the Xojo world that is doing that.

Then there are some of the obvious needs.  We really want to add a designer control allowing you to visually create reports and then save that format into an external file so that in the long run reports don’t have to be compiled into your application.  Client wants a tweak to a report?  Find, send them the new report definition file and voila, it’s done.

I’m sure I can come up with a half a dozen other things I want to see in the product.

Some of the comments we’ve received about BKeeney Shorts so far have been awesome.  Things like it being easy to import into an existing project, fast in creating reports (about 300 pages a second!), and thanking us for wonderful support are all really cool things to get in your email in box.

That’s my quick update for BKeeney Shorts.  What sorts of things do you want to see in a reporting tool for Xojo?

Xojo: Inspector in Windows

Based on one of the comments from this morning I captured some screenshots of Xojo in Windows 7.  Hopefully this time you can get the side-by-side comparison in the post.  The only thing I’ve done is stitch together the Inspector image so it’s one continuous image.  I think I would have to agree that even in Windows it ‘looks’ like a Mac OS X app and I’d say that’s probably not a good thing for most Windows users.

 

RealStudioWindows XojoWindows

Database Primary Keys

The primary key that you define for your tables is critical to a well performing and well designed database.  The primary key to your table is very important so it’s worth spending some time on it BEFORE you start coding.

Let’s start out by describing what the primary key does.  The primary key is the unique identifier of a record for each table.  Regardless of how many rows the table has in it, the primary key is the pointer to a particular row.  This key will never change during the entire lifespan of the row.  There will never, ever, be two records with the same ID.

The primary key should never change.  This is why using a text field as a primary key that contains human readable/changeable data is such a bad idea.  I’ve worked on databases where they used Name as a primary key.  This is such a bad idea especially in cultures where women change their last name when getting married.  Even exempting female name changes most places in the world allow you to change your name legally.  Since it can change it’s a bad idea for use as a primary key.

Another example that we’ve dealt with in the past is using a Social Security Number (national id).  Another bad idea for a number of reasons.  One, data entry mistakes happen.  Two, government agency mistakes occasionally happen where there are two (or more) people with the same SSN.  Three, it’s not uncommon in certain parts of the country where undocumented workers use the same SSN.  Four, identity fraud is common.  Because this means it’s possible for two people or more people to have the same SSN it’s not a unique identifier.  Avoid using it.  It’s  a bad idea.

We recommend using an auto increment integer primary key.  Let the database do what it does best and let it pick it out for you.  That way there will never be any collisions or duplicates.  It’s what databases do very well all on their own.

I’ve worked on projects where there was no auto-increment primary key and was defined as an integer.  The developer devised a scheme to get the largest record ID and increment it by one when needed.  This was fine when a single user used the app but when multiple people were inserting data at the same time collisions occurred generating errors because primary keys must be unique.  It was ugly to fix and it all would have been avoided if they had used an auto increment primary key to begin with.

Someone asked me the other day if ActiveRecord could use a text primary key.  No, and it won’t ever.  It expects an integer primary key.  If you ARE using a text primary key.  Stop.  Add an auto-increment primary key and then add a Unique Index on the text field.

Real Studio/Xojo has some interesting things happen if you try to open a recordset that’s not returning the primary key in the query.  It won’t be able to update it in some cases.  You’ll get a generic message about not know which record you’re trying to access.  I’ve had some issues, in the past, using many-to-many tables that couldn’t be edited even though they had a unique index on fields.  So I recommend adding an auto-increment primary key event to many-to-many tables.  Then, if you have constraints on your index (like the index needing to be unique) you can add them there.  So far it’s worked for me.

For primary keys we use a standard naming convention:  tablename_ID.  A lot of people use a generic ID field but we’ve found that to be less than ideal when doing table joins.  If you have table A, B, and C all with an ID field joining them together means I have to put an alias in my SQL statement so I can retrieve those primary keys later.  By using the A_ID, B_ID, C_ID I never have to alias the field names in a query.  Plus, it has the added benefit of making the SQL easier to read because the name is explicit and the _ID tells me its a primary key.

Each database has its own internal record id.  SQLite uses rowid and you can actually query against it.  If you haven’t specified a primary key in your table it will use that rowid as the primary key.  When you specify a primary key, the specified primary key and rowID are the same.  However, if you do not specify the primary key the rowID is not guaranteed to stay the same.  If you were relying upon rowid to identify records in other tables you might be putting yourself in through a world of hurt if the user ever does a vacuum on the database.    The moral of the story is don’t rely upon the internal id – always specify your own primary key (that auto increments if you haven’t heard it enough now).

If you get into the habit of using an auto increment integer primary key you’ll avoid many problems later.  You don’t have to use our naming standard for primary keys but doing so will improve the readability of your SQL statements.  Primary keys are too important for anyone/thing but the database to figure them out.

Happy Coding!

Training Day Video Online

We held a full day of training the day before the Xojo Developer Conference (where we couldn’t use the term Xojo yet) on April 23rd.  We had over a dozen people at the training day where we discussed what we knew about databases.  We did that for most of the day and then spent the rest of the day going over 3rd party plugins, controls, libraries, and utilities to help you get your Real Studio/Xojo apps going.

We recorded all of it and have rendered it all (except a 30 minute portion where the mic wasn’t on) and made it available for our Real Studio/Xojo subscribers (as well as attendees who got a year subscription for attending).  It is now available online at http://www.bkeeney.com/RealStudioTraining/realstudiotraining.cgi

Because it’s Friday and I don’t feel like doing any real work, I decided to pull some stats about our Real Studio training app:

It was originally written in a fairly popular web CMS framework.  It was re-written using Real Studio Web Edition (because we could) and went live in late 2011.

We have 39 hours 44 minutes of Real Studio training video available.  A little over 6 hours of it is available to non-subscribers.

We have served up over 4,800 hours of streaming video since we began tracking it.

We have a little under 1000 registered users on the web app with about 100 current subscribers.

Web Edition has been interesting.  The training area has been our test bed of new for new versions of Real Studio Web Edition and now for Xojo.  It continues to grow as Web Edition gets better.

Browser stats actually surprised me a bit.  FireFox is stronger than I anticipated and Chrome is much higher than I expected.

Likewise, platform usage surprised me a bit with Windows users at 41 percent.  I know very few Windows-only Real Studio/Xojo users so perhaps this just indicates that I travel with a Mac-centric crowd or a lot of Windows users are looking at Real Studio/Xojo and need some additional help.  When I get a chance I’ll have to see if I can figure out the stats of subscribers vs. non-subscribers.

Browser Usage

 

Platform

 

The New Xojo Framework

Xojo, Inc. has talked a lot at XDC (Xojo Developers Conference) about their new upcoming framework.  The reasons for a new framework are many and valid.  Among them are consistency, a need to serve desktop, web, and soon to be iOS applications, and to remove archaic methods.

This sounds kind of scary because most of us have been using the existing framework for many years.  But in reality I don’t think this is a bad thing.  How many times have you been bitten by framework calls that are one-based rather than zero-based to name just a few.  The new framework promises to make everything consistent across the entire Xojo universe.  All arrays/lists will be zero-based and methods are more explicit in their naming.

Furthermore, UI controls will become portable between desktop, web, and iOS.  In the current framework a desktop button is not portable to web button and visa versa.  While this isn’t too horrible, it makes life a bit more difficult as you have to create new instances and then copy the code from the events from one to the other.  The new framework means that a button is a button is a button regardless of platform.  There will be SOME differences as there are some platform specific controls (iOS has views, splits, tab bar, etc) that have no equivalent on the other platforms.

The Xojo framework has several main modules:  Core, UI, iOS, String, Color, Number, Math, Media and a few others.  They’ve also added a number of common interface elements that I suspect will become a very big part of the framework.  The Core framework has common items like Dictionary, Point, Rect that will be used by other parts of the framework.  In today’s framework you would create a Dictionary object like:

dim d as new Dictionary

In Xojo it would become:

dim d as new xojo.core.dictionary

Not a huge difference but enough that I’m sure will tick some people off.  But what this gives you are new methods that are unique to the Xojo framework that are very useful like ValueOfKey and RemoveByKey.  Not that those do anything different than Value and Remove in the existing framework but they are more explicit in their use.

Strings are another change in that strings now are zero-based to become consistent across the entire Xojo universe.  But otherwise most functions are part of the Xojo.String module.  All the usual suspects are there but new functions that are more explicit are also available.

The new framework is a requirement for iOS.  When it ships it will NOT be able to use the old framework.  Shortly after the iOS release it will be released for Web and then shortly after that for desktop.

The good news is that the old framework and the new framework can be used simultaneously (exception iOS) for years to come so it probably won’t mean much to anyone for a while.  When I asked Xojo, Inc. when they’ll drop the legacy framework they really had no answer.  I suspect like many deprecated things from Real Studio it will take a while.  So there’s no need for panic.

The new framework should make life easier for all of us in the long run.  It’s not going to be a quick transition and we won’t be forced to use it.  I’m okay with it because I’m sure there will be a bunch of other things to worry about more.  Welcome to the future.