Xojo has had Implicit Instances of Windows and WebPages from the very beginning and I was so happy when they gave us the option of using it or not.  I can tell you from experience debugging newbie apps that Implicit Instance is evil because it often leads to subtle and hard to find errors.

The implicit instance lets us do some very simple things like:

Window1 is shown.  No big deal.  For simple apps this is no problem and fast and easy.  That simplicity comes with some perils because window1 loads whenever any control or property on that window is checked.

For example, a lot of developers will do something  like this:

The problem is that simply by doing this comparison, window1 is loaded into memory and depending on the other window settings it may become visible.  It drives developer crazy.

Setting ImplicitInstance = false forces the developer to make a new instance of Window1 if they want to use it:

I think this is the preferable approach because it’s safer.  It will never give you Window1 by accident.  In fact, if you attempt to do this with window1.implicitinstace = false:

The Xojo compiler will give you an error that says:  Expected a value of type class Window1.Window1, but found a static namespace reference to class Window1.Window1.  This is a roundabout way of saying you can’t call window1 directly since that’s the class name when in reality you need to be checking for an instance of the class. That class instance cannot be named Window1 (because that’s the class name).

So how would you check to see if a Window is already open?  That’s easy.  The Window and WindowCount methods are there for you to do just that.  Iterate through the window listing and when you use the ISA method to ask if it’s of type Window1.  If it is, then do something.

A common thing to do is close all instances of a particular window.  Using the above code might fail if you have multiple instances of a window open.  Here is the code that closes all instances of a type of window.

In this case we must iterate backwards through the array.  Think about it if you are confused as to why.  Better yet, test it yourself.

Web apps have a similar property in the WebSession.PageCount and WebSession.PageAtIndex methods.

The drawback, if you can call it that, to having Implicit Instance = false is that as you call new windows or web pages you haven’t done anything to the old ones.  Depending upon your application this may cause long term memory issues especially as the app gets a collection of pages that are no longer used.   For short lived apps this usually isn’t a problem.

To solve this you can either iterate through the existing windows/pages to find the one you’re looking to reuse or simply close it as you open your new one.  Either way, I don’t think the burden is too high.

It is my not-so-humble opinion, that leaving ImplicitInstance = true is bad for you as a Xojo programmer.  Simply put, Implicit Instance is evil and you should avoid using it – especially in larger applications.

What say you my Xojo developers?    Do you like to turn Implicit Instance off or do you even care?

We released version 1.5.3 of BKS Shorts today.  A number of bug fixes, changes, and additions were added.  The change list below.

I will be the showing off Shorts at the next Xojo webinar on February 2nd at at 1:00 PM (GMT-5:00) Eastern Time (US and Canada).   Signup at https://zoom.us/webinar/register/7a19681a9a0c3f5f7c24e00bf0acd2b8

One of the new items is the ability to show a Row Number on any band using the new SC_GetCount XojoScript.  Add this to any Band Script to modify a TextItem.

We added a couple of new examples based on user feedback.  The first is using the SC_GetCount Band Script to set row numbers.  The second, is an example of how to print directly to a printer without having to go through the viewer.

Change List:

• Added SC_GetCount in the Band XojoScript editor. This lets you get how many times this band has been shown.  Example of use is to have line numbers on your report without having to do it in SQL.
• Updated German localization
• Rearranged UI on ccPAF_Filter (Filter Data) to make it a bit more obvious
• As a Text Item or Field Item are put on a report it will automatically use the “Default Style”
• Fixed an issue where the Default Style wasn’t getting passed to the generated report.
• The Styles Editor now allows you to delete multiple Styles at a time.
• Added a new example of how to print directly to printer without having to use the viewer.
• Reconfigured Demo window to break between Report Designer stuff and older code-only stuff.
• Added SC_GetCount Demo
• Fixed some items in the HTML Renderer
• In PAF_PrintKit.PrintText.constructor if there is no DefaultStyle we create one.
• ReportPF will now extract Styles from the report definition file.

BKS Shorts with the Report Designer is $300 and you get the full source code.  More information can be found at http://www.bkeeney.com/allproducts/bkeeney-shorts/

New Xojo developers are often sorely disappointed with Xojo when first coming to the language.  Why?  The complaints are varied but they usually say things like “<insert part here> doesn’t work right.  In <insert old dev environment> it worked this way.”  I’ve heard this complaint so often that I ignore it.  Don’t convert your app to Xojo, rewrite it in Xojo.

Xojo attracts a lot of VB6 developers.  The IDE’s look a lot alike and the languages at first glance are pretty similar.  The problem is that Xojo isn’t VB6 and most of the things that take huge workarounds in VB6 are almost laughably simple in Xojo.

The first thing many people do is look at the VB Migration Assistant from Xojo.  It isn’t a perfect tool and does not convert any code for you.  Not converting code is actually a good thing because no conversion tool is perfect.  It’s very hard to convert the intent of the original programmer.  Sure, there are rules you could employ to convert code but in my experience the converters create more work for you in the long run.  It’s much easier for a human to look at the VB6 code, figure out the Xojo equivalent and use the Xojo-way of doing things.

At best, the VB Migration Assistant will convert your UI for you.  But given the huge diversity of 3rd party controls for VB6 you will have to work at converting them to standard Xojo controls.  And again, because VB6 doesn’t do some things well, like control subclassing, you might actually be better off rewriting the user interface from scratch in Xojo anyway.

