Xojo: the Best Secret in the Programming Industry Part 1

Xojo turns twenty years old in 2016.  That’s an extraordinary feat not only for a business but even more as a development tool.  The simple fact is that 90% of all businesses in the United States fail within two years.  There’s a significant number of the remaining businesses that fail two years after that.  Xojo has beaten the odds from a business standpoint.

When it comes to software development tools and languages it seems that every time you turn around there is another programming language of the moment that is the hot, hot, HOT thing that everyone has to learn and then two years later it is relegated to old, has been, technology.  Each one promises to make software development easier and faster and in most cases they solve A problem but not necessarily all problems.  In reality, every development tool still requires a competent programmer to do some work – you get nothing for free.

Xojo has been renamed multiple times first as REALbasic and then as Real Studio but in each name iteration it’s been the same product:  a rapid application development platform and language that creates compiled desktop, console, and web applications native for Mac OS X, Windows, and Linux.  Not only in 32-bit but also for 64-bit.  For a vast majority of users it really is as simple as checking a box captioned “Windows” to create a fully functioning Windows application that works the same as the one you’ve create on the Mac or in Linux.

Xojo started out twenty years ago as CrossBasic before Real Software Inc purchased the rights.  It was modeled after the very successful Microsoft Visual Basic and those roots are still visible today.  Xojo initially ran only on Macintosh but within a few years it ran on Windows.  It now runs on Linux too.

Xojo has transitioned from 68k Macintosh desktop apps, to PowerPC apps, to Carbon apps, and finally to Cocoa apps.  Recently they transitioned from 32-bit applications to 64-bit applications for Mac OS X, Windows, and Linux and introduced Linux ARM as a new target.  This transition is still in progress (the IDE is still 32-bit and remote debugging isn’t available for 64-bit yet) and they’ve announce more transitions on the Windows side to start moving away from the venerable Win32 framework for some things.

Besides desktop apps Xojo also creates console and web apps.  Web apps are a different beast as they expect to keep a constant connection between the browser and application on the server.  This makes web apps work a lot like desktops apps and eliminates a host of typical web app issues.  These web apps can be deployed as either cgi applications or as standalone apps.  The cgi applications work with Apache or IIS servers.  Standalone builds require no server and act as their own server which makes them very easy to deploy to any Mac OS X, Windows, and Linux machine.  Much of the code used in a desktop app is reusable for web apps.

A few years ago Xojo introduced the ability to create iOS applications which introduced yet another target.  iOS transitioned quickly from 32-bit to 64-bit after one of Apples famous ‘deprecations’.  iOS built under Xojo works with the iOS Simulator that comes with Xcode to accomplish remote debugging.  Just a few weeks ago Xojo announced that in late 2017 Android will become another target.

Xojo is an integrated development editor, or IDE, that allows a developer from within one application, to write all the code, layout all the user interface, and include any resources necessary for it to work.  It has a series of built-in editors that mostly mean you’ll never have to leave the Xojo IDE.  Working on desktop, web, console, or iOS projects expose the available libraries and controls for those targets.

Xojo lets you compile final executables or do remote debugging to any of the supported platforms.  So while working on Mac OS X I can remote debug an application in Windows running on another machine on the same network or in a VM environment.  While remote debugging, any exceptions that occur in code are revealed in the IDE and users can view variable values and see the call stack.

These things are nothing spectacular by themselves because many development tools can do them.  What makes Xojo remarkable is that is does this regardless of what platform you develop on.  A Windows developer, Mac OS X developer, and a Linux developer get the same capabilities and can deploy to any of the other platforms.  The only exception is that to do iOS you must be using a Macintosh and have Xcode.

Like any tool it has its detractors but it’s managed to transition, quite quickly at times, due to sudden announcements from Apple (who thought they’d move away from PPC?  Or iOS apps would be 64 bit that quickly?) and from the inevitable changes from Microsoft, and the sometimes daily changes in Linux distributions.  Some users complain about the number of bugs introduced in new releases or that bugs sometimes go years without being fixed.  It’s my opinion, though, that every developer complains about those things in their development tool of choice.  Xojo averages a release every 90 days (with the occasional dot release) and always add some new features and fixes many bugs.

