Tag Archives: Xojo

Xojo 2016 Release 1

Posted on by

Xojo 2016 Release 1 was released today.  This much anticipated version is all about Retina and HiDPI display support.  In addition to that, there are, as always, the usual mix of new features and bug fixes.  Let’s get to it!

The IDE is Retina Aware

The IDE itself is now Retina capable and all of the icons and images used in the IDE have been replaced with high resolution images.  On my 27 inch 5k iMac it’s quite a noticeable difference to my aging eyes: everything is very sharp.  As with many apps once you start using the high resolution version it’s hard to go back to a lower resolution.

Before you jump into this version you might want to do some testing.  On relatively new iMac the Web Layout Editor is very slow.  So slow as to be almost unusable.  This only happens on existing projects since new projects seem to work just fine.  Perhaps it’s a combination of project size and/or web page complexity or number of Web Containers.  I really don’t know but I’ve submitted a Feedback report showing the symptom and an application sample from Activity Monitor.

Your Apps Can Be Retina Aware

In the last Xojo version we were introduced to ImageSets and that feature is now more useful in 2016 Release 1.  The ImageSet allows you to add a normal sized image (1x), a 2x image, and also a 3x image.  Mac OS X only uses the 1x and 2x images but some Windows 10 resolutions will use the 3x image.

HiDPI support for Windows is officially beta and I believe that’s mostly because the various versions of Windows that Xojo supports all do HiDPI slightly different.   Currently Xojo does not support Window 10’s per-display scale factor and will use the scale factor of the screen it was launched on.  TextArea’s only display in large size, the HTMLViewer and MediaPlayer is not scaled, BevelButtons don’t display, and Image Set Icons do not appear correctly in toolbars.  Obviously this is less than ideal for Windows applications and you probably don’t want to release a Windows app with this set.

With Retina/HiDPI support is a new Application shared property called SupportHiDPI.  When set to true, Xojo will build your application with Retina and HiDPI awareness.  When set to false it will build apps that worked the same was as previous builds.  Sadly, this property cannot be changed at runtime because it would make enabling it for Mac OS X a no brainer but leaving Windows as is.

As you can imagine, Retina/HiDPI changes a number of important things.  The Picture class has a new constructor that can take one or more bitmaps in addition to its size.  All bitmaps must have the same aspect ratio or an invalid argument exception is generated.  One question that I’ve not explored for myself is how exact this ratio must match.  What is the precision on this check?

The graphics object now has a ScaleX and ScaleY property.  For pictures the scaleX/Y are always set to 1, but a graphics object passed in from the paint event might have a ScaleX/Y set to 2 on a Retina display.  Graphics.Pixel is now deprecated (NOT REMOVED).

Windows have a couple of changes too.  There is a new event ScaleFactorChanged on Mac OS X that is an indicator that all graphics for that Window should be invalidated.  A read only ScaleFactor tells you what the scale factor is for this window.  The Canvas object has a similar ScaleFactorChanged event on Mac OS X as well.

Local Language Reference

Retina is not the only new thing in R1.  The Local Language Reference has been revamped again and if you are a Dash user you’ll notice that it shares much of the same look and feel.  Searching for an item in the Language Reference, in my opinion, is considerably easier in this new version and I find I like it better than the online version.  Besides being able to search for any event, property, class, enum, etc the local language reference allows you to go back through your search history rather quickly.

Web Framework Changes

The web framework received a number of important changes.  Perhaps the biggest and most important to web users are that WebStyles have changes their implementation.  The change notes say “User defined WebStyles now have more specificity than framework applied styles.” which I have been lead to believe means that WebStyles now work properly in all cases as there were fringe cases where styles were either ignored or improperly applied.  During the beta cycle Xojo asked us to test web apps to make sure nothing broke.  In my testing I didn’t see any issues.

The connection type of a web app can now be set with a command line option.  The WebListBox received some love too.

Miscellaneous Fixes

  • Build times have been improved.
  • Xojo.net.httpsocket now works in Mac OS X console and web applications.
  • A memory leak in NSWindow was fixed in the Cocoa framework.
  • The FileTypes editor has received a number of bug fixes and changes.
  • 40 changes to the documentation and examples.

Conclusions