In both cases I said rewriting Xojo.  Sorry.  There is no easy solution to get your VB6 application to work in Xojo.  While the two development tools use a BASIC language that’s about as close as they get.  VB6 is an ancient language by modern standards.  Xojo is updated 4 to 5 times a year and VB6 hasn’t been updated in a long, long time.  Control subclassing in VB6 is impossible and threads are very hard and because of these two things most VB6 apps tend to have huge workarounds to fulfill those needs.

In Xojo these issues just aren’t there.  Subclass controls to your hearts content.  Need a thread or two or a dozen?  No problem it’s a simple to use Xojo class.  Need a 64 bit version?  Want it to run on Mac OS X, Windows, Linux, and Raspberry Pi?  Xojo can do all that easily.  For VB6 that impossible.

If you are contemplating switching to Xojo do NOT look at ‘converting’ your application.  Think about rewriting it.  This means doing some legwork upfront to learn the Xojo particulars and only then writing code.

We’ve converted dozens of VB6 apps over the past fifteen years as Xojo consultants.  We’ve helped teach thousands of developers on how to use Xojo with our Xojo training videos and one-on-one training.  In the long run you’ll be much better off learning the Xojo way of doing things.  Perhaps then you’ll appreciate that Xojo did it better.

Xojo issued a dot release today for Xojo 2015 R4.  Release 4.1 fixes some relatively important bugs and you should update to it.  Even though this was, obviously, released in 2016 any licenses that were valid for 2015 R4 can still update to this release.

If you are using any plugins that are doing drawing via the graphics method you may have noticed that they don’t draw in the proper location in the IDE (but still work in compiled apps).  I noticed this with several Einhugur plugins and those appears to work properly in the IDE now.

A number of new Xojo framework items have been fixed.  Xojo.Core.Date and Xojo.Core.TimeZone no longer leak memory.  Xojo.IO.FolderItem iteration now works on Mac OS X (caused a crash before).

In Windows, the Listbox no longer leaks memory.  In Linux, attempting to send anything to the graphics object from a Printer no longer crashes.

Complete release notes at http://developer.xojo.com/2015r41-release-notes

We released version 1.5.4 of the Report Designer today.  One of the bigger changes is it ships with a web example of how to take a report definition and display it for a web app.  This affects a significant amount of methods and properties throughout the project to make them work on desktop and web but seems to work well.

BKeeney Shorts (with report designer) is 100% Xojo code (DynaPDF Starter kit required to export to PDF) and comes with a drop in Report Designer and Report Viewer component for both desktop and web apps.

For purchasing information please visit http://www.bkeeney.com/allproducts/bkeeney-shorts/

Version 1.5.4 change list:

• Major code changes to allow most classes to work in web apps too.
  • Simply copy BKS_Shorts_ReportDesigner folder into your existing web project.
  • Delete PAF_PrintKit.DesignCanvas (desktop ScrollCanvas subclass)
  • Create a new PAF_PrintKit.DesignCanvas that is a WebCanvas subclass
• Changing text values in the Properties List is now Case Sensitive
• Added Portugese Localization
• Added a commented out example of how to connect to MySQL without using the winDBConnection Window.
  • See winRPTViewer.Display
• Fixed an issue that would cause the SQL statement to not be saved properly in the JSON string
• Added a Default Style if none is in the local dictionary
• How reports are saved so they can be viewed without first having to be in the designer
  • WARNING! YOU WILL NEED TO RESAVE ALL OF YOUR REPORTS
• Cleaned up some localizations and made some more strings dynamic.
• Made the Report Designer the default pushbutton in Demo Window
• New Report opens a new Report Designer Window instead of copying the current connection. (this affected menu handlers in odd ways one wouldn’t expect)
• Created a Web Example

Next Wednesday, February 24th, I will be meeting with Xojo developers in the Palm Coast, Florida area. The location isn’t set yet, so check in the forums at https://forum.xojo.com/28686-central-florida-xojo-user-group and let us know if you can make it. We’re getting together at 7 PM and I hope to see you there!

March 11th, 2016 Christian Schmitz of Monkeybread Software fame is getting tougher with other Xojo folks in Chicago, Illinois near O’Hare Airport. More information at https://forum.xojo.com/28759-xojo-meeting-for-chicago-illinois. I had originally hoped to make this meeting and offer some training but I already had a commitment.

March 15th, 2016, Christian Schmitz is in Cleveland, Ohio. More information at https://forum.xojo.com/28758-xojo-meeting-for-cleveland-ohio

Monkeybread Software is hosting an event in Koblenz, Germany on May 19 and 20, 2016. Two Xojo representatives will be there for this two day event. I went to one of these events a couple of years ago and had a really good time. The Xojo conference was fun and the day after the event a number of us went on a tour along the Rhine River Valley. Fun had by all! More information at http://www.monkeybreadsoftware.de/xojo/events/koblenz-2016-event.shtml

The big Xojo event of the year is October 5-7, 2016 in Houston, Texas. The Xojo Developers Conference (XDC) will have twenty-eight speakers, thirty-five sessions, and attendees from around fifteen countries. The entire Xojo development team will be there and what’s discussed at meals and events is just as important as the sessions. It’s not an inexpensive event, but if you want to learn more about Xojo and pick the brains of Xojo experts, XDC is THE event to go to. More info at http://xojo.com/xdc/HTML/index.html.

Getting together with other Xojo developers is a lot of fun.  I highly encourage you to find other developers in your area and start sharing the knowledge!

