Xojo Open Source Projects

In my last post I talked about the state of the 3rd party market for Xojo.  It was a somewhat depressing talk for those already selling and a cautionary tale for those contemplating entering the market.  All is not bad news, however.  In some ways, the amount of open source source code available for Xojo is at an all-time high.

For many Xojo developers the must-have libraries are the Windows Functionality Suite  and MacOSLib .  These two libraries are great places to start to enhance your Windows and Macintosh applications respectively.  There are both free and wrap system API calls into Xojo classes and methods.  I would start with these two classes.

The folks at IntelligentVisibility have done some interesting things.  Their CalendarTimeChooser project is 100% Xojo code calendar and time chooser that is pretty slick, in my opinion.  Besides that they have a DropBoxAPI project, a Telnet class for Xojo, a Logging class, an AutoCompleteTextField, and a Loading Wheel control.

Long time Xojo user Kem Tekinay has released Kaju.  Kaju is a set of classes that can perform self-updates for your Mac, Windows, and Linux apps.  This solves some real world problems we all face and while Monkeybread Software has the Updater Toolkit it uses different technique for each platform and (from experience) troubleshooting can be difficult in getting the Sparkle framework working on the Mac.

Another long time user, Scott Boss, of Nocturnal Coding Monkeys, has released the Xojo Colors Module that aims to simplify the use of colors in your Xojo project.  Another project is XoDrill which is Xojo class that uses the Mandril APIs from MailChimp allowing you to send mass mailing through the MailChimp service.

iOS has only been out for one release, but it has received a lot of love from the community.  Some criticize Xojo for not being complete and not providing some basic functionality.  I disagree because Xojo should not have to provide everything – just the basics for us to do everything else.  I think it’s working because the work coming out of the community has been extraordinary.  If your Xojo iOS app needs gestures then xojoGestures is a great place to start.

If you are working with iOS then I hope you are spending a lot of time in the Xojo iOS forum.  The users there are turning out iOS declares at a prodigious rate and there are way too many to list here.  The forum should be your first place to search for a solution.

Xojo for iOS has introduced the new framework which, in come cases, is considerably different than the existing one.  XojoiOSWrapper  tries to bring those legacy framework methods to the new framework and specifically for iOS.  If you’re working with iOS AND desktop apps and trying to use a set of shared business logic between them you’re finding it hard to accomplish.  GlueKit for Xojo is a set of classes and methods from long time Xojo developer Phillip Zedalis of 1701 Software, that allows you to interact with a single class that bridges the new and old frameworks.

Perhaps this trend is part of a larger trend with software that tends to make things open source.  I’m still not convinced that this is the best thing, long term, but it does provide some stability with developers entering and leaving the community and having source disappear forever.  Regardless of the long term implications it shows that the Xojo community is alive and thriving.

If I didn’t catch your Xojo open source project I apologize profusely!  Any oversights are purely my error.  Please leave a comment with the link to your repository and a brief description of what it does.  And for those of you wiling to share your work with the community a big hearty THANK YOU!

Shorts 1.1

picAppIcon256We released a new version of BKeeney Shorts today.  Version 1.1 is a recommended update for all registered users and is a free update.

Version 1.1 has a number of improvements:

• Text blocks now have an AutoHeightAdjust property that lets them auto wrap their text and change the text height accordingly

• New demo report that demonstrates the automatic height adjustment in a row (i.e. GroupItem) of data of varying text

• The desktop version now has an RTF Block and uses the Formatted Text Control to convert into Shorts reports and HTML

• The Demo project for Web and Desktop comes with viewers you can use in your own projects

• Multiple demo reports with the various ways to create a report via code

More information on pricing, features, documentation, demo project, and more available at http://www.bkeeney.com/allproducts/bkeeney-shorts/

The State of the Xojo 3rd Party Developer Market [u]

BKeeney Software offers a variety of Xojo developer tools for sale. BKeeney Shorts is a reporting tool unlike anything else in the Xojo kingdom and allows you complete control over your reports. That is its strength and also its weakness since you have to fully code your report. We also offer a Calendar class for use in desktop applications, a cross platform Spell Checker plugin, and ARGen that creates the classes that ActiveRecord uses to make database coding easier and quicker in Xojo.

Over the years we were approached by developers that were leaving the Xojo market and wanted a home for their product. When True North Software decided to exit the Xojo market we purchased the rights to Formatted Text Control, RB Code Reports and a number of other Xojo related tools. When Pandaware left we picked up Simple Help Editor and Styled HTML Field. Many people were asking for PDF classes and had fond memories of Fireye Software’s PDF classes so we tracked down Asher and acquired those too.