The Xojo community is incredibly welcoming to new people.  There is not a lot of condescension given to new users that ask simple questions on the Xojo forums.  Unlike some other venues there is not a lot of vitriol going on.  The Xojo engineers frequent the forums and answer questions.

Since Xojo has lasted twenty years they’ve already beaten the odds.  There is every indication that they’ll be around many more years.  They are no Apple, Google, or Microsoft, but yet they keep churning out new versions that attempt to keep up with the ever changing development landscape with what many would consider a very lean development staff.  Most of the development staff are former users so there is a high level of familiarity with the needs of the user base.

So why don’t more developers know about Xojo?  With the features and history described above it seems like everyone show know what Xojo can do for them.  That doesn’t seem to be the case so why not?  In part 2 we’ll examine some of those reasons.

XDC News:  IDE Redesign Coming

I’ve made no secret that I despise really dislike the Navigator in the Xojo IDE.  It is often in the way and it paradoxically either shows not enough detail or way too much.  Working in a large project is an exercise in frustration due to the Navigator.  Thankfully, the most serious bugs have been worked out but there are still issues where the Navigator may or may not have the control focus when invoking a keyboard shortcut.  This can sometimes produce ‘interesting’ results


During the XDC 2016 keynote last week Geoff Perlmann, CEO of Xojo announced that an IDE redesign happening.  This scheduled change should appear towards the end of 2017.  They acknowledged at XDC 2015 that the Xojo IDE needed some redesign but it is obvious that they’ve given it some serious thought with actual design documents that spell out exactly how it should work.

During the keynote Geoff showed us several screenshots of ‘Photoshopped’ versions of the new IDE with the caveat that everything could change between now and release.  The biggest change is that this new IDE is a mixture of the best of Real Studio and Xojo.

Gone is the Navigator (as we know it) with all of its faults.  In its place, Geoff said that we’ll start with a something akin to the Project Tab from Real Studio.  In the screenshot it looks like it’s a list of the project with a Type (e.g. Window, Class1, Class2, etc), and another column to describe what it is.  In Real Studio this was a combination of base class and whatever interfaces it might be using.  To figure out the base class and interfaces of an object in the Xojo IDE you have to hover your mouse over the item.  Every new tab will start with this project list.img_4510

Double clicking on an object zooms in on that object in the same tab. It loads whatever editor it needs.  This should eliminate much of the focus stealing that happens with the Navigator and make individual editors more stable without constantly having to worry about the Navigator.

A side benefit (I think) of the Navigator being eliminated is that the Library of controls is now on the left side of the screen and will be visible, by default, in the Form Layout editor.  This fixes a complaint many people have in the current implementation where the Library and Inspector can’t both be open at the same time without making them windows.

With two screen shots it’s hard to glean much information but with a toolbar item for Build Settings it’s a sure bet that their is a new (old again?) dialog for the build settings that is currently in the Navigator.  This makes sense because after you’ve set up those things how often do you really change them?  Again, one more thing eliminated from the Navigator that annoyed me.

It appears that Location is again in the toolbar.  This should make it faster to change locations in the project instead of having to invoke a dialog.  Since this IDE should work a little like Real Studio let’s hope that the Back/Forward buttons work properly.

We did not get a look at the Code Editor so it’s hard to say if that’s morphing back to what Real Studio was as well.  I for one would like to see the method definition pane move back to the top of the screen rather than in the Inspector.  In the “Meet the Engineers” panel the compiler engineer, Joe Ranieri, said that there would be changes likely in the debugger panel but didn’t mention anything specific since the 64 bit debugger is a work in progress.