Today I’m going to talk about the Imposter Syndrome.  That feeling that says everyone knows you’re faking it and they’re going to find out, at any minute, that you’re a fraud.  You’ll be cast down into the depths of despair in humiliation because EVERYONE WILL KNOW YOU SUCK!

I’ve experienced this feeling and I’ve had conversations with developers I greatly admire that struggle with this too.  This is both heartening because it means we’re not alone in this despair, but it’s also sad since that means there’s really not a point where you’ve ‘made it.’
Feeling like an imposter doesn’t go away as you gain experience but it’s not as big a deal.  With more experience you know the things you know and have hopefully gained enough knowledge and wisdom to know where to start looking for the things you don’t know.  Still, sometimes, you have to fake it.

Wait, fake it?  Yes.  Sometimes you have to be an imposter.  Let me use a poor analogy to explain it a bit more.

When you start a new video game you just start playing, right?  You know a few rules and as you progress you make mistakes.  You learn from them and at some point you level up.  This comes with a fancy cut scene showing your character victorious over the foe, gaining an object of some value, and gaining experience.  Your character is more wise and capable of doing more things.  You were up for the challenge and overcame the barriers to the next level.

Being a consultant and software developer is no different than a video game.  You have to play the game to learn the rules.  The consequences of not learning the rules can be disastrous but hopefully you’ve done your research so those rules don’t kill you (metaphorically speaking, of course).

At some point you level up from time and experience doing consulting and programming projects.  Sadly, there is no amazing cut scene with dramatic music since we rarely, if ever, see the level up process.  It’s shame really because I’d really like to have dramatic music just play from nowhere and obtain some cool device from my endeavors.  But I digress.

For a Xojo consultant, like myself, it’s knowing parts of the framework really well and realizing that I don’t know some parts as well.  I do a ton of small example projects to learn those bits better.  It means creating my own tools to make my daily life easier.  Those tools involve ActiveRecord, and Shorts to name a few.  These were not developed overnight but over the period of a decade.

So the next time you feel the Imposter Syndrome hitting, recognize that it’s a natural part of the process.  You leveled up without noticing and that’s okay.  You can handle it.  It means you’re winning.

It’s been an interesting couple of weeks in the cross-platform development world.  First, Microsoft announced that they were purchasing Xamarin.  Xamarin and Microsoft have always been friendly and this move isn’t very surprising.  As a Mac user much of the marketing verbiage doesn’t talk about the Macintosh, just iOS along with Android and Windows Phone and Windows apps.  Xamarin has always seemed to be mobile first and desktop last, so again, this doesn’t seem surprising.

Many people really like Xamarin and there are a number of Xojo developers that have tried it out.  Their opinion of Xamarin isn’t very good:  limited support, expensive, buggy IDE, and slow building of apps are just a few of the major complaints.  In comparison Xojo, they say, is ‘fast and lean’.

This week Microsoft announced that SQL Server, their Windows-only database server will be ported to Linux and be available in 2017.  This seems to be a tacit agreement that their biggest weakness in the server world is Linux.  Linux is extremely popular and since it’s cheaper to deploy than Windows they have to do something to stop the hemorrhaging.  Perhaps they’ll sell a boatload of licenses but it’s tough competing against the free or inexpensive database servers like PostgreSQL.  Again, no where are they talking Macintosh OS X.

This news makes me happy that cross-platform app development is getting some attention.  When the big boys of the world are pumping money into it then there must be something to it.

It also makes me sad since I don’t see Xojo changing their focus.  For many years they have had this hobbyist/part-time developer first mentality.  This has hurt them with professionals looking for a new development tool.  There are many things, I believe, that hurt them in this market.  I’ll list a few here:

• It’s a BASIC language:  No getting around it.  It’s a modern object oriented language that compiles down to native code, and (mostly) uses native controls doesn’t seem to matter much.  VB6 screwed up many peoples opinions of language for better or worse.  In reality, there are lots of really good VB6 apps out there but many more poor VB6 programmers.
• The IDE: especially the Code Editor.  It doesn’t let you do bad things and that’s great for beginners.  Usually it’s the first thing people complain about, though.  It’s limiting, and forces you into the Xojo way of doing things.  No other major IDE, that I’m aware of, forces this restriction upon their users.
• Lack of basic controls:  I’ve been using Xojo for 15 years and have a tool chest of controls and libraries that I use on a daily basis.  But still, the lack of even basic Date/Calendar controls is a turn off for many first-time users.  Add in very poor RTF support, no PDF support, and especially no true grid control and you have a lot of strikes against the tool.  Yes, you can turn to the 3rd party community for some of these (and they are not very expensive) but to not have any of these things hampers adoption.
• Reporting:  I don’t know of any serious Xojo developer using the built-in reporting tool.  It’s just not robust enough for most peoples needs.  We’ve used several 3rd party tools over the years and in the long run wrote our own (BKS Shorts).
• Android:  iOS was a big addition to Xojo but without Android it’s not convenient to do a lot of mobile development with Xojo.  To add Android is a huge project and unlike anything they’ve done to date.  I would expect a minimum of eighteen months but probably more like two years of major development work to get it into Xojo even as a beta.  And that’s assuming they announce it.

I use Xojo all day every day and use it for dozens of commercial desktop applications and dozens of Xojo driven web apps.  Xojo is mostly stable and under constant development.  Just in the past year they’ve added iOS and Raspberry Pi development as well as added 64 bit compiling for Mac OS X, Windows, and Linux.  Much of the limitations you can overcome by dipping your toes into the 3rd party market – but that market is tiny in comparison to many other development tools.