We purchased these products from their respective owners either because we already owned the products or had a use for them. In some cases we simply updated the source code and in some cases we started a complete rewrite to suit our needs. This means that in addition to the original thousands of man-hours the original developers used to create them we’ve invested significant time and effort ourselves to work on them.

BKeeney Software can’t exist on the sales of these developer products. Developer product sales are lucky if they top 20% of our annual income. Most years it’s less than that. Our second highest income earner is our Xojo Training material but, by far, our best income source is our consulting services. With multiple Xojo developers that makes sense. Not only can we throw all of our developers on a project we can (and usually do) all work on separate projects. When one of us is idle (which thankfully isn’t very often) we find time to work on our applications and developer products (and me on training material).

I was on the receiving end of a grievance on the forums this week where I was accused of not delivering updates that I promised on one of the products. If I did nothing but work on our products I’d be out of business in short order and that product would just go away and who knows if anyone would pick them up.

This got me thinking. Am I unique in this position? So I queried some other Xojo developers to find out what the state of the Xojo 3rd party market is like and if they would share their thoughts. I received more information back than I expected.

Almost all of the developers I contacted said that product sales were a minor portion of their income with most stating it was less than 20% of their income. Jérémie Leroy has a full-time job and the Xojo business is just a happy sideline. Sam Rowlands said there was no way the sales of his developer products comes close to paying for itself. And,one of the more well known figures in the Xojo community, Christian Schmitz said, “Even with the scale I have with MBS myself. Consulting keeps the company running.”

From these statements, it’s pretty obvious that the 3rd party market, while not exactly stagnant, isn’t thriving either. Everyone I talked to has other sources of income besides their developer tool/utility sales. Part of this is probably because the Xojo market is small. Another reason might be the hobbyists that Xojo attracts and they simply don’t have the means to purchase tools. Another possibility is that Xojo has ‘good enough’ tools built-in and newcomers don’t need the more advanced commercial, add-ons.

One of the interesting comments I received from several developers was that it was those that purchased the cheapest version of their products (some offer encrypted and non-encrypted versions) created the most work for them. I’ve seen this myself with our encrypted source code that it seems to generate more support tickets than the full-source versions. Based on this feedback I am seriously considering removing the encrypted versions from our store and simply selling the full-source versions. It’s interesting that our one product that doesn’t have encryption (Formatted Text Control) doesn’t generate that much support help despite it being one of the largest and most complicated products we sell.

All of the developers I contacted felt that the future of Xojo is bright and holds promise. iOS development in Xojo might become as big as desktop and web which means new customers for their products. The new framework causes concern for many in the Xojo community but the developers I talked to were ecstatic that Xojo was listening to our concerns and making incremental changes to the new framework based on that feedback.

The 3rd party Xojo development tool market is tough business to make a living at. The fact that half our products came from developers leaving the community says something. That some of the most well known and respected voices in the community can’t make a living selling Xojo developer tools and have other sources of income is also telling.

So what can Xojo do to help us out? Growing the user base is the biggest thing they can do and it seems that having the iOS version is a step in growing the platform. One area of concern, though, is that many Windows users are unhappy with Xojo right now. They feel, rightly or wrongly is besides the point, that the focus has been so Apple and iOS oriented the past couple of years that they feel unwelcome. Some focus on making the Windows experience better would be reassuring to them.

I also think that Xojo could do more to promote the 3rd party products. Perhaps the Xojo Developer Evangelist could pick a product to review each month. Xojo Developer Magazine does reviews like this but it doesn’t receive the eyeballs that the official Xojo site gets. Personally I’d offer a discount for the people that purchase via the review. The market isn’t THAT big and it would be a good way to show off some products and generate sales for developers that are starving for income. More income means more of time for product development and everyone wins when that happens.

I feel the future is good. More Xojo users means more product sales (hopefully). This, in turn, means we can spend more time on those products and pump out updates on a regular basis. Until then, us 3rd party Xojo developers will continue with our labors of love and put updates out when we can.

What do you think of the 3rd party market? What could Xojo do to improve it?

[Update:  ]

After looking at our 2014 numbers our total developer products and training sales was LESS THAN 10% of our total income.  In 2013 the amount was more but amounted to less than 5% of our annual income (consulting was VERY good that year).  In other words, if we relied on our developer products and training to make a living we would quickly go out of business.