From two screenshots it’s obvious that Xojo is listening to our complaints.  It’s a shame, though, that it will take four years to address them.  I can only wonder how many developers do a bulk of their work, still, in Real Studio because they are more efficient with it, and only compile in Xojo.  The plus side, though, is they are doing it the right way with a design document and essentially writing the documentation, first, before implementing it.  It’s a big and important job so it’s nice to see changes coming.

What about you?  Are you excited about it or is this just one more thing to relearn?

2016 Xojo Design Award Winners

img_4508Xojo announced the winners of the 2016 Xojo Design Awards today in Houston, Texas during their annual Xojo Developers Conference (XDC). These are applications and tools made with Xojo that were considered the best in their respective categories.
Best Overall:  EverWeb http://www.everwebapp.com

Best Business App: Light Blue https://www.lightbluesoftware.com

Best Consumer App: Alinof Timer Pro https://www.alinofsoftware.ch/apps/products-timerpro/index.html

Best Cross-Platform App: PubCoder https://www.pubcoder.com

Best iOS App:  Studiometry Touch http://oranged.net/studiometrytouch/

Best Developer Tool:  Everweb http://www.everwebapp.com

These are great examples of what some awesome developers are doing with Xojo. Congratulations!

XDC News:  Android Support

iurThe 2016 Xojo Developer Conference kicked off in Houston, Texas today.  Geoff Perlmann, CEO of Xojo, Inc. took the stage this morning to deliver his keynote speech.  The biggest news of the day is that Android support is coming for Xojo.

Many Xojo developers (myself included) find that iOS support is great but without Android support it’s not complete.  Geoff announced that in the fourth quarter of 2017 Xojo will have the ability to compile Android mobile applications.

This is a big deal and a daunting challenge for this team.  It appears that they’ve done their homework to figure out what they want to do.  Details are scarce at this point but they already know they will compile down to native code and not Java.  They will also use native controls like Xojo does for iOS.

The target version of Android that they are aiming for is JellyBean (version 4.1) or better.  Roughly 97% of all Android users will be covered.  Sadly, version 4.1 was released in 2012 .  I would have thought that 4.4 (KitKat) or better would be a better choice.  Let’s hope that gets changed before release.

Geoff did not mention if Xojo is planning on adding additional staff.  The reason I bring this up is that I find a twelve month timeframe to implement a completely new platform.  A more realistic expectation is that it will be released in beta form and it will be 2018 before it’s ready for more usage.

More details as learn about them.

XDC News:  2017 Roadmap

img_4508In todays keynote address, Geoff Perlmann, CEO of Xojo announced the major features coming to Xojo in the 1st, 2nd, and 3rd quarters of 2017.

First quarter:

64-Bit builds will be out of beta.  This means that XojoScript will be 64-bit capable as well.  This also means that 64 bit builds for Windows will include application icons and version info.

Remote Debugging will be available for the Raspberry Pi.  This should make using and developing on the Raspberry Pi that much better.

Remote debugging will also be available for 64 bit!  This should make the transition to 64-bit much faster at this point.  I know that we are holding off moving to 64-bit builds because of the lack of remote debugging.

String and Join functions that are pretty slow in 64 bit builds will now be considerably faster.  Again, really good news for some developers that have experienced this.

Second and Third Quarters:

New projects will be 64-bit by default.  32-bit builds are NOT going away.  What is going away is 32-bit versions of the IDE and while nearly all Mac OS X and Linux OS’s are already 64-bit this might cause some pain for Windows users that will have to update to 64-bit.

The new Xojo framework will come to Console, Web, Desktop and Mobile.  (Technically speaking mobile is already using the new framework.)

New plugin format:  Currently plugins in Xojo are written in C/C++ and are only supported for console, desktop and web application.  Developers will be now be able to create plugins in Xojo that will include resources, windows, etc. that are not possible in the current format.  The advantage of this is that it will allow anyone with a Xojo Pro license to create plugins and could (potentially) dramatically increase the availability of 3rd party controls.

These plugins are compiled into an intermediate format that is not human readable.  Presumably this format is something that can’t be reversed by the average developer.