So my wish is that Xojo would focus more on business needs.  Identify the features that business owners need and implement them.  Include more basic controls and charge more for advanced controls that not every developer will need.  Get reporting cleaned up.  Make database programming smarter and less error prone.

It is my firm belief that if you get the business users you’ll capture the part-time and hobbyist programmers along the way.  Many of the hobbyist and part-timers only care about one platform and that’s only a $99/year investment.  If you want to do cross-platform desktop that’s only that’s $299/year.  For every desktop license you need three single licenses.

A Pro user like myself needs desktop, web, and console apps for sure.  iOS is a nice add-on but not necessary for us at this point.  The Pro license costs $699/year.  You need seven single licenses to make up for it.  My company has four licenses and we renew every year.  So my business is the equivalent of twenty-eight single license users and while I might grumble at writing a check every year for license updates it’s nothing at what we used to pay for VB6 and 3rd party licenses every year.  At one point it was $2,000 per developer per year.  That’s just the price of doing business.

So tell me, which type of customer should Xojo focus on?  What do you think their biggest weakness is in capturing some of this nascent cross-platform market?

BKeeney Software is proud to announce Version 1.6.0 of BKS Shorts with Report Designer, our reporting classes and tool for Xojo.  Shorts allows you to integrate a report designer into your own Xojo desktop application.  Desktop and Web applications can generate reports.  Both versions can export to PDF if they have the MonkeyBread DynaPDF plugin.

This is a recommended update for all registered users and is a free upgrade.  Besides a number of important bug fixes there are also some big new features

The first is the ability to ask the user for runtime parameters for a query.  For example, if you created a report based on a fiscal year you can now ask the user which fiscal year they want.  The dynamic runtime query lets you ask the user for a number of different things.  Strings, numbers, user supplied lists, and even a list based on a database query are possible.
The second thing we added is the ability to get an event back from the generated report on what row was clicked.  This event gives you the information for all objects in that row so you could implement a drill-down report.  Along with this event we now allow invisible objects to be created to provide additional information.

Our product page is at http://www.bkeeney.com/allproducts/bkeeney-shorts/

Full change list:

• Dynamic Runtime Query variables. Allows the report designer to ask the user what values they want at runtime. Current paramters types::
– Boolean value using a Checkbox
– String value
– Numeric (integer and double values)
– User List (popup)
– Query List (popup)
– Date, DateTime, or Time

• Moving items via the mouse will immediately update the save status on the Toolbar

• Changing Filter Data will update the save status and undo status

• Undo now works for changing of filter data.

• Added Filter Data to report designer Toolbar

• Added an ObjectSelected event on the BKS_ShortsBaseViewer that will pass back the clicked BKS_Shorts.Item and if there is one, the BKS_Shorts.GroupItem. This will allow you to implement a drill down report.

• Invisible TextItems are rendered in the background color to allow the MouseHit to bring back additional information in the group

• Added a FieldName property to BKS_Shorts.Item and reports run through the Report Designer will fill that in at generation time. This allows the user to query what the field (if there is one) from the selected item.

• Added OK/Cancel generic container for all dialogs

• Bug Fix [Windows Only]: Now respect the number of copies specified for a print. Note that this is not in Shorts classes itself but how the supporting code prints.

• Bug Fix: Fixed another instance where it was possible to NOT have a Default Style when generating a report.

• Improved German localizations.

• Moved About Shorts Designer Menu Item out of winReportDesigner

• Bands that are marked as invisible no longer get rendered on the report.
Known Limitations:
• Dynamic Queries do not work with IN clause in where statements.

One of the things that’s just not talked about much in the Xojo documentation unless you know where it is located is object casting.  ISA and Casting is so useful it’s worth devoting some time talking about it.

Let’s start with some common examples in desktop applications.  We all use the Window class.  Typically our new projects start with an instance of the Window class called Window1.  To put it another way, the Superclass of Window1 is Window.

The ImplicitInstance property of windows is subtly evil.  Subtle because if you reference anything in Window1 it gets created if it’s not already.  A lot of new Xojo developers will ask how can they tell if a window is open or not.  They’ll often come up with something like this:

If window1 is not open this line will actually create it!  So this is a bad thing and why I recommend that you turn off ImplicitInstance on all windows until you understand the implications.  I digress.

The better way to tell if an instance of Window1 is open is to iterate through global Window method.  You can do that by doing something like this:

This will iterate through every window, visible or not, that the application has created.  I used DownTo because many times you want to close said window and going UP will cause funky things to happen to your array of windows (I will leave this as an exercise for yourself).

If you put a public property in Window1, say, s as string.  You cannot do the following:

The compiler will squawk with an error:  Type “Window” has no member names “s”.  This might seem mysterious, but the window returned from the Window array is a Window, not the subclass window1.  It’s an important difference.  The framework call to Window brings back a listing of all Windows even though each individual window brought back will be a subclass.  The array must all be of the same class type (Window) for it to work so the framework uses the Super.  To work with the Window1 properties you have to cast the window returned to an instance of Window1.

If you only have one window type (highly unlikely in a real app) you could simply cast any windows to window1 but that’s unrealistic.  Instead, you need to check what type it is first.  Using the ISA operator you can test what kind of window subclass it is.  If w is an instance of Window1 than you can do something with it.

The next step is to cast the window to the subclass.  This is as simple as wrapping the window variable, in this case w, with the name of the subclass, Window1.