Seriously, why do I even bother with developer sales?  Just using them and updating them for ourselves would be cheaper in the long run.

Client Red Flags

I’ve talked before about those little things that prospective clients (and sometimes actual clients) do that should give you cause for concern.  These are those things that should be red flags and make you reconsider taking them as a client, or not keeping them as a client.  We recently took on a new client that had already burned through another Xojo developer before coming to us.

I’ll start off by saying that we have an entire stable of clients that came to us after they had tried out another developer.  Roughly 75% of our long term clients have come to us this way.  For some, the developer left the industry and recommend us to their client but for some the Xojo consultants had failed to deliver a working application even after quite a bit of time and money.  The clients came to us and they’re happy that we have multiple developers and have a breadth of experience that is hard to find elsewhere.  We’re also not going away anytime soon.

This client should have raised enough red flags for us to avoid from the start.  But, honestly, that’s easy to say in retrospect.  Sometimes you just won’t know until you work with them for weeks and sometimes months.  Plus, it was a smallish project that was only a couple of weeks long.  What could go wrong, right?

The clients first developer underbid us by a grand total of 10 hours but had significantly lower billing rate.  A couple of months later the client parted ways due to lack of progress from the first developer and called us back.  Red flag number one, in my opinion.  Clients have every right to be price conscious but one warning sign is if they’re trying to get the project done ‘cheap’ and ‘quick’.  While possible they also need to be flexible and this client was anything but.

The second issue with the client is that they kept using phrases “we want it exactly like this,” with ‘this’ being a VB6 application that looked like they coded it in 1995 and an HTML website that harkened back to the 90’s as well.  Even if Xojo could create such an application (it can’t without significant work) I’m not sure I would simply because creating a 20 year old GUI isn’t something I strive for.  We were going to create modern GUI (nothing crazy – just want Xojo gives us) with a database backend so the application could scale.  But they demanded flat files and a UI that looked ‘exactly’ like their prototype (which was non-functional).  Their reasoning?  Because they understood it and ‘their generation’ understands that look.  Hm…okay.

I guess my biggest issue with this client is they chose Xojo – not us.  There was nothing in the project spec (a VB6 app, a simple HTML web site, and some phone meetings) that said it couldn’t be done in Xojo and when we heard ‘just like this’ we translated this to mean ‘as close to this in Xojo as possible’ and when we didn’t make it look like the 90’s website they were mad and cancelled the contract despite us redesigning the app twice in attempt to mollify them.

In retrospect, the client doesn’t really want a Xojo developer.  They want an HTML and php developer that will do exactly what they want.  No more.  No less.  The signs were there from the beginning – we just failed to see it.

In the long run it’s just another red flag example that I hope to learn from and I hope that you don’t have to go through either.

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!

Xojo.Core.Date

I ran across an issue with Xojo.Core.Date that I talked about on the forums https://forum.xojo.com/18549-xojo-core-date-question.

The issue is that the new Date class does not have SQLDateTime.  Well, technically it does with a generic ToText function.  However, there is no way to get just the SQLDate portion without having to write your own method.

The ToText method has a LOT of power to do and it is considerably more powerful than the old Date class.  The ability to work with Locale is very cool and should simplify some things.  However, I have some issues with the ‘replacement’ for SQLDateTime.

First, SQLDateTime is very explicit in what it does.  ToText (with no parameters) doesn’t tell me jack and the fact that I missed it in the documentation tells me the name absolutely 100% fails the ‘name explicitly tells you what it does’ test.

Second, there’s no option to just get the Date in SQL format.  Sure, you can create your own method to get that but that’s one more thing to create, test, and maintain.  There are times when you need just the SQLdate portion.  It doesn’t matter why we need it – we need it.

The new Date class is full of wonderful things.  However, removing functionality that many of us use every day should be avoided.  I think this is one of those times where the Xojo engineers got too clever in the new framework.  I’d much rather have the SQLDateTime and SQLDate methods back.  They are much more explicit than ToText.  If you agree, you can sign on to <feedback://showreport?report_id=37521>

Of course, like with the Numeric.FromText methods, I’m willing to be convinced that the Date.ToText method to get SQLDateTime is better.  What say you?

 

[Update]

Later I realized that we could accomplish everything by adding the SQL option to the DateFormat and Locale enumerations.  Then the code would be something like this:



dim d as Xojo.Core.Date = Xojo.Core.Date.Now

dim t as text = d.ToText(Locale.None, Date.FormatStyles.SQL, Date.FormatStyles.SQL)