With all of this work on Retina/HiDPI applications for Release 1 I am disappointed at the lack of project examples for HiDPI and Retina.  Sure, the SupportHiDPI is an easy thing to do, but for many of our applications that create images on the fly we are only left with some fairly vague instructions.  A Xojo Blog posted today http://blog.xojo.com/a-journey-of-a-thousand-pixels might be your best bet in understanding some of these changes in more detail but even I scratched my head with some of the implementation details.  Actual example code that show the practical implications of Retina/HiDPI and creating images would have been very welcome.

I’m relatively happy with 2016 Release 1 though not without some reservations.  Since the number of Windows controls in HiDPI that don’t scale properly is fairly large it’s not ideal that you can’t turn off HiDPI for Windows but keep Retina on for Mac OS X.  Sure, you can always do two builds but it’s not an automated option.  Performance issues with the Web Page Editor is also troubling and perhaps this means there’s a dot release in our near future.

There are quite a few things on the horizon that Xojo needs to tackle.  Full debugging in 64 bit and a 64 bit IDE is perhaps the biggest one and the HiDPI stuff is surely a distraction from that important requirement.  This beta cycle was really long and it makes you wonder how much their schedule has shifted just to get HiDPI (mostly) working with some obvious work still to do.

What are your thoughts on Release 1?

Xojo Code Folding

Posted on by

I was talking with another Xojo developer and we both commented on how neither of us use Code Folding in the Code Editor.  I’ve been using Xojo for fifteen years and this developer is at least ten years.

For-Next

For-Next regular

If you’re not familiar with code folding it’s the ability to collapse an entire branch of an If – Then statement, Select – Case, For – Next, While – Wend, and probably a few others.  The code doesn’t go away, it’s just temporarily hidden.  It’s a convenient way to hide a good chunk of code so you can easily see what else is going on around it.

For Next Collapsed

For Next Collapsed

The other developer and I discussed this issue for a while and we really couldn’t come up with a good reason why.  The best reason we could come up with is that it *looks* like the code has been deleted.  Like I said, it wasn’t a good reason but at least it was a reason.

Do you use Code Folding? If not, why?

Have a Merry Christmas and Happy New Year folks!  Stay safe, enjoy time your family, and happy coding!

Xojo 2015 R4

Posted on by

Xojo 2015 Release 4 hit the internet today.  The fourth release of Xojo this year is full of bug fixes and only has a few new items.  I’d recommend using this release as the bug fixes are substantial.

Let’s get what’s NOT in this release out of the way.  This release was initially supposed to be about getting Retina and HiDPI capabilities in the IDE and in our applications.  It was determined that there just wasn’t enough time before the end of the year to get it done.  It’s disappointing to not get these new capabilities but I’d rather they be done right than Xojo giving us a half-assed feature that no one is really happy with.

This release also does not complete the 64-bit work started in 2015 Release 3.  We still cannot use the Remote Debugger to live debug 64-bit applications and there are still major gaps in the capabilities between 32-bit and 64-bit applications.  A full list is here:  http://developer.xojo.com/64-bit-guidelines

Changes and Fixes

What this release does is fix over one hundred compiler, framework, database, and IDE bugs.  There a number of 64-bit bugs that have been squashed that were causing linking errors or outright crashes when compiling 64-bit applications.

For the framework there are a couple of high profile fixes that are welcome.  XML Exceptions no longer ‘skip’ exception handlers.  I know this has been troublesome for many developers.  An issue with the new Xojo.IO.Folderitem class has been fixed on Cocoa that would cause crashing when a FolderItem object was put in a tag, for example.

The Web framework received

some bug fixes as well.  Some of the more notable:  WebSessions no longer quit when moving from network to network.  WebPicture’s no longer return nil when defined from a FolderItem and the WebPicture no longer uses twice the memory when the image is in the project file.  The web framework now recognizes the Epiphany web browser on Raspberry Pi.

The WebDragItem now has the Origin X and Y values that indicate the X and Y coordinates of the Sender web control where the drag began.  I haven’t tried this out yet, but this should make some things (like a web based designer) a little easier to create.

The MSSQLServer Prepared Statement no longer returns a nil and should allow developers to use this safer method of using Xojo with Microsoft SQL Server database servers.  The ODBC Database plugin also got an update so it no longer crashes when retrieving large SQL columns.