If your code is wrong, or you try to cast it the wrong window type you’ll generate an exception at runtime that says Window1 cannot be cast to whatever the object you’ve put in.  For example, the following code generates that error:

This type of paradigm is common throughout Xojo.  We already know about the Window and WindowCount methods.  Another commonly used one is the Control and ControlCount on a Window.  Code like this happens quite a bit:

This works fine as long as your control is actually a RectControl.  Not all items returned by the controls method are RectControls. Checking with the ISA operator before casting is important.

The ISA function and Casting can be an important tool in your application.  It can take what would be some tricky Introspection and turns it into a trivial piece of code.  It’s also one of those things that you don’t know you need it until you need it.

BKeeney Software is proud to announce Version 1.6.1 of BKS Shorts with Report Designer, our reporting classes and tool for Xojo.  Shorts allows you to integrate a report designer into your own Xojo desktop application.  Desktop and Web applications can generate reports.  Both versions can export to PDF if they have the MonkeyBread DynaPDF plugin.

This is a free update to all existing users.  This version is mostly a bug fix release and is recommended for all users.

Change List:

• The Footer Constants can now also be used in the header
• Refactored DesignCanvas and ReportPF and moved some of that code into PAF_DatabaseKit.DBWrapper where it makes more sense
• Loading a report into the designer, or for rendering, will no longer re-read the schema and overwrite any manually created relationships
• Added Tables and Views section into the report definition file
• Fixed an issue with report width/height not being remembered correctly. Changed from using PrinterSetup string which is not cross platform safe to use the dimentions instead.
  • YOU NEED TO RESAVE YOUR REPORTS TO TAKE ADVANTAGE OF CHANGE
• Fixed issue where landscape reports weren’t being exported properly to HTML and PDF.
• Added breaks in the PreparedStatement creation to help in debugging.
• Added some missing field handling to ODBC
• DBWrapper will no longer create a missing SQLite Database.
• Fixed UI in winDBRelations

Xojo 2016 Release 1.1 hit the web today and this version should be the one you’re using from now on.  This dot release fixes a number of critical and important things.

First off, web app compile times just got much better.  Building a 64 bit Linux web application went from five minutes in 2016 R1 to just three minutes in 2016 R1.1 (both versions had to recompile the plugins so take two minutes off that for an average time). This is a marvelous and unexpected surprise in R1.1.

The Web Page Layout editor that was a dog in R1 is much improved.  A complex web page with multiple containers and controls is now nearly flawless when dragging controls around on the page.  This one feature alone is the worth upgrading to R1.1.

The MySQL plugin no longer crashes when a closing the database connection.

BMP’s with a mask dragged into a Linux project long longer throws an out of bounds exception when the app is launched.  Xojo.Net.HTTPSocket was also updated.

In Windows, the SaveAsDialog no longer returns the wrong name if anything in the file path has a period in it.  Xojo.Crypto.RSAGeneratePair no longer crashes.  The new Language Reference no longer has high CPU usage and the Windows IDE no longer crashes when a remote debug app quits.

Besides the web page editor, the IDE also received a few fixes.  Perhaps most important is that searching the project no longer results in a crash for some developers.

Read about all of the R1.1 changes in the release notes.

All-in-all R1.1 is a welcome version and I recommend that you update to it immediately.  What do you think?

Most of us want an easy button when it comes to software development.  Out of the dark ages when you literally had to code everything yourself came the frameworks that did a lot of the dirty work for you and all you needed was to figure out what those framework calls were.  Tools like Xojo make this even easier because the framework has been around a long time, well known and documented, and mostly complete.  Add in the rise of internet searching and it’s quite possible to find huge chunks of code that do what you want.  Be wary, though, because that convenient piece of code you just found might have bugs in it.

The reality of programming is that any code that you didn’t write should be considered suspect.  That’s not the same thing as saying Other Peoples Code (OPC) is wrong, it might be perfectly safe to use, but you really should vet the code and thoroughly test it before putting it into your application.

I’ve seen it on the Xojo forums where someone whips out some code from memory and it contains a bug or simply doesn’t work.  The person asking the question then gets mad that it doesn’t work.  Normally the bug is simple to fix but it’s obvious that in many cases the developer getting mad didn’t even attempt to read any documentation.  Come on, people!  If it was that easy, we’d have created AI’s to do the programming by now.

Really, in the long run, you need to understand what you’ve copied.  Maybe it looks right on screen but it is horribly optimized, or worse.  Maybe it calls into the netherworld and summons Cthulhu.  Anything is possible, right?  Do you want to be responsible for the software Armageddon in your company?

Much of the example code given on the internet is lacking defensive coding for the sake brevity.  This can lead to runtime exceptions that can cause needless headaches.  If I had a $1 for every Xojo programming that’s wondered why their Recordset is coming back nil and not checking for database errors I’d could probably buy an enterprise license of Xojo every year.

It’s been my experience that any code you find you will have to tweak it (either a little or a lot) to fit the business requirements of your application.  If you don’t understand the code you’ll never be able to figure that part of it out.  Learn the individual bits of code and learn how to use the debugger for heavens sake.  The Xojo documentation has some great information.  The debugger is your friend!

When it’s your own code that you’re copying and pasting (especially in the same project) it’s a very strong indicator that you should refactor your code.  Perhaps making a global method or making a helper class makes sense.  That’s actually a good time to ask the forum on the best strategy because you’ll probably get two or three different responses.  Learning new techniques is good and in the in long run those will become new tools in your arsenal of programming tricks.  And remember that in a year or two you’ll look back at your coding today and be embarrassed (this is natural) because you’ve learned SO much since then.

