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!
There have been a number of trips down memory lane this week regarding the Macintosh so now you’ll have mine. If you’ve been living under a rock you may not know that the Macintosh was introduced 30 years ago this week. It truly changed computing and it certainly changed my course in life.
I entered college in the Fall of 1985 to become an electrical engineer. While PC’s weren’t unknown at the time they were still expensive enough where they weren’t common. In the fraternity that I joined, they had two(!) IBM PC’s sitting in the basement ‘computer room’. We were praised by the national fraternity for having all of our books on Lotus 123. Looking back how quaint.
As with any fraternity we had our various committees and in the Fall semester of 1986 I ended up being the chairman of the Parents Committee and it was one our charges to send a newsletter out to parents to inform them of all the great things their kids (and money) were doing. For many years we had people that worked at the newspaper and had access to the Linotype machine where we could print out the text at high resolution, lay it out on boards for printing. That semester we had no one on staff and I was scrambling to figure it out.
One of the older Brothers worked at the school computer lab. He mentioned they had these new Macintosh computers and this thing called a LaserWriter printer that was ‘very cool. He handed me a copy of MS Word and Aldus PageMaker and told me to go figure it out (ah the days before anti-piracy solutions). I was reluctant but curious and got to play around with the two apps on a Macinoths plus.
I was intrigued and hooked. I had used quite a few different types of computers, TRS 80, Apple II, IBM PC’s, Atari to name a few but the Mac was something special with its 9 inch black and white monitor and its mouse where you pointed and clicked and dragged things in a What You See Is What You Get (WYSIWYG) environment. It was SO intuitive. If you didn’t know the exact command you could find it in the menu’s.
My parents newsletter went out with relative ease and our chapter won an award for innovative newsletter. The following semester I was in charge of the Alumni Committee and we won an award for the newsletter we did then too. From then on I can’t tell you how many newsletters I did for the fraternity. Again, looking back on 30 years they’re pretty cheesy but superb for the time.
This was an engineering school so we were predominantly IBM PC’s (this is long before Windows came into play). Our classes expected us to use PC’s, the software was PC only and I stuck out like a sore thumb. It was common practice at the time to do all lab reports by hand and to use very expensive chart paper to hand draw lab results and it took many hours to make nice graphs. I pissed off more than a few classmates off by turning in my lab reports done on a LaserWriter where I used Word, PageMaker and a charting app to chart my data. The lab TA’s were impressed with my reports despite having crap data and questionable results. This is when I learned that making it user friendly and looking pretty counts.
The rage of the era was attending Mac User Groups, or MUG’s, where you could meet with like minded Mac geeks and talk about the software you were using, get questions answered, etc. I started one at school. I had my own MUG newsletter (for the 30 engineering students that actually liked the Mac). I hooked up with other MUG’s in the Chicago area and got involved with them and because of that involvement was able to help pay my way through school doing Mac training and graphic design (okay I wasn’t very good at it but I was better than most desktop publishers of the day).
One Fall (I think ’88, or maybe ’89) I went to a MUG conference in Ann Harbor, Michigan. The keynote speaker was Bill Gates (really!) and he spoke about how well Microsoft Word, Excel, and PowerPoint versions 1.0 were doing on the Mac. His engineers held breakout sessions that lasted ’til the wee hours of the night listening to what Mac users thought needed improving. I even shook Mr. Gates’ hand when I passed him in the hallway. Despite having more money at that point than I’ll probably ever have, he was just your average computer geek. Go figure.
That conference also happens to be the first place I saw my first 1 GB drive. It was the size of a suitcase and cost a couple of grand. As we all filed past we kept muttering, “What the hell would you have that needed something that big?” Remember, operating systems lived on a 1.5 megabyte floppy drives back then. We were so naive.
At times it’s been a very long 30 years. I remember the mid to late 90’s. It was an ugly time to be a Mac user. Windows was king of the hill and every year there were fewer and fewer of us. Even though I was using a Windows PC at work I always came home to a Mac where I was writing software for fun. I used Think Pascal and Metrowerks CodeWarrior. I had learned Pascal in college but learned C and C++ on my own. CodeWarrior was a great development environment in my opinion.
When I finally was smart enough to switch careers – okay my soon to be wife told me to find a job I liked before we got married – I found Visual Basic and Access gig. It was decent and I did learn to appreciate what Microsoft had done in terms of wiping out alternatives and becoming ‘the standard’. However, DLL hell and compatibility problems were still issues that plagued even 100% Microsoft shops.
I landed a development job working for an exclusive CodeWarrior shop doing very early Mac OS X development work. They did a lot of fun stuff but they wanted to do some rapid prototyping of an app idea and since I was the new guy in the office they told me to look at this thing called REALbasic. I did and without too many issues I created a proof of concept for a photo storage and management application – the iTunes for photos if you will. Sadly for all of us, iPhoto came out just a few months later and killed the project. But my intrigue for REALbasic remained and I kept working on small projects and when it could do Macintosh AND Windows builds with just a click of checkbox I was sold! It was the best of both worlds.
One thing that I recall vividly was my reaction when Microsoft was officially convicted of being a monopoly. I was sure they would NEVER again have 95% marketshare because the only way they got it initially was to do it illegally. So far history has proven me right. Of course the iMac, iPod, iPhone, and iPad have had something do with it.
When I started doing REALbasic (now Xojo) consulting 13 years ago few people cared about Mac versions of their apps. A few years later when the iMac and iPod started to reinvigorate Apple it was a common theme to do a Mac version to keep the boss happy. Nowadays, nearly all of our consulting clients want a Mac version first and if we can do a Windows version to keep the accountant happy (who is running some accounting app that’s still Windows only) that’s great.
Thirty years is a good chunk of my life. I can remember life before the Macintosh but working on that first Mac literally changed my outlook on life and put me in a different path. There are a lot of things about the Mac that made me a rebel, but also set the quality bar high. I’m still willing to pay more for things that are of better quality from cars, to tools, to hiring contractors that work on my house because I firmly belied that you get what you pay for.
The Mac inspired me for 30 years. I’m hoping it will for another 30. Happy birthday, Macintosh!
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.
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?
We 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/
We 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/
It’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?
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.
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!