The IDE has dozens of bug fixes.  Most of them pretty minor but they add up.  Among the more notable fixes:  AutoComplete has had extensive work so that control arrays and structures should work.   Private methods and properties now show in AutoComplete as expected (now, only when in scope).

The Syntax Help Area (at the bottom of the Code Editor) is now scrollable  when the content does not fit the preexisting area.    This area will also show the description, if there is one, in addition to the signature.

The Interface dialog now resizes itself to 75% of the window height.  If you make it larger it will reopen at that size (or the limits of the window).

Filtering in the Navigator now shows results ordered on how closely they match the string based on the Levenshtein distance of the match.  So if you don’t quite get the name right you might still get results instead of requiring an exact match.

New Stuff

Despite this being a mostly bug fix release there are a couple of new goodies that might make your day.  The first is that MySQLCommunityServer now has a SecureAuth property which allows users to authenticate using old password hashes.

The Graphics class for desktop apps has a new property, called CharacterSpacing, that allows you to change the percentage spacing between characters.  You can use both positive and negative values.

Web Text controls now have a TextAlign property.  This should simplify web projects as you no longer do have to duplicate a WebStyle and change the alignment simply to change the text alignment for a single control.  You can still do that but this is a new way to eliminate that extra work.

In some preparation for Retina, Image Sets are now available.  Use the Insert Menu and select Image.  In the Image Set editor that are now 3 thumbnails for the set for normal size, double size, and triple size.  But since this release doesn’t include Retina support this feature is of limited usefulness – for now.

What might be the biggest news of the release is the addition of the CGFloat data type.  This temporary datatype aliases to a Single in 32-bit builds and a Double in 64-bit builds.  This should make fixing some the common libraries (think MacOSLib) easier since we can make one variable that will work for both build types.  Xojo has said that once 64-bit iOS and OS X builds are ONLY 64-bit the CGFloat data type will be deprecated.

Future Releases

I’m a big fan of these mostly bug fix releases.  In a product that changes so much and so quickly (at times), these bug fixes releases allow us to take a deep breath and not worry too much about using this release.  We worry about the big releases because of the shear amount of changes involved and the amount of testing required with our applications.

So what do we have to look forward to in 2016?  Presumably, 2016 will see a full compliment of Retina and HiDPI support since Xojo publicly pulled it from this release.  I would also expect the 64-bit journey to continue with hopefully the IDE becoming 64-bit which means that XojoScript, Windows version and icon information work, and the grandaddy of them all, Remote Debugging work in 64-bit.

I hope we get a Remote Debugger for Raspberry Pi simply because that will make life easier on that platform too.  I’m not sure what else we really need for Raspberry Pi.  What have I forgotten?

I would expect the IDE to get some level of redesign.  Many people, including myself, are unhappy with the workflow in Xojo and think it’s slower to use than Real Studio.  I know of several large customers that have stuck with Real Studio rather than migrate their projects to Xojo simply because of the IDE workflow issues.  Personally I’m happy that Xojo plans to address some of those issues.

I expect the iOS framework to grow with new controls and capabilities.  I also expect the new Xojo framework to keep growing (TCP Socket perhaps being the biggest need) and getting more attention to eliminate some of the cross platform bugs in it (looking at you HTTPSocket).

Will 2016 be the year that the desktop or web frameworks gets rewritten for the Xojo framework?  Perhaps, but Xojo isn’t saying much.  With XDC now in October we won’t get much of a hint of future plans until then, or until we see it in a beta cycle.

I know that Android support is at the top of the wish list in Feedback.  I do NOT see it in 2016 simply because it’s yet another platform.  Unless they’ve already started the work on it (which is always possible and we haven’t noticed it) I expect it to take at least 18 months (more likely two years) for an Android beta release.  And even then, how long until it’s really usable?

So what is your take on this release?  Good, bad, or meh?  What are you most looking forward to in 2016 from Xojo?

Listbox and Tag Options

Posted on by

The Listbox is a very powerful control, in my opinion.  Out of the box it doesn’t have a lot of capabilities but it’s easily extendable and it’s possible to create some complex grid-like applications using the standard Listbox.  Is it perfect?  No, but it’s more than adequate for most developer needs.  There are a number of options for showing and storing data.