There is no easy button when it comes to software development.  Even with RAD tools like Xojo you need to learn the language and the framework to bend it to your will.  Sure, use OPC as a way to learn how parts of it work but copying and pasting verbatim without learning why it works is a recipe for disaster.

Happy Coding!

BKeeney Software is proud to announce Version 1.6.2 of BKS Shorts with Report Designer, our reporting classes and tool for Xojo.  Shorts allows you to integrate a report designer into your own Xojo desktop application.  Desktop and Web applications can generate reports.  Both versions can export to PDF if they have the MonkeyBread DynaPDF plugin.

This is a free update to all existing users.  This version fixes a couple of important bugs and is recommended for all users.  In this version we also added a CSV Renderer that allows you to export your reports to CSV in addition to HTML and PDF.

Product Home Page:  http://www.bkeeney.com/allproducts/bkeeney-shorts/

New:

• Added a CSV Renderer that can export reports to CSV format ignoring page headers and footers.  (Note: CSV Export isn’t perfect. We’re just taking the text and putting it in a file.)
• Added CSV Export into the File->Export Menu to give example.
• Added Chinook Invoice Database Example.
• Added ability to get exception messages back from the Report Thread.

Changes:

• Tightened up the spacing in the dynamic DateTime container.
• Did some prep work in the Designer and in ReportPF to allow fields in the header in a future release.

Bug Fixes:

• Fixed Formatting of page numbers so it can go up to 4 digits.
• Fixed loading of Schema and Views in the report viewer.
• When opening a report the view switches automatically to the Design View.
• Fixed an issue where adding ? to the Filter Data (thus making it a dynamic runtime variable) would not get saved without unchecking and checking the dynamic checkbox in the list.
• Fixed issue with Lines line staying put in proper location in the Designer.
• Fixed issue where adding a Field in the Header of the report would cause what appeared to be an infinite loop (really was an exception in the thread). Now it will finish the report.

One of the challenges I see regularly in my work as a database administrator is finding a way to bridge the gap between the well-normalized physical implementation of a database behind an application and providing a way to make the data available in an easy-to-use (and understand) fashion for the end user.  For many clients this means letting them design their own reports.  Database views are my go-to method for making a complex database structure easy to use for end-users and even developers.

Views have a number of advantages.  For one, they are available in all SQL databases, including SQLite.  Views allow you to reduce the complexity of the end user experience by managing and limiting the data presented.  This might mean taking a very complex query joining multiple tables and presenting it in a single table with the end user (or developer) not needing to know the gory details of the SQL behind it.

This last point is important for the developers too.  Having the programmers figure out the complex joins for a query pulling from multiple tables is sometimes challenging and not always a good use of their time.  Having the Xojo application do all that work for a complex query is sometimes painfully slow.  Views not only speed up the development process but make the Xojo application more efficient since the database has already created the view and optimized it internally.

Views are more secure since you can limit the data shown and control who has the rights to view it.  By giving users and developers access to the underlying tables you may be exposing sensitive data.  Views are an easy way of sanitizing data.  We use views as read-only constructs so the user cannot update the data (note:  not all databases treat views as read-only).

Views can be created, modified and deleted via simple SQL statements.  The syntax of the statements (in particular for modifying views) varies a bit from database to database but the details can be easily found.  To create a view, the syntax is:

    CREATE VIEW viewname AS

SELECT (fill in your query here)

We recently used views implementing a large customer records management (CRM) system for an insurance broker.  Their database has around 100 tables containing information on customers, policies, related products, agent and commission data.  The data is normalized and it isn’t always straightforward to get related data.  The client does not have a dedicated IT staff and reporting is the primary responsibility of a part-time administrative employee, “Jane”.

Our goal was to provide Jane with the easiest means possible to write any report that was requested by management.  While Jane has some knowledge of databases and foreign keys, she isn’t technical and doesn’t have any training on the SQL language.

Our answer was to use our desktop reporting tool, BKeeney Shorts, customized to only show her views created solely for reporting.  (We did this via a simple naming standard in the database.)  She is presented with options such as:  Agent Commission, Prospect Contact and Client Policy Details.  If she needs an additional view, it’s easy to add it to the database and not impact the Xojo code behind the application. (It doesn’t require a recompile and redeployment of the software).

The view incorporates the calculations behind the data, so the reports are always consistent in terms of things such as how commission checks are calculated or who is the primary agent for an account.  By using views we ensure that consistent results are shown to the end user even if someone else is assigned to write reports

Views provide a level of abstraction between the database and the end user and we find  them very useful.  For the developers, it means they don’t have to figure out the complex queries and have the Xojo application create inefficient and complex queries.  Views are your friend!

BKeeney Software, Inc. is proud to welcome Tim Parnell as the newest addition to our full-time staff.  Tim will be working on several high profile client projects for BKeeney in addition to lending his skills to all of the BKeeney products.

Tim has been writing software for nine years and is known for his work on MacDust and with TinyGrab and MacHeist.  He has also been active in the Xojo community with his HTML Edit and Answers products and is an active contributor in the Xojo forums.

Bob Keeney, Vice President of BKeeney Software said, “We’re excited about bringing Tim on board.  His experience with web technologies in addition to his Xojo skills enhances the mix of services we can offer to our clients.”