This new plugin format will become the preferred format but the old style format will be supported for the foreseeable future.  It will be supported for Mac OS X, Windows, Linux, Linux ARM, and for iOS.  This last item is a high want by many Xojo developers.

Fourth Quarter:

Interops is a new feature to take the place of Declares in Xojo.  Declares are great but there’s no autocomplete and there’s absolutely no data type checking.  Interops should make this much easier.

More news coming up!

XDC News: Xojo 2016 Release 4

img_4508In today’s keynote address, Geoff Perlmann, CEO of Xojo announced the major features of Xojo 2016 Release 4.  Release 4 is scheduled to go beta in November and go public in December.

The existing Windows framework drawing is currently done via GDI or GDI+.  Xojo recently dropped Windows XP support and this allowing them to update how Windows apps work.  In the upcoming release Xojo will switch to Direct2D and DirectWrite.

These two technologies will allow better picture scaling and better alpha channel support.  And while GDI+ does have some hardware acceleration these new libraries have full support for hardware acceleration.  In testing, Xojo says that intensive drawing routines should be roughly 280% faster than R3.  End users should only have to recompile their apps to take advantage of this new feature.

Geoff did not talk about flickering but I will attempt to find out more this week.

Among the other changes:

Windows HiDPI will now officially be out of beta.  In addition the Windows Xojo IDE will be released as HiDPI capable.

Xojo Cloud users should see exceptionally better upload speeds.  Starting in R4 the libraries used in the upload are cached so they are not uploaded every single deployment.  This should speed up deployment and testing quite a bit.

More news to follow.

Xojo Musings

iOS 64 bit builds was introduced in Xojo 2015 R1.  Raspberry Pi support and 64 bit builds for Xojo desktop, web, and console apps was released in Xojo R3 in October 2015.  iOS, Raspberry Pi, and the 64 bit builds are all using the LLVM compiler.  The lack of a 64 bit debugger really holds back adoption of these new platforms in Xojo, in my opinion.

I’ve spent the last month working on a couple of different Raspberry Pi projects.  One was for a client and one was for fun.  In both cases the projects weren’t exceptionally tricky or complex but they took way longer than necessary since you can’t ’see’ anything while it’s running so I was is forced to use ‘old-school’ debugging methods with log files, message boxes, console messages, and whatnot.  Regardless, it’s not fun using the Raspberry Pi with Xojo.

It’s obvious that the move to 64 bit is much harder than they anticipated.  If it was easy the Xojo IDE would already be 64 bit by now – a year after 64 bit was released.

As a company we’ve officially held off on supporting 64 bit builds of our products.  Both Shorts and Formatted Text Control use XojoScript which isn’t 64 bit compatible yet.  XojoScript can be stripped from both products but it’s not an ideal situation and one that seems pointless since 64 bit is coming – eventually.

Xojo 2016 R3 was released a few weeks ago so the chances of R4 coming out in October is pretty slim.  The Xojo Developers Conference (XDC) is coming up in two weeks so I’m sure everyone at Xojo is gearing up for it.  And since they are all at the conference there is not much chance of real work getting done that week.  Good for those attending but bad for those anxiously awaiting new features and bug fixes.

In the past two and half years Xojo has added two new platforms (iOS and Raspberry Pi not to mention 64 bit builds) and not added any permanent staff (that I’m aware of).  Xojo does amazing stuff with the limited staff it has.  While they swear it doesn’t take away from their work I have to call them on it.  Two new platforms with initial development cost, debugging time, and the subsequent bug reports from users HAS to slow them down on other things.  It simply does.

I’m not doing their level of work but we manage five employees each with their own set of projects.  To put one person on ‘project x’ when they’re already working on ‘project y’ means that ‘project y’ gets delayed.  Since 2016 R2 was a big iOS release one has to wonder what was delayed to get those features added (and some would argue they were a year late anyway but that’s a different post).

I’m hoping to see a 64 bit debugger at XDC but I’d bet on a 64 bit IDE first.  This makes sense because they need time to work with it internally before we see it.  This will mean that XojoScript and whatever else was holding 64 bit back has been figure out.