That would solve all of the issues, no?  They get to keep ToText and we get the ability to format the date in whatever form we want.  Then there is no ToText without Parameters.

New Navigator Preferences in Xojo 2014 R3

Without reigniting some of the flamewars of the past I think we can all agree that the Xojo Navigator is less superior to Real Studio in some ways. The old Real Studio IDE project list and method list showed you a lot more information at a glance without having to dive into the details. With all of the attention on iOS in release 3 I forgot to mention two new preferences for the Navigator that might make life easier for some.

Under the General Tab in Preferences there are two new checkboxes that affect how the Navigator shows some information. The first is the Default Values checkbox. This option changes how Properties and Constants are displayed.Xojo Preferences

Don’t Show Default Values:Don't Show DefaultShow Default Values:

Show Default Values

The other option is the Show Types in navigator checkbox. That option allows you to see the Property and Constant data types in the Navigator.

Don’t Show Types in Navigator:Show NothingShow Types in Navigator:Show Types
While certainly useful, it does make the the Navigator more cluttered, in my opinion. Cluttered makes things harder/more complex so I’m on the fence if this is a good option or not. I think what would be far more useful is to show the Super and Interface(s) of objects in the Navigator like how Real Studio did. What it did was put that information in separate columns so you could resize them as needed. In Xojo you have to hover the mouse over the object to get a help tag of the super and interfaces, or you look into the Inspector for the Super and go into a stupid dialog to get the list of Interfaces.

Real Studio:

Real Studio
Xojo:

Xojo Help Tag
My beef with the Navigator hasn’t really changed much since the initial version. It shows me too little information when I want more, and too much when I don’t. There are times when I’m okay with the Navigator but to work with it on a regular basis I find myself right clicking on objects to open it in a new tab – which is what Real Studio did. If the goal was to reduce ‘tab management’ Xojo is an abject failure in how I work.

I’ve been using Xojo on an every day basis since the new IDE was still in alpha so I don’t think it’s just a matter of ‘getting used to it’.  It has clearly affected how I manage my projects and there are still significant bugs, a year and a half later, that still affect us.  Yes, the list of bugs if getting whittled down but it’s obvious, to me at least, that the Navigator is an incredibly complex piece of code and starting with complexity is never a good start for a project.

Let’s hope that with iOS finally out the door, Cocoa working well, LLVM and 64 bit seemingly ‘close’ after several years worth of work some time can be spent on the IDE interface, the Windows framework, and some other long standing issues that drives us Xojo developers insane.

What do you think?  What’s on your wish list for the new year?

iOS For Xojo Notes #1

After doing about five hours of training video for iOS for Xojo I’ve discovered a few things.  First, the new framework will take some getting used to.  It’s not that it’s difficult to figure out, it’s just different.  Each little difference requires that I analyze what it’s doing and evaluate if I need to change my coding practices.

We’ve already talked about one of those differences with the FromText methods.  In the old framework using string.val does a lot of assumptions (not all of them good ones as we’ve come to find out) and those assumptions will either result in a valid number or a zero.  Blank strings also convert to a zero as well.

We’ve all been used to those assumptions for so long that we didn’t even realize the assumptions.  Or we ignored them.  Either way, we depended upon them.  The new framework uses much more stringent rules and if the text is outside of those rules it will throw an exception.

We can argue all day long whether it’s really an exception but that’s an argument for a different day.  Xojo has decided that errors shall not be silent (am I the only one that just said in a Gandolf voice, “Thou shall not pass (errors)!”?).  Errors causing excpetions will change the way we code and I’m still not entirely sure that I’m comfortable with those changes yet.  I’m sure it’s really a matter of getting used to them.

The other thing I’ve discovered is that events on iOS controls are different than their desktop and web counterparts.  In desktop and web if you set the value of a control it fires their relevant change events.  In iOS it does not.

In desktop and web apps we’ve actually relied upon this behavior.  Rightly or wrongly, it was there so we did.  This also meant, however, that we’ve had to somehow make a distinction of whether or not the user or the developer set the value (and caused the event).  Usually it was a matter of setting the control enabled = false while loading the data and then setting enabled = true when we were done.

Since iOS does not have this behavior I suspect we’ll start putting less code in the events of controls and instead use a method that does the work.  This is probably a good thing.  Being dependent upon the events to do something will make us better programmers in the long run (hopefully).  It’s not really a huge change but it’s a somewhat important one given the background Xojo developers have in desktop and web.

At first I thought this might be a bug but after cornering a Xojo engineer this was by design.  I can live this change now that I’m aware of it.  Do you have different thoughts on this?