A new user to Xojo recently asked me about the various tag options in the Xojo Listbox.  She wasn’t sure when you’d want to use RowTag versus ColumnTag versus CellTag.  It was a good question – I hadn’t given it much thought.  I like questions like this because it forces me to think like a new Xojo developer.

Most Tags in Xojo are the Variant datatype and that means they are very good at storing whatever you want in them.  We often say, “just stash the data in the tag”.  Since you can put practically anything in a variant it’s very convenient to use it.  I suspect that whenever the new framework makes it into UI elements the tag will turn into an Auto variable (which will lead to interesting problems but that’s a post for another time).

When it comes to the Xojo Listbox, I know some Xojo developers like to make columns of zero width and put data in these hidden cells.  I dislike this approach for several reasons.  One, it limits what the listbox GUI can do.  A zero width column means that you probably don’t have column resizing on (and if you do the columns are accessible to the user).  Two, it’s not how the control was intended to be used.  Three, we have Tag options to eliminate the need to do this.

We predominantly use the Listbox.RowTag property to store our data.  A vast majority of our projects are database driven and since we use ActiveRecord a lot we almost always have a class object (the ActiveRecord object) that has our record stashed away in the RowTag property.  The listbox may only have 2 or 3 visible columns of data but the ActiveRecord object might have dozens of properties (which reflect the fields in the table).

This gives us the advantage that we only have to query the database once and that’s to load the listbox.  Subsequent edit/update and delete operations simply use the object that’s already in the RowTag.  The user selects the row, we get the object out of the RowTag property and then pass it on to whatever method needs to work with it.  This fits 95% of everything we ever do with a Listbox.

The CellTag comes in on projects where we’re not using ActiveRecord.  Things like preferences come to mind where it’s data but not database related.  We load the Listbox cell data with what the user can edit.  Then, in the CellTag property put a copy of the visible data so later on we can compare the Cell text to what’s in the CellTag.  Even in this case, though, we still use the RowTag property for identification purposes.

Using the CellTag and comparing it to the Cell text is convenient when doing inline-editing of the Listbox data.  The comparison can happen at the Cell Lost Focus event or in a generic Validate method before saving the data.  Either way, the CellTag data is ‘hidden’ and the user can’t mess with it.

The ColumnTag has been around a couple of years and I can’t say we’ve used it much.  I can see the benefit of using it, however, to make things like Pivot Table using the Listbox.  This isn’t a trivial task, mind you, but I would treat it like the RowTag.  It’s there for use and I’m sure someone out there has a reason to use it.

If you find yourself making zero width columns to store data in your Listbox you should look at the various Tag properties.  Trust me, it will make your application work better and be safer with your data.

What interesting things do you use Listbox tags for?

Should you Mix and Match Old and New Framework?

Posted on by

When Xojo introduced the iOS framework when Xojo 2015 R1 came out we got introduced to the new Xojo framework.  It was only required for iOS and were told that it would eventually get added to the other targets.  Xojo 2015 R2 introduced much of the new Xojo framework into the desktop framework.  Many people are curious if it’s time to start using the new framework.  Is it safe to use?

Let’s get this clear up front.  There is no reason why you have to use the new Xojo framework.  Sure, it’s the future but the old framework will work for many years to come and there are huge gaps in the Xojo framework that haven’t been addressed yet.

My first bit of advice is to not dive headfirst into mixing and matching the old and new frameworks just yet.  It can be an exercise is frustration.  Take, for example, this bit of code:



dim d as new xojo.Core.Dictionary

d.value(kMachineName) = MachineName.ToText

if d.value(kMachineName) = “” then
   
   break
   
end

Looks like it should work on desktop, right?  It doesn’t because when you get to the comparison it generates an exception.  When you break it down it makes sense because the Auto value you get from DictionaryValue is a Text type and you’re comparing it to a String type.  The two are not equivalent.

The way around this, that seems to work, is to do this:



dim tBlank as Text

if d.value(kMachineName) = tBlank then
   
   break //handle error
   
end