Other things I predict for XDC:

Android.  Don’t get me wrong, I want Android because I feel it’s the only way for Xojo to grow into the mobile space, but if it means that the same staff are now adding yet one more platform it’s not worth it.  I’d rather have the big ticket items they’ve already said are coming than yet another platform that takes precious time away from what they already have. Likelihood:  sadly, pretty good given a recent Xojo blog post

Windows framework changes.  It’s been a while since Windows has received significant love.  We know they’ve been talking about using part of the .NET framework in Windows and now that Windows XP support was dropped this might become a reality.  The only question is what does it give us and when do we get it?  Likelihood:  Good

New framework additions.  The Xojo framework has been slow to gain momentum in the community.  Part of it is bugs those brave enough to use it have discovered and part of it is that it’s incomplete.  I’m not sure how much of the new framework is used in new parts of the IDE but it seems like this would become a bigger part of their mission as time goes on.    Likelihood:  Good

New database frameworks.  In iOS we’re already seeing the potential changes coming where a database error throws an exception.  This is a good change but will require a lot of patience on our part to get used to.  Many XDC’s ago Xojo showed off ORM classes (a lot like ActiveRecord but built into the IDE) for SQLite that looked interesting so it will be nice to see if that’s gone anywhere.  Prepared Statements are now built into the SQLExecute and SQLSelect commands but they’ve also screwed up (read removed) dynamic queries with the lack of BindType and BindValues so I’m looking for a new solution in this front.  Likelihood:  Maybe

Libraries with Xojo.  This was brought up last year at XDC so I don’t expect to see a lot of news about it but I do expect an update.  It would be really nice to create libraries using Xojo instead of using plugins or encrypting source code.  Likelihood:  Mention only

Plugin Management.  The simple fact of the matter is that many Xojo developers (myself included) use plugins.  For many it’s the simplest way of doing things and between Monkeybread Software and Einhugur they offer a ton of functionality that is not built into Xojo.  It would be nice to have the IDE manage them so you can have multiple versions of a plugin installed and only some of them activated on a per project basis.    Likelihood:  Wishful thinking

I’m sure there will be a surprise or two but honestly I expect methodical, evolutionary changes.  What news do you expect to see from the Xojo Developer Conference?  What would surprise you?

Xojo 2016 Release 3

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Happy 50th Birthday Star Trek!

Today is the 5enterprise-movie-facebook-timeline-cover-photo0th anniversary of Star Trek.  For many people it inspired us to be better people and get involved in technology.  I think I can say with some relative certainty that I would not be who I am today if I had not watched Star Trek.

I am too young to remember when Star Trek originally ran but it was a staple of syndication by the time I was a youngster growing up in rural America.  This was a time before satellite television and we had only four channels (the horror!).  Star Trek was on every Sunday afternoon and it quickly became a must-watch show in our family.
One of my fondest memories was going to my grandmothers house and watching Star Trek with my cousin.  She was the only family member that had a color television and she was content to let us watch “that show” as long as we relinquished control before the Lawrence Welk Show came on.  Good times, let me tell you.

I recently attended the World Con convention in Kansas City.  This is one of the big science fiction and fantasy conventions of the year where the Hugo Award is given out.  Think of it as the Oscars for SF and Fantasy writers/readers.  I attended quite a few writers panels where panelists brought up Star Trek as being a major influence.  It was surprising to find that authors that I admired had the same influence as me.

Star Trek is part of the pop culture now.  Who doesn’t know what a Vulcan or Klingon is?  It’s what every show about space travel is compared to in some way.  The impact it has made on our culture is huge.
Star Trek is surprisingly liberal when you think about it.  It was where liberal ideas got presented to a conservative audience in a way that was palatable.  It made a huge difference in the lives of many people.  Black men and women saw Uhura on the command bridge doing real and important things and no one (on the show at least) cared that she was a woman or black.  As a kid I didn’t know it was a big deal that Kirk and Uhura kissed.