What significant changes have you found in iOS that were a surprise?

Xojo 2014 Release 3.1

Xojo 2014 Release 3.1 hit the internet today. This release is a minor maintenance release and is recommended for everyone.

Web received a number of fixes. Checkboxes now work properly on touch devices. Label offsets are calculated correctly when the initial text is an empty string. Labels that had been on a container that had been set invisible in the IDE and visible via code now appear properly.

It’s a shame that these bugs made it into release.  Beta testers were so enamored with iOS that desktop and web didn’t get much attention.  But then again I was using the beta’s for production web apps and didn’t spot these bugs either so my bad too.  They’re kind of obscure in how to set them up and I generally don’t do either of those.  Hopefully with 2015 R1 we’ll get some better testing for targets other than iOS.

iOS received a few critical fixes. The first is that SQLSelect and SQLExecute now work properly (it was randomizing the data). The second fixed soft declares.

If you have not played around with the iOS SQLiteDatabase class the SQLExecute and SQLSelect methods now have built in prepared statements so there’s no need to through the steps of creating the prepared statement and then binding the values.

The IDE received a few minor bug fixes.  So did the compiler.

I reported a bug with the new Xojo.Core.Timer.CallLater in Windows yesterday. It generates an exception in a compiled application but in the debugger it generates an exception in the IDE! Too weird to be anything bug true. :)

I am looking forward to 2015 (seems weird to be typing that) Release 1. It looks like iOS builds will be 64 bit in that release. That means that Xojo is creating 64 bit builds for standard and debug builds in the iOS Simulator (Intel) and, at a minimum, standard builds for device deployments (ARM).

Presumably, this means that the IDE can already understand 64 bit debugger instructions, right? Is 64 bit for other targets far behind? Let’s hope not!

We already know the fiasco over the FromText methods in the new framework are being addressed in 2015 R1. In addition to FromText Xojo will offer a much less stringent Parse method that should satisfy most developers.

Any bugs that you’ve seen in Release 3? Anything you’re really looking forward to in the next release?

New Xojo Framework Thoughts

I don’t think application development is very hard. It is however complex and this, I think more than anything else, makes it appear hard because people equate complexity with being hard. Xojo does a pretty good job of making things less complex for us and I honestly truly appreciate that.

The new framework that we’re really seeing for the first time in iOS has some good things in it. Database errors throw an exception. I like that that because that’s what we (BKeeney Software) does with our own SQLSelect and SQLExecute extends methods (name SQLSelectRaiseOnError and SQLExecuteRaiseOnError). Not everything I agree with though.

In the existing framework we would do something like this to get the integer value of the aTextField.

dim i as integer

i = TextField1.text.val

We’ve been using this for close to 15 years. Works great. Now, in the new framework we have to use different converters and use code like this:

dim i as integer

i = Integer.FromText( TextField1.Text)

Seems pretty straightforward, no? Well, no, because in their infinite wisdom, if there is no text (i.e. a blank string) an “InvalidArgumentException” is thrown. WTF?!

Instead, you will have to do this instead.

Dim i As Integer

If Not TextField1.Text.Empty Then
   i = Integer.FromText(TextField1.Text)
End If

But even then, if there text there that can’t be converted to an integer it throws the exception. I sort of agree with that change.  But, I don’t see this change as being ‘better’ or even simpler. If anything it’s more complex and it’s getting away from the strengths of BASIC that made many us use it over other languages in the first place.

So really what you’ll need to do is something like this:

Dim i As Integer

try
   
   If Not TextField1.Text.Empty Then
      i = Integer.FromText(TextField1.Text)
   End If
   
catch e as InvalidArgumentException
   
   i = 0 //if that’s what you really want.
   
end


You really want to do that several thousand times in a big accounting application?  When I suggested that I’ll just create my own extends methods to match current functionality the response was “Not doing so is a great opportunity for silently doing something really wrong.” Well, I guess at that point it’s MY problem, no?  If something goes wrong, and I did my own method, it really *is* my problem.  Or are the Xojo Programming Police going to take away my license?

Xojo is trying to make a complex process idiot proof. I appreciate the effort, I really do, because Lord know I can be an idiot at time. All they did, in my opinion, was make this simple process more complex. I think they may hinder adoption of the new framework. My guess, though, is that they’ll force it down our throats for console, desktop, and web when the time comes.

What do you think, my friends? Is the new framework helping us or hurting us or is this just a “this is different so I hate it” reaction?