BKeeney Software, Inc is a consulting and software development company that has been around since 2002, specializing in Xojo application development.  BKeeney offers Xojo training, tutorials, source code and developer products.  www.bkeeney.com

One of the strengths of Xojo is that it creates a no requirements executable package.  For Mac OS X it puts all required libraries and resources in the application bundle and for Windows and Linux it puts all the necessary files into the Libs and Resources folders.  This makes installing your apps on Windows and Linux pretty easy because you did not need an installer (however it’s highly recommended you use installers!).

Xojo 2016 Release 1, however, has a new requirement that is biting some users fairly hard.  Some Windows 7 and 8 users get an error staying that it can’t start because it’s missing the api-ms-win-crt-runtime-l1-1-0.dll.  This error is because Xojo Windows framework was updated to use the latest Microsoft tools which means the “Universal C Runtime”.

This new runtime is shipped with Windows 10 and should be part of a fully updated Windows 7 and Windows 8 installation and because of this Xojo is not distributing the DLL when they build an application.  The past few months have shown us that many people do not automatically update their systems.  It’s pretty easy to replicate this behavior in a VM environment.  Simply do the base install of Windows 7 or 8 (doesn’t matter if it’s 32 bit or 64 bit) and without doing the hundreds of updates required to bring that version of Windows up to date, run a Xojo application.

There are three solutions to this problem.  First, have the user do all of the available Windows Updates which should install the runtime.  The second, is to have the user download the runtime installer from Microsoft.  The third option, is to add it to your installer.

We use InnoSetup for creating our Windows installers.  Xojo has conveniently added the redistributable to the Xojo download package so we can use it.  Look in the Extras/Windows Runtime/Installers/ directory to find these installers.  Adding this into your installer is relatively painless.

In the [Files] section of your Innosetup script, add the following line:

Source: “VC_redist.x86.exe”; DestDir: {tmp}

Then, in the [Run] section, add this line to have it installed automatically:

Filename: {tmp}\VC_redist.x86.exe; Parameters: “/install /quiet /norestart”; StatusMsg: “Installing 32-bit runtime…”; Flags: waituntilterminated

This is a no fuss way to add it to your installer.  It only adds about 14 MB to your installer.  Most users will never see it because they’re up to date.

I highly recommend that you peruse the PDF provided by Xojo on this topic at Documentation/WindowsUniversalRuntime.pdf.

In our testing installing the new runtime has not caused any issues.  The clients that have had this added for them have reported no issues either so I think it’s pretty safe.  Some Xojo forum users, however, have reported that their Windows installation will hang when trying to install the Runtime.  Have you experienced any issues with the runtime?

BKeeney Software is pleased to announce a new release of BKeeney Shorts, their Reporting tool for Xojo.  BKS Shorts allows users to embed a report designer into their desktop applications and render reports onscreen, to a printer, as well as to HTML, CSV, and PDF formats (PDF requires a DynaPDF license). Web applications can render reports to HTML, CSV and PDF Formats.

Version 1.7 is an extensive update with a new, faster, file format.  Users with dynamic queries can now put a summary of selections in the header.  Dynamic queries that use popup list selections can now make them optional.  And much, much more.  Complete change list below.

BKeeney Shorts Product Page:  http://www.bkeeney.com/allproducts/bkeeney-shorts/

BKeeney Shorts costs $300 and is shipped with 100% unencrypted Xojo source code.

New Features:

• Added SupressField property to Fields. This will keep rows with identical text to the row above it from displaying. Resets on each page.
• Added ?? shortcut to Header/Footer bands to be able to put report parameters into the report. Feedback appreciated.
• Added check upon opening reports in the designer to see if all fields in the report are still valid.
• Now provide an error message to user if there were any errors while generating report.
• Added a Version field to the report to make it easier for future file format changes. New file format is 1. Added a conversion routine to convert to version 1.
• The Property List now has a dedicated popup menu for Date fields.
• The Query List Dynamic queries can now be made optional to ‘select all’ for that field.

Changes:

• Now provide feedback to the user during report generation. This will give rough estimates of numbers of rows created.
• When switching back to Design view we now make sure the thread generating the report is killed if still running.
• Major rewrite to the DBWrapper class to make it much more effecient.
• PAF_QueryCondition made part of the PAF_DatabaseKit and renamed to PAF_DatabaseKit.QueryCondition
• Reports will save the DefaultStyle from the StylesList.
• Added some Localization strings into the object list.
• Removed the Contextual Menu from the Property List format item. Only used for Dates and it now has dedicated Date Popup.
• Added a WaterMark to two of the Coded reports.

Bug Fixes:

• Fixed issue where Grand Summary bands weren’t working.
• Views are now properly vetted through the TableViewAddCheck.
• Rescanning the schema will refresh the object list properly now.
• Can no longer drag a report objects (from the Report section of the Object List) into the designer. Now you can only drag fields and report primitives.
• Repeat Each Page and Page Break are now only valid and displayed for group headers.
• Adding/Removing items from the Designer now updates the Report Objects section of the object list.
• Fixed wording in the Band Editor.
• Background Text Color now saved properly in Style editor.
• Pressing Enter/Return while in the Properties List will update the object in the Editor.
• Fixed issue with report time in Report Footer if user had never set format in preferences.
• Fixed issue with line objects not calculating their top/right property properly.
• Fixed a date conversion issue when formatting the dates to other than default.
• Fixed mouse handling and drawing issues when the canvas width was smaller than the page width.
• Fixed Report window Title not showing on initial save of report in designer.
• Fixed odd random Nil Object Exceptions when updating from the property list.
• Fixed the WindowMenu class to work with multiple menu bars used in the project.
• Fixed issues with the IsFunction property when generating reports.