Star Trek and its subsequent followup shows talked about the politics, religious, and social issues of their era.  Of course you didn’t know it at the time – it was just entertaining – but like any good science fiction story it explored the grey areas of the day.  In my opinion, science fiction is the last remaining political and social commentary avenue available for modern era writers because it’s not about ‘us’ it’s about the future or some alien civilization.  It’s easier to see the injustice when it’s not about present day us.

There are other numerous examples of how Star Trek predicted the future, or perhaps helped change the future.  Automatic doors, cell phones, tablets, talking computers, and any number of other ‘futuristic’ technologies in Star Trek are now commonplace.  Imagine what the next fifty years will hold for us technology wise!

The other thing that I love about Star Trek is that it gives us hope for the future.  A future where we’ve learned to work together for the greater good for all species.  To not ignore our differences but to embrace the diversity of ideas that we all bring to the table.  To use technology for good things but also be wary of its abuses.

Happy Birthday, Star Trek.  Let’s hope the next 50 years are as fun, memorable, and thought-provoking!

Estimating is an Art, Not a Science

A question that comes up quite a bit is how to do proper estimating.  It’s not an easy thing to quantify as much of involves gut feeling at times.  It’s why I feel that estimating is an art, not a science.  The hard thing about estimating is that it takes experience to know if you’re doing it right or not.

My first bit of advice is start using a tool to track your time.  If you can’t do it by specific task, as least do it by overall project.  Once the project is done you can then see if your estimate matches reality.  It won’t at first but that’s why you track your time so you can make adjustments on the next project.  After looking at several projects I came up with the idea of the times three for estimates.

When you look at part of a project, say a form, your estimate tends to be something like this:  if I know everything up front and there are no major surprises this is what is how many hours it will take to complete the programming and testing of this form.  However, we rarely know what those major surprises are up front so at best this is my guess and multiply it times three to come up with a more realistic estimate.

After a while I started to realize that some forms just aren’t going to take that long.  An About Window just won’t take more than fifteen, twenty minutes – ever – so why do the multiplier on that?  It makes no sense.

What makes one form harder to develop and test than an other?  Complexity.  A simple List form and an Add/Edit form might take an hour each (if that) to complete but busier versions of both might take three to four hours each.

What brings in the complexity?  Well, that depends on a number of factors.  Number of controls on the forms is a good start.  The business logic is another.  If how things work depend on what the user is doing in the controls you can rest assured that programming and testing of it is going to take longer than you expect.

Another part of complexity is the number of unknowns.  If you have to do a complex calculation that involves a bunch of math (especially if you’ve never done said math before) it should up the complexity.  Doing some programming concept in Xojo that you’ve never done before should up the complexity as well.  In both cases you should expect some research time, maybe even time to do a small example project, and a restart or two since you’re learning as you go.

In my initial guess I still do the ‘if I know everything up front and there are no surprises’ estimate.  And then my multiplier is my feeling of the complexity of that part of the project.  The complexity factor is now my multiplier.  So an About Window has a complexity of one.  A simple list form has a complexity of one and half, but a form with several page panels or containers that do different things based on user input might be a complexity factor of three or four (or more).

I tend to break projects down to several parts.  The first is overall project design.  There are certain number of hours just to set up the project and create the classes I need.  There’s usually some database design and implementation.  Do I need to make any special classes or subclasses for functionality that I already know about?

When it comes to the UI I often take the database design as the guide.  Each database table is (probably) going to need a List form and a way to edit it.  Figure that a list table is only going to need a few of the fields for listing but the Add/Edit form is going to use all of them.  Are they all text fields or is it a mix of lookup fields with foreign keys?  Each of these adds to the complexity of the forms in question.

Coming up with an estimate is sometimes an art.  It takes experience (and failing a few times) to get the hang of it which is why you need to track your time.  Using the complexity as a multiplier might be a good way for you to start getting more accurate estimates.

Let me know if you do something different for estimating.  How do you track your time?

Happy coding!