Obviously if I was using Text everywhere this wouldn’t be a problem.  But this is a desktop app and the major gaps in the Xojo framework start to show up.  The database classes will only accept Strings so you have to do some conversion.  This isn’t a big deal, but it’s one more thing to worry about and deal with when exceptions come up.

99% of our consulting applications are database driven so not having the database classes in the new framework are a major hindrance to us to adopting the Xojo framework.  Frankly, if it weren’t for the client wanting us to use the new framework whenever we can we’d not be using it yet.

Some of the parts of the Xojo framework that are done aren’t fully fleshed out.  For the past couple of weeks I’ve been working with the xojo.net.httpsocket class.  Works great on Mac OS X and Linux (surprisingly enough) but when I get into Windows for testing it just does nothing – no exceptions, no errors – it just absorbs commands.  The first reports of issues happening in Windows were reported in back in August but that report was closed as not reproducible.

When it comes to the networking classes the new TCPSocket class still hasn’t been ported to non-iOS targets yet.  Neither has any of the UDP and ITC classes and, in general, there are still a lot of old global framework classes that haven’t been ported yet.

This makes sense because iOS and then 64 bit took a lot of time and resources to get to the state they’re in today.  I would argue iOS isn’t complete yet but that’s an argument for another day.  It looks like 2015 R4 will be mostly Retina support so we are many months away from some of these gaps getting filled.

I am curious to hear other Xojo developers experience with using the new framework.  For me it’s been frustrating from the lack of examples in the documentation, to it just working differently than the old framework, to the new classes not working as they should, to not having a complete framework to pull from and the messiness from commingling the old and new frameworks.  My advice would be hold off on trying to use the new framework in a desktop, console, or web app until there’s more of it.

What’s your experience with the new framework?

Xojo Conference in London

Posted on by

With a little over a week to go there’s still space available at the MBS Conference in London the 27th of November.  It will be held at the Antoinette Hotel in Wimbledon which is a part of greater London.  The conference homepage is at http://www.mbs-plugins.de/archive/2015-11-11/Schedule_for_MBS_Xojo_Conferen/monkeybreadsoftware_blog_xojo.  There are still spots available!

This is during the Thanksgiving Holiday weekend for the United States but if you want to avoid your crazy relatives join us in London and get your geek on.  Airfare is reasonable this time of year to London.

Give it some thought and think about joining us.  I went to one of the conferences in Koblenz, Germany a few years ago and had a blast.  There is nothing like getting together with like minded people to chat about your favorite development tool.

I’m going to give a presentation on BKS Shorts and the new Report Designer that will soon ship.  I think people will be very happy with the ability to embed a report designer into their applications AND have the ability to modify the UI as they see fit.

Xojo 64-Bit Apps and Raspberry Pi

Posted on by

Xojo 2015 Release 3 is now publicly available.  This release is, by far, the biggest Xojo release in many years – if not ever.  All targets can now be built for 64-bit and also for Raspberry Pi (32-bit ARM).

Building your application for 64-bit in Xojo is as simple as going to the build settings for each platform (Mac OS X, Windows, Linux) and setting the Architecture to 64-bit.  On Linux builds in addition to the 64-bit option there’s also the ARM 32-bit option to build for Raspberry Pi.  It really is that simple.

All this is really good news because Xojo put a lot of time and effort to get the 64-bit compiler working.  They’ve obviously been working on 64-bit much longer than just this release period but to add twelve new targets (Mac OS X 64-bit desktop, console, web, Windows 64-bit desktop, console, web, and Linux 64-bit desktop, console, web, and Linux ARM desktop, web and console) is impressive, to say the least.

Raspberry Pi support is better than initially announced at XDC 2015.  Initially we were told that Xojo would only support console applications for the Raspberry Pi.  Instead, we have the ability to not only create console applications but also desktop and web applications for Linux ARM.

I’ve taken some random web and desktop projects and ran them on the Raspberry Pi with few to no issues.  The only thing I’ve not been able to get working is cgi web applications even though I installed Apache (I’m sure it’s simply a matter of getting the configuration correct).

One of the cool things about the Pi is that you can use GPIO and create all kinds of cool projects with switches, LED’s, and sensors of all types.  In the examples that come with R3, look in Platform-Specific/Linux/Raspberry Pi/ and you’ll see four projects that make use of the Wiring Pi library.