July 5th is National BKeeney…er…Bikini Day.  In celebration we’re offering all of our products at 30% off for the next 48 hours.  Apply the coupon BIKINI in our online store to receive the discount on the following products:

ARGen:  Our utility for creating ActiveRecord classes for use with Xojo.  Make the IDE work for you when developing your Xojo database applications.

BKS Spell Check Plugin:  Easily add spell checking to your Xojo applications with our Mac and Windows plugin that can either use the System dictionary or use a Hunspell dictionary.

Calendar Classes:  Add Day, Week, and Month views to your Xojo applications.

BKeeney Shorts Professional:  Create and render reports in your Xojo desktop and web applications.  Renders to screen, printer, HTML, CSV, and PDF formats.

Formatted Text Control:  A TextArea replacement that allows inline pictures, hyperlinks, and much more.

FTC and Spell Checker Plugin:  Get the FTC control with the spell checker.

Simple Help Editor:  Making help systems stinks.  This utility helps make it easy.

Styled HTML Field:  Export from a StyledText field to HTML.  Handy if you’re going to add HTML to emails sent from Xojo applications.

Task Timer 5 (Mac and Windows):  If you aren’t tracking your time you’re missing out on a key metric on how well you estimate and where you spend more of your time.

Xojo Trainer (Download and Flash versions):  Learn Xojo (offline) from Xojo professionals with over 15 years of Xojo development experience.

Visit our online store to see all our products or visit any of the product pages to get more information on them.

Last week Xojo 2016 Release 2 was unleashed to the masses.  There are a lot of changes and tweaks in this version and if you are creating web or iOS applications there is a lot of like about this release.  There are also a myriad of changes and enhancements that should satisfy most developers.

iOS Stuff

The biggest changes in R2 is for iOS and these are things that developers have been requesting since its initial release.  Support for iOS 7 has been dropped because its market share is less than 20% and the minimum required version is now iOS 8.  This also means that Xcode 7 or Xcode 8 needs to be installed.

The Xojo engineers added iOSScrollableArea which allows you to view and display content that is larger than the view.  This is a very welcome addition and is worth the upgrade for this feature alone.

R2 also adds the iOSLocation class that allows your application to request location coordinates as well as get updates from the device.  Once your application gets permission to access the device location you receive changes via the LocationChanged event that gives you latitude, longitude, altitude, course and speed parameters.  An Accuracy property lets you change the desired accuracy.  In addition to iOSLocation Xojo has added the iOSMotion class that allows developers to access the accelerometer and gyroscope.

iOSTable was arguably the most useful and least powerful control in iOS for Xojo and this release definitely gives it some love.  You can now embed controls in the cells of iOSTable by using the iOSCustomTableCell class.  This allows you to create some very rich and powerful UI that lives in the cell of an iOSTable.  I guess the best equivalent in desktop and web terms is that the iOSCustomTableCell is a specialized ContainerControl you can put into an iOSTable cell.  I’m looking forward to using this.

They’ve also added support for Row Actions in the iOSTable.  The new ActionsForRow event passes in the section and row and you have to supply the iOSTableRowAction array.  The iOSTableRowAction has a title, an Auto tag and a Style.  The style can be either Normal or Destructive with Destructive changing the background of the Action to red (does this ever vary? – not sure).

The new iOSSharingPanel allows you to share pictures, text and URL’s with any registered system service or app.  That’s a fancy way of saying you can share this data between applications.  It’s the iOS version of the clipboard available to desktop applications.

The iOSPicturePicker class allows you to select images on the device or take pictures with the camera.

To avoid confusion for users, the old SQLiteDatabase class for iOS has been renamed iOSSQLiteDatabase.  The corresponding recordset class is now named iOSSQLiteRecordSet.

Non-IOS stuff

The Web framework is now HiDPI capable.  It works similarly as desktop apps in that it queries the browser for the scaling factor.  Then, the application serves up the proper image if it can.  You can change how this works by changing the Supports HiDPI in the Shared Build Settings.

In Windows there are a number of significant HiDPI changes that make it work better in Windows 8.1 and 10.  Perhaps the biggest Windows change is that Xojo.Net.HTTPSocket is no longer much slower than HTTPSecureSocket.  I have not had a chance to look at this one in detail yet so if you’ve had success or failure with it, please leave a comment below.

Always check the release notes that are in every release.  I’m just hitting the highlights out of hundreds of line items and you never know what might be there that affects your application.

As with any new release it’s better to test your project against it before releasing it into the wild.  In my own testing I had some instability with converting an old web project (started around the very first public beta of Web Edition) to use HiDPI graphics.  This involved adding an ImageSet and adding the 1x and 2x graphics, deleting the old graphic, and then fixing it in all locations in the project.  I was able to crash the IDE but all of the crashes were different and, of course, none of it was reproducible.

The Future

The 800 pound gorilla in the room is a 64 bit IDE and 64 bit debugging.  Things like XojoScript are holding back the IDE from being 64 bit.  I would also imagine that not having an integrated debugger available in 64 bit is holding back that as well.  I know we are avoiding releasing some 64 bit projects because of these limitations. We’ve also been playing around with the Raspberry Pi and it’s definitely not very useful without the debugger.

We need the 64 bit debugger.  Let’s hope that R3 provides us with some relief in that area!

How has your experience been with R2 so far?