If you want to dive into Xojo and Raspberry Pi I highly recommend you take a look at the Xojo GPIO page on the Einhugur blog at https://einhugur.com/blog/index.php/xojo-gpio/.

If that wasn’t enough for one release, Xojo didn’t stop development on other parts of the IDE.  Web applications can now use drag and drop between objects on a WebPage.  They added a new AcceptingConnections property that allows you to start/stop a web app from accepting connections.  Standalone web apps now use TLSv1.2

There’s some new features in iOS too.  iOSLabel has new clipping modes that you can use instead of wrapping.  iOS now has container controls which should allow for some really complex user interface designs.  The iOS advanced tab in Build Settings now gives developers the ability to modify the Entitlements of built apps.

The desktop app FileTypes Editor is completely revamped and now allows developers to specify UTI’s for Windows and Linux too.  The new editor also lets you know if the icon set is complete.

A few important IDE bugs have been fixed.  If you delete an object that has open tabs those tabs are closed.  The grab handles on Layout Editor objects are now inline with the control frames than outset slightly.  These are annoying little things and I’m glad they’ve fixed.

Moving your own applications to 64-bit seems to take two routes.  One, it will just work and you’re on your way; or two you’ll have some work to do.  This seems to depend entirely on if you’re using plugins and libraries.  MonkeyBread Software and Einhugur have 64 bit versions of their plugins ready to go so check with them for 64-bit compatible versions.  MacOSLib may cause some issues and while I know the developers have been updating it I don’t see anything on their GitHub site saying they’re compatible yet.  Windows Functionality Suite users out of luck since it was made before structures were available in Xojo so if you’re using any of those classes you’ll have to find alternatives.

I would expect a few things about 64 bit to come to light now that it’s released to a bigger audience.  While I can’t confirm a dot release is coming I expect one to fix anything major to come up in the next week or so.

Everything is not yet perfect for 64-bit in the R3 release.  For one, the debugger doesn’t work in 64-bit applications yet.  Until that’s released you’ll need to debug the old fashioned way using console messages and log files doing full builds.  You cannot do remote debugging for ARM targets either.

A few other items are unavailable for R3.  XojoScript is unavailable for 64-bit or ARM targets.  You cannot build 64-bit Mac OS X apps from Windows or Linux.  Icons are not preserved in Windows 64-bit apps.  Tooltips class and tooltips on the ListBox do not work on Mac OS X 64-bit.

The Xojo IDE itself is not 64-bit.  I don’t think this is a huge deal yet but it’s also impressive that they were able to get 64 builds from a 32 bit application.

This release is massive and impressive with 64-bit builds and Linux ARM as well as over 300 changes and bug fixes should make everyone happy for a while.  Xojo should be congratulated for their hard work.

What did I miss?  What are you happy or disappointed with?

Using UI to Store and Manipulate Data Is Not a Good Idea

Posted on by

I’ve fielded a number of questions from developers over the years asking about the Xojo Listbox.  They question is if it’s a good idea to store and manipulate data in the Listbox.  While it’s possible, I say the answer is no, the Listbox is NOT a good place to store and manipulate data.  It’s also a poor place to put your business logic.

The Listbox is a user interface element.  It’s job, if you will, is to present data to the user in a grid.  Along the way you get the added advantage of resizable columns, sortable columns, the ability to do things in the cell with text, checkboxes, and even doing your own custom drawing and handling.  It conveniently allows us to stash data in row, column, and even cell tags and therein lies the delicious dilemma for users that need to manipulate data.

It’s common to see Xojo developers load a listbox and while it’s loaded manipulate all data in its cells and cell tags.  Their listbox events are filled with code to do things to other cells, and tags, and there is often a lot of code for business logic in them.  Then, when it’s all done, they save it off in whatever format they’re using.  This is all fine but it’s a royal pain to debug because most people don’t think about using a constant value, say kAverageValue, but instead say me.cell(iRow, 5) = str(NewAverage). To be honest this works well until you add a new column.  Then, all of your code for the cells to the right of the new column is wrong and you won’t know it until you test.

Another thing that I’ve seen happen is conversion errors.  The developer stashes a numeric value in the listbox cell and formats it.  Then has to go through the process of converting it back to a number for use in the database or file.  This often leads to issues that, again, can be tricky to track down.

Instead, we recommend using a data class that represents each row of data.  The whole list of data can be thought of as an array of data and we store each row in the row tag property.  What it boils down to is that when you’re start working with the data you manipulate the data in the data class rather than in the UI.  Then you update the UI from the data class.  The heart of it is your data class and it’s there you should put your business logic.  If cell 5 can’t be a negative number if cell 1 is greater then 100 it might make more sense to put the validation code in the data class rather than in the listbox itself.  That way you can do validation logic based on class property names rather than listbox row and column values.

If iAverage > 100 and iSetPoint < 0 then

is easier to understand than

if me.cell(row, 1).val > 100 and me.cell(row, 5).val < 0 then

The other thing that’s bad about depending upon the UI to store your data is now you are tied to that control.  I know developers that have invested a lot of time using the StyleGrid and when it wasn’t updated they spent a lot of time rewriting it for the listbox.  Some rewriting is inevitable, but if you can uncouple your data and your UI it’s much easier to move to another control later on.

We use ActiveRecord a lot and whenever possible we put our business logic in it rather than the listbox.  Does this mean that we get rid of all logic in the listbox?  No!  If column 0 can’t be negative, ever, then by all means put that logic in there.  But if the value in column 0 depends on another column we try to put it in the ActiveRecord data class.  The listbox simply becomes the input and display mechanism for the class.

Am I suggesting your go rewrite your listbox today?  Absolutely not, but perhaps the next time you want to make your listbox jump through hoops, perhaps you uncouple the data and put your business logic in a data class rather than in the listbox.  You might like the results.

Thoughts?  Do you agree or disagree?

VB6 and Windows 10

Posted on by

It looks like the Visual Basic 6 holdouts can breathe yet another sigh of relief.  Visual Basic 6 seems to work with Windows 10 as do VB6 apps, though not without some caveats.

I’ve been reading a few threads in various forums where most people have had few to no problems developing VB6 apps or running them in Windows 10.  I’ve seen at least one VB6 developer that claims they’re OCX laden application has issues when loading.  They say that some of the controls simply fail to load at runtime.  Funny enough, it happens only on 32 bit Windows and 64 bit Windows 10 works fine.  They gave no information if these were new installs or legacy upgrades.

Another developer claims to have problems installing VB6 Service Pack 6 on Windows 10.  They tracked it down to two Registry keys not being written.  This website gives a process to install VB6 in Windows 10.  The fact there is now a procedure to install an old app on a new operating system should be pause for concern.

The only way to get hold of VB6 is to have a MSDN subscription.  The subscription is $500 so that doesn’t seem like a huge burden.  But then again, remember that Microsoft is not supporting VB6 though the VB6 runtime is shipped with Windows 10.

There are a boatload of VB6 applications still out there so I think support for VB6 will be around for a long time.  In April, 2014 an InfoQ article  stated there were hundreds of VB6 developer positions listed on Dice and Monster.  VB6 officially went out of support in 2008 so good luck finding entry level and even junior developers to fill those spots – no one is learning VB6 any more.  One of my old clients has had a revolving door of VB6 developers for several years now and it’s getting harder and harder to find competent VB6 developers, and developers that wish to work with it.

As a Xojo consultant we’ve converted quite a few VB6 apps.  Well, convert is a strong word, really it’s a rewrite.  Despite both using a BASIC-like language, the two languages are diverging rapidly (not that they were ever really all that close to begin with).  Many issues that we spent a lot of time working around in VB6 just don’t happen in Xojo.  In our experience entire modules and classes just disappear because we don’t need them in Xojo.

Xojo is updated several times a year while VB6 isn’t.  Xojo is about ready to release a new version that creates 64 bit versions of Mac OS X, Windows, Linux for desktop, console, and web apps.  iOS will also be 32 bit and 64 bit.  VB6 is stuck building only 32 bit Windows apps.

Is Xojo a perfect alternative for VB6?  No.  It is not perfect for every application.  Because its strength is really cross platform applications there are compromises all over the place.  If you look at Mac and Linux applications they just don’t have the complex controls that Windows does.  For some this is a deal breaker because their application demands it.  However, if you want a Mac OS X or Linux version of your application you’ll want to redesign the UI anyway.

Ten years ago our clients came to us for Windows apps first and if we could do a Mac version for the graphics geek that was great.  Now, they come to us for Mac apps first and if we can do a Windows version for the accountant in the corner that’s great.  Xojo does web apps now and that’s become an increasingly larger portion of our business and VB6 just doesn’t compete in that area.

The Xojo universe is full of VB6 developers and the Xojo forums are full of them.  The developers that have found and started using Xojo usually go through a short learning curve and a few WTF moments.  And then, after they stop trying to make Xojo work just like VB6, they embrace the tool and enjoy life again.

Windows 10 is yet another bullet dodged for VB6 hold outs.  At what point do you start to panic and find an alternative?  I guess if you’ve waited this long you’re hoping that Microsoft keeps supporting the VB6 runtime forever.

I am biased, naturally, but Xojo really is a good product and a good solution for many applications.  If you would like to find out some rough costs of moving your application to Xojo we have a utility that will give us some metrics on your VB6 project.  It can be found at http://www.bkeeney.com/vb2rbconversion/

Happy coding!

Licensing Systems for Xojo Applications

Posted on by

For years we’ve been using eSellerate for purchasing and licensing and registration of our apps.  We’ve recommended it to clients too and, for the most part, it’s worked quietly, steadily, and hassle-free for many years.  Their plugin is still using the old Real Studio format and they’ve said in several emails that they will not support Xojo going forward.  With Xojo moving to 64 bit in the R3 release it’s time for us to look at alternatives.

We liked eSellerate for a number of reasons.  For one, it was pretty simple.  Once you learned the intricacies of their web portal it was easy to add products.  Their sample app sucked but we figured out a better sample and offered it as an example for others on our website.  After years of using them I could set a new product up in as little as five minutes.  Then, they handled all of the various sales taxes and VAT for the states and countries that need it.

After the purchase, eSellerate would send an email to the user with purchase details.  This included license code, download instructions, and any other messages that we wanted to give them.  And all of this without any intervention on our part.  It just worked.

eSellerate also has an in-application purchase which we found to be pretty useful.  Users could purchase the application without ever having to leave the application.  For some people this was a nice feature but I’m not sure how necessary this is any more.  Lot’s of people purchase things over the internet with no qualms.

When it came to the registration part of things they had a number of nice features.  I could control how many machines could be activated with a single license.  This led to some instances where users didn’t deactivate a license on an old machine and couldn’t activate it on a new one.  However, a 30 second trip to the eSellerate web portal usually solved this.

On very rare occasions we’d get a user that couldn’t activate an app because of security restrictions on their network.  To solve this eSellerate had a manual activation process that would bypass all of that.  It was kind of tedious but then that’s why it’s called a ‘manual’ activation.

Bundling products together was pretty simple and even setting up payments to a third party was easy.  It was flexible and I know it was used in a number of bundle offerings over the years because of its simplicity.

So now we are on the hunt for the next purchasing/licensing/registration system.  We could write our own but I really don’t want to do that for a lot of reasons I won’t go into here.  Ideally, we’d find an existing system that integrates into our website that takes a variety of payment types and also handles sales taxes.  The last thing I want is to get hounded by a government entity – I just want that to happen automatically.

I’d also like to keep the per machine registration with restrictions on how many activations a single license can do.  It must work on Mac OS X, Windows, and the most popular Linux distributions.  Not that we have a lot of Linux applications but we have some and I don’t want two different systems if I can help it.

The in-application purchase and registration was nice but that’s not necessary any more.  I think most people are comfortable now buying over the internet.  However, offline activation is still something that is a requirement.  There’s no telling where customers are and what security restrictions are in place.

I guess the other part of the equation is that I, nor or customers, need something them an arm and a leg.  I’ve see a few licensing schemes that want $300 per product per month.  While they seem really nice, that’s above and beyond what we want and need.

A few names that have come up recently are LimeLM, Paddle, FastSpring, and I suppose even the venerable Kagi is in play.  FastSpring is more of an eCommerce front end so what are you using for application licensing?

What I’d like, Dear Readers, is for you to share your experiences, both positive and negative for any of the services listed.  Have any missed any that should be on the list?