Don’t Overuse Variants

At XDC 2019 my session was titled Xojo Design Mistakes (the alternate but way longer title was ‘Thankfully time travel doesn’t exist or my future self might travel back and murder my younger self for the stupid coding mistakes I’ve made’).  These are things that I’ve discovered over the years, both in my own projects and in other peoples projects that are just plain wrong or less than ideal.  This will be an on-going series since I had well over 50 slides and left about 150 out.  So when I get bored I’ll bring these topics up.

Variants are a very powerful datatype in Xojo. It allows you do set it to anything including null. It’s a wonderful thing to use in ListBox row, column, and cell tags where the you, the developer, could be anything into it.

Variants are evil too if you use them in ways you shouldn’t. Take the example below:

This is truly a made up example but it shows how subtle Variants can stab you in the back. Just adding the three Variants together where one is a string, the other an integer, and the other a double, can change depending on the order they’re used. Frankly, I don’t care how the compiler came up with the value because in both cases it’s ‘wrong’. Wrong in the sense that it depends on order and no programmer should have to depend on order.

How did we get here? Variants have implicit conversion. So if you try to add a variant to an integer it attempts to convert it to an integer. If you try to add it to a string it converts it to a string. What happens if you have a number inside the string and it really should be a string? The answer is that it depends.

That’s just a poor use of the language, in my opinion. Xojo is a strongly typed language and I like that it won’t let me willingly add an integer to a string. I like that I have to explicitly convert from one datatype to another. Variants break that rule in that they’ll implicitly convert from one to the other and the compiler will never tell you.

The variant datatype allows the Xojo developer to query what it is. For example you can use the Type method to see what variable type is it. You can see if it’s an array using the IsArray method. You can see if it’s a Numeric value using IsNumeric but you get into the same problem where assigning an integer 8 and a string “8” will both return true from IsNumeric. So it’s a bit of a problem because it could be either. We should rename it Schrödinger’s datatype because it could either either value until the compiler asks for it.

Auto was introduced in the Xojo framework (deprecated now?) to replace Variant. It didn’t do any implicit conversion for you. In fact, it wouldn’t even tell you what datatype was in it and the only way to do was to use Introspection. It certainly solved the problem of implicit data conversion but replaced it with a harder to use datatype. For what it’s worth I didn’t think it was hard to come up with your own “what is your type” methods using the extends keyword but it was something that many Xojo developers weren’t comfortable doing and frankly seemed silly to rely on Introspection to do that work.

I turned down a project many years ago because the original developer had used Variants for everything. Didn’t matter what (local, object, global), they used variants and they wanted me to tell them why their project wasn’t working right. When I told them I wouldn’t do it and asked why they had used variants for everything they simply said, “Because they could be anything. Why not use them?”

I know that many languages are not as strictly typed as Xojo and perhaps that’s where they came up with that mentality. I find some comfort in knowing that if I try to put a string into a numeric value the compiler won’t let me unless I explicitly convert it. I like the certainty of knowing that my data can’t change on my unless I tell it too.

Variants are good for storing things temporarily. Stashing values and objects in a Tag for use later is convenient and useful and a good use for them. For everything else it makes sense to use a datatype. If you finding yourself using a lot variants you should rethink what you’re doing because they can subtly make your calculations change in ways you don’t expect.

Formatted Text Control 3.2.1

BKeeney Software has released version 3.2.1 of the Formatted Text Control, a canvas based word processing control for Xojo Mac OS X and Windows applications. The FTC is an alternative to the built-in TextArea control and allows for in-line graphics, hyperlinks, custom components, better RTF support and much more. The demo project has quite a few examples, including a Masked Text Field, XojoScript example, Embedded FTC (in your own canvas), as well as a word processor with page view.

The Formatted Text Control costs $150 and is 100% unencrypted Xojo code. Version 3 and above requires the use of the Text Input Canvas plugin (included in package) to allow for proper text handling in Cocoa builds.

Download links and more information at http://www.bkeeney.com/formatted-text-control/ 

This version has a number of bug fixes reported by users since release. It is recommended for all users. Registered users should be receiving an email from our automated distribution system.

Bug Fixes:

  • Fixed issue where all StyleRuns after a hyperlink will also be marked as hyperlink
  • Issue #4074: RTF clipboard ignores hyperlinks with umlauts and cuts them
  • Issue #4087: missing RTF space after “\kerning0” keyword
  • Issue #4130: FTXojoScriptField: Left part of the text is hidden by the section of the line number.
  • Issue #4135: Migrating texts from a TextArea to the FTC (Ich migrieren Texte aus einer TextArea in das FTC)
  • Issue #4196: Remove GOTO calls from FTC

Enterprise Code Signing for iOS in Xojo

There’s been a feedback report (47975) for several years asking for the ability to use enterprise code signing certificates for building our Xojo iOS applications.  So far nothing from Xojo but there is a way to create enterprise code signed iOS app for Xojo – it just takes some extra work.

Here are my steps to building an iOS enterprise app:

  • Build your app in Xojo with the Build for App Store switch turned off.
  • Build the built app into a folder named “Payload”
  • Compress that folder.  Change the name from Payload.zip to “yourappname.ipa”.
  • In your favorite text editor paste the following code.  Replace App_ID_Prefix and App_ID with the valid information for your app from the Apple Developer website:

<?xml version=”1.0″ encoding=”UTF-8″?>

<!DOCTYPE plist PUBLIC “-//Apple//DTD PLIST 1.0//EN” “http://www.apple.com/DTDs/PropertyList-1.0.dtd”>

<plist version=”1.0″>

<dict>

<key>application-identifier</key>

<string>App_ID_Prefix.App_ID</string>

<key>keychain-access-groups</key>

<array>

<string>App_ID_Prefix.App_ID</string>

</array>

</dict>

</plist>

  • Save this file as Entitlements.plist
  • Go to the Apple developer website and download your enterprise developer provisioning profile.
  • Download iReSign project from https://github.com/maciekish/iReSign (see note below)
  • Run the ReSign app
  • Drag unsigned .ipa file to the top box, or use the brown button.
  • Drag your mobileprovision file you downloaded from Apple to the second box, or use the browse button.
  • Drag your Entitlements.plist file you created earlier into the 3rd box, or use the browse button.
  • Select your name from Keychain Access List.  For example it might be, “iPhone Developer:  Firstname Lastanme (XXXXXXX) from the dropdown.
  • Click ReSign! and with.  The resigned filed will be in the same folder as the original with (Resigned) in the name.
  • Voila!  Move that resigned file into the appropriate place and remove the Resigned so it’s back to the yourappname.ipa” name.
  • Now you can deploy your enterprise code signed app to any iOS device.

Each iOS device may have to trust the certificate.  Go to Settings -> General -> Device Management.

For it to work properly in MacOS Sierra (and above) I had to recompile the ReSign app in Xcode (no code changes).

It seems like a lot of steps but once you get it working it’s not hard after that. One thing we learned the hard way is that enterprise certificates expire in a year so plan renewing the certificate and getting a new version out before it expires.

Hopefully someone will find this useful.

[Update]: My iOS Build settings for Team are set to “None”

Don’t Use GoTo

At XDC 2019 my session was titled Xojo Design Mistakes (the alternate but way longer title was ‘Thankfully time travel doesn’t exist or my future self might travel back and murder my younger self for the stupid coding mistakes I’ve made’).  These are things that I’ve discovered over the years, both in my own projects and in other peoples projects that are just plain wrong or less than ideal.  This will be an on-going series since I had well over 50 slides and left about 150 out.  So when I get bored I’ll bring these topics up.

Don’t use GoTo – ever.  GoTo is a holdover from the old BASIC days where code was unstructured and you needed to manage flow-of-control.  Old BASIC programs used a ton of GoTo statements because, well, you just had to.  It was the only way to get anything done.  Xojo uses a modern BASIC syntax but it’s fully object-oriented code and still has GoTo as a reserved keyword and it still functions.

Xojo has many ways of doing flow control.  There are multiple ways of doing loops with While’s, Do-Loop’s, For-Next’s, and we control those loops with keywords such as Continue, Exit, Return.  Since we have methods and functions too we can exit those by calling Return at any point in the method and the code resumes execution at that point.  GoTo just isn’t needed any more.

And yet GoTo still exists.  I recently ran across this code in a project we’re updating for a client.

As you can see we are in a fairly typical For-Next loop iterating through a ListBox.  The first line into the loop we check if we’re closing the window and if we are we call GoTo bale which takes us to where bail: is.  Bail is at the bottom of the method and we’re doing nothing afterwards (the last two lines are Exception handling in this method and aren’t called).

This is such a poor example of Xojo coding.  We can use Exit to accomplish the same thing since Exit will immediately exit the loop and since there would be nothing after the loop it would simply leave the method entirely by simply calling Return.  There’s no penalty for using either Exit or Return.

Honestly, I have no idea why the original developer did this.  I think they came from VB6 where code like this was pretty common, but even in that language there were much better ways to do the same thing.  So I will call this lazy coding because the developer didn’t use the best way in Xojo.

Using GoTo like this is potentially risky too.  Feedback case 24710 shows that using GoTo may cause a memory leak because the compiler may skip cleanup code.  I think the above code is safe but I could see if we loaded oNote before the GoTo exiting the loop it would be dangerous.  But even still, if GoTo is outdated, not recommend, and dangerous on top of all that why use it?  I can think of at least three ways to make this code safer and better.

At the end of the day, If you’re using GoTo – don’t.  Refactor your code so it makes use of the modern Xojo calls. It’s safer and the right way to code in Xojo.  Your future self will thank you.

(245)

Xojo 2019 R1.1

A dot release for Xojo 2019 Release 1 was released today.  Xojo 2019 R1.1 has several significant bug fixes.  This release is highly recommend for all users.

Perhaps the biggest bug fix is related to ListBox.CellbackgroundPaint and Listbox.CellTextPaint events.  They no longer leak memory 64 bytes of memory each call.

In Windows URLConnection received some attention.  They sped up socket requests and decreased the CPU usage.  Authentication no longer hangs when there is request content present.  The events for URLConnection are no longer re-entrant.  This is fancy way for saying that some events, like PageReceived would get called a lot rather than just once and could cause some issues depending upon usage.

Changing the case of label now changes the text in Windows.  For example if you set the label1.text = “lower” and then tried label1.text = UpperCase(label1.text).

Also in Windows, TabPanels embedded within another TabPanel no fires the Changed event multiple times.

One new thing made it into this build.  iOS projects now add default plist entries for NSLocationWhenInUseUsageDescription, NSLocationAlwaysUsageDescription (for iOS 10) and NSLocationAlwaysAndWhenInUseUsageDescription (for iOS 11+).   These can be overwritten by user plist files.

I am glad to see this dot release version of Xojo.  I know we like to beat up on Xojo Inc for various things but I think they generally do the right thing for the community.

(282)

Listbox.CellTextPaint and Listbox.CellBackgroundPaint Memory Leaks

There are bugs and then there are bugs.  Not all are created equal and certainly not all are worthy of a dot release.  But when a serious bug comes to light you have to take it seriously.

Feedback 55596 is a perfect example of this.  If you use Listbox.CellTextPaint or Listbox.CellBackgroundPaint your app will leak memory.  Leaking memory is bad to begin with but since the Listbox calls these events frequently.  Losing 64 bytes per call adds up quickly.

I was going to do a release today for a client using 2019 R1.  This was the first release where Windows drawing was as fast as older versions of Xojo.  Prior releases of this product had to be built with 2017 R2.  So now what do I do?  I’m damned if I do a build and I’m damned if I go back to 2017 since we have to retest everything.

Xojo Inc. doesn’t seem interested in doing a dot release.  On the forum Greg was quoted as saying, “…doing a point release is not an insignificant task and takes resources away from making progress on other things, never mind the additional stress that comes with it.”  Who cares if it’s work on their part?  Seriously, if I can’t use the current public release then why am I here?  It’s bad enough I’ve been chasing Xojo versions for nearly two years with Windows drawing.

This is part of a much bigger issue that many at the Xojo Developers Conference discussed a few weeks ago.  Xojo has always been a lean organization and many times I’ve felt that it’s been quite anemic.  But an important bug and a public release to fix it shouldn’t be a major stress inducer to the developers.  To me this says there are too few developers and too much work on their plate.

For what it’s worth, the bug is marked as fixed as of May 14th.  It’s still too early to tell if we’ll get a dot release for such an important bug fix.  Maybe R2 is just around the corner but I don’t have time for a 30 to 60 day beta period.  I need this fix now.

(218)

XDC 2019: Web Framework 2.0

At XDC 2019 Greg O’Lone of Xojo showed us the current status of Web Framework 2.0.

The design goals for the web framework:

Update the server technologies.

Improve responsiveness

Modernize the framework

New and Updated Controls

Improved Browser Support

HTTP 1.1 compliant server.

Minified frameworks and Client Rendering (more done on the browser now)

jQuery – feature rich JavaScript library

Boostrap and FuelUX controls

Browsers:

Support as many of the current browsers as possible.  Current framework parses headers to determine what to support but most browsers lie.  Going to ask the browser what it supports.  The controls themselves will determine what they can do.  Things like TouchEvents and File API support might change.

Adding Browser History triggers.  Can tell the session that something happened.  For example if user was filling out form partially and hit back button.  When they come back to the site the HashTagChanged event fires can allow you to get that information back

Visual Session Controls.

Server Connection Monitor.  New dialog to show user that it’s having problems communicating.

Layout Modes:  Fixed, put a control on a layout and it just stays there.  Fluid layout lets controls flow around in the container.  Auto(layout) – not in version 1.

Big list of already supported controls.  New ones:  MessageDialog, PagePanel, Breadcrumb, Rich Text Editor.

Big functionality updates:  File Uploader (splitting engine from the interface).  Listbox has pagination, dynamic data sources, sortable columns, built-in filtering, custom column types.  Canvas has layers, events, and Drag and Drop on browser side.  Toolbar is Bootstrap (but will have icons) and it will act more like the desktop toolbar.  TextFields gets browser side text formatting and validation.  MenuItems are theme compliant, disabled items, hierarchical, separators, and headers.

Styles:  Existing editor is painful.  All projects will get the global Bootstrap theme.  Drop-in theme replacement.  Themes can be previewed in the IDE!!!  Selective control-level customization more like what we get on the desktop.  Property-level style access which means will be able to change styles via code!

Project transition is a one way operation.  Using API 2.0 but will still use the deprecated API.  Some things like ListBox.AddRow will automatically converted to new API.  CGI projects are going away and the only option will be standalone.

Xojo Cloud will be using only 64-bit standalone apps.  You’ll get Load balancing and multiple domain names.  Must be using the newer server configurations.

WebSDK 2.0:  jQuery, Bootstrap and FuelUX will be included.  Browser feature detection and we’ll be able to query to see if a browser can do something.  

TypeScript allows us to compile the Javascript that all browsers use.  Get some definition files and other things.

Greg shows us a demo of the Web Framework 2.0:

Shows a WebPage that has working TabPanel.  Layout Editor drag and drop not working quite like it will in release version.  Shows me MessageDialog.  Shows new ChartingControl.

He then shows us changing the theme.  Simple drag and drop of Cyborg theme changed everything in the project.  Very nifty.

Greg shows us pre-Alpha Feedback using Web Framework 2.0.  TextField support password managers now!   Buttons are Escape and Enter sensitive now.  Listbox has custom column types:  Picture column and URL column.  Clicked on a link (Feedback report) and then opened it.  Showed use of the back button that took us to previous action.  Then showed Dynamically Load listbox an dhow it loaded more data as he scrolled to the bottom of the list.

Very functional demo!

Q & A:

Message Dialogs have icons?  Yes, just like current desktop.

The demo showed 3 buttons.  Will it return values?  Yes, just like current desktop.

Will container control will be draggable?  Redesigning drag and drop.  So maybe?  Might not be right away.

Pushing more stuff down to the client will be have access to hardware/devices on client side?  You’d have to use Internet Explorer and the WebSDK to load and ActiveX control.

How easy to support Dark Mode in web apps?  Only supported in Safari.  Answer is maybe and change the stylesheet on the fly.

Recommend load balancer for new web framework?  No.  Used it with several load balancers and they all worked.  Changed how much data is being transferred between client and server.  Transmissions cut down by 60%.

Can users change theme at runtime?  Yes.  Maybe not in version 1.

With Xojo Cloud load balancing is there any scheduling or rules?  Control distribution is up front – no thoughts on scheduling.

With new Canvas control would you be able to create a game with it?  Their intention is to expose the canvas handle to developers.  Some restrictions.

Custom skinning on progress wheels?  Yes.  Current one is SVG and it just rotates it.

How will editing in web listbox work?  Custom column type.  Doesn’t work today but a huge want.

Listbox has a built-in Search Field.  ListBox in general has a number of things built-in.  By Default has pagination and search field.  Will eventually support multiple layout types (list, picture) but not for version 1.

Open events work by the way.

Will tags be available in more places?  We haven’t done that yet.  Unknown if it will get into version 1.

User get click happy is there a way to prevent weird stuff from happening?  Still have the Auto Disable for buttons.  There is some mechanism in place to prevent the exact same event from being sent to server.

Column sorting and pagination?  Adopted desktop behavior for column sorting.  Sorting a column will requery the database.  Always goes back to the data source.

Xojo 2019 R1

Xojo 2019 R1 was released today. This is the 2nd release in a row where there is not a dramatic number of new features but quite a few bug fixes and enhancements. Let’s dig into what’s changed in this release!

The big change in this release revolve around the URLConnection control. The HTTPStatusCode property is now available for both the Send and SendSync calls. The control now appears in the library. It now yields to other threads. Send requests are now closed before the ContentReceived and FileReceived events are fired. The string encoding for the ResponseHeaders is now consistent across platforms. It also now automatically handles compressed content-encodings in Windows and Linux (just like MacOS does). The TimeOut property now works (before it always did 30 seconds). Error messages are no longer empty in Windows. The ReceivingProgressed event now correctly reports the total bytes. The response headers are now updated property when a request is made. The SendSync no longer intermittently returns empty strings in MacOS.

The licensing has changed for Raspberry Pi. The license for Desktop and Console applications on the Pi is now free!

There are some other new items. The list is small but significant. The first is that 32-bit Windows builds can now set HiDPI and supported versions properties in the manifest file.

The TextArea control for Windows 8 (or newer), and Linux now support system spell checking. This matches the behavior on MacOS.

The Text datatype now has target appropriate EndOfLine properties. If you use Text you’ll no longer have to create your own EndOfLine constants.

The IDE added the ability to switch between Computed Properties and manual Getter/Setter methods. There is a new menu item when right-clicking on a property. In addition to the standard Convert To Computed Property there is a new menu item called Convert To Method Pair which creates two overloaded methods. For example, if you have MyProperty as Integer and select the Convert to Method it will create one MyProperty method that returns the integer value and another overloaded method that accepts an integer value with an assigns. So it looks like to consumers of this property as if nothing changed.

The constants setting has been changed from Dynamic to “Localized.” This creates a new grouping in the Code Editor called “Localized Strings”. It’s still a constant but it better reflects that it’s localized and should make it easier to visually see if a string is localized or not as there was no easy way to tell before.

There are 25 changes and 162 bug fixes for Xojo 2019 R1. Here are what I feel are the significant items:

The ODBC Database plugin now works better with 64-bit builds. Date fields in MacOS now work properly. In 64-bit Windows updating a binary/image column no longer fails with an invalid precision error.

The MySQLCommunityServer plugin no longer crashes when has certain field types and originated from a PreparedStatement.

The SQLiteDatabase no longer crashes when out of memory situations arise – an error is now generated.

Calling an OpenDialog from within a thread now properly raises a ThreadAccessingUI exception. I’m actually surprised that this wasn’t flag a long time ago.

StringShape rotation is no longer incorrectly offset. The original Feedback report was for Linux but it appears this affected other targets too.

The Window/Canvas Backdrop picture now draws correctly in HiDPI. This doesn’t affect me directly but this is the first time in several years where Canvas drawing in Windows seems really solid. I’m in testing right now with a client app that had been held back in 2017 R2.1 because of Windows drawing performance.

GroupBox caption in Windows now properly draws the size, bold, italic, and underlines styles instead of ignoring them.

A bunch of work was done in the Code, Constant, Layout, and FileTypes editors. The Inspector and Library received a little love too.

You can read the release notes at http://docs.xojo.com/Resources:2019r1_Release_Notes to get the entire list and see if anything affects you.

Conclusions

So far I’ve found this release to be solid and the major updates to URLConnection now appear to make it worthy of investigation. I’ve not used it enough, yet, to recommend it but I think most of the major bugs are worked out. The number of bug fixes and enhancements makes R1 a worthwhile upgrade.

I think this version is worthy of your time and effort to try out. As always, you should really test Xojo out on your projects, in all targets, to make sure it works as expected. Some of the bug fixes in this release might mean you have to get rid of some workarounds you’ve come up with (thinking of the StringShape rotation fix here).

You can download the new version at https://www.xojo.com/download/

Let’s hope that the major new features (like API 2.0, Web 2.0, and Android) can be staggered so there there isn’t a flood of new things in a single release. Too many new things makes it hard on beta testers.

Have you found any showstoppers? What are you most happy about in this release?

Until next time, Happy coding!

Evaluating Prospective Xojo Clients

A couple of weeks ago I did a blog post about evaluating Xojo consultants.  I think if you’re hiring a Xojo developer the consultant should clearly be an expert in Xojo and should be able to publicly show why they deserve your hard earned money.  But, there are two sides to the equation and I didn’t talk about evaluating the prospective client.  Here are some of the things that are red flags to us and maybe why we should steer clear of them.

Does the prospective client have a clear idea of what they want?  We’ve had clients that had a mere paragraph of content but could clearly articulate what they wanted.  Other clients have written an 80 page document full of meaningless gibberish that required a three hour face-to-face meeting to understand it.  

This is hard to evaluate but I’ve learned that if I can’t understand what the client wants and needs within a reasonable amount of time we’re not a good fit.  Either they can’t articulate what they want or it means that we’re just having communications issues.  It’s also possible they don’t know what they want and they want us to figure it out for them (which is a completely different project).

Has the prospective client worked with other Xojo developers before and been unhappy with the work?  Don’t get me wrong, we’ve picked up a lot of happy long-term clients and projects this way.  The client worked with another Xojo developer that couldn’t finish the project for a variety of reasons (like going back to a corporate job, or they bid too low and couldn’t live on the resulting income).

This is hard to evaluate too and you have to take it on a case by case basis.  Listen for the reasons why they were unhappy with the consultant.  Do their reasons seem petty or legitimate?  Do they accept at least some of the responsibility or do they put it all on the consultant?  Reasonable clients will accept partial responsibility.  The unreasonable clients, and the ones to stay away from, blame everything on the consultant.

The prospective client thinks they can do some of the work.  They have experience in <x> language and want to implement some of the work in Xojo on their own.  Or they feel their proof of concept project written in <x> language should give you a huge leg up on the overall project.

As with the previous points this is hard to evaluate.  Xojo is an easy to learn language but it’s been my experience that making Xojo work like <x> language is a recipe for disaster.  Xojo is Xojo and not like java or FileMaker or anything other language or environment.  Maybe their work helps but mostly it probably won’t.  It’s just easier to assume it’s going to be a complete rewrite.

The flip side to this is there are some clients that really are competent developers – just not in Xojo.  We’ve done a number of projects where we start the project for them.  We complete the basic infrastructure and give them some example List and Edit forms whatever else they want help with and then turn it over to them to complete the rest of the project.  They usually come back with some questions but for the most part they finish it themselves.  I consider this as part consulting and part training and we put more comments into code so they can understand the code better (since they’re learning).

The prospective client is always fighting with you about money.  We’ve had clients that want estimates on features so they can get their project done as cheap as possible.  I don’t begrudge any client that wants estimates on features to save money, but there are those clients that always complain about every penny and fight you on estimates and change orders and demand proof for every little thing.  They also tend to hold you to the dollar on any estimate you give them.

We had one prospective client that came with a project written by another developer.  It was referred to us by a Xojo consultant leaving the industry and couldn’t help them.  The project had a silly design where the SQL query was a staggering 200 pages when copied into a text editor.  It literally took minutes just to create the query and many minutes for the database to return results.  The only way to really clean it up and make it work properly was to break it up into smaller queries.  It would have given them more flexibility and it would actually speed up their entire process rather than locking the app up for minutes at a time.

Regardless, we came up with the estimate to fix it.  They said it was too much money and we parted ways.  They came back again in six months when the Xojo developer they found to ‘fix’ the query couldn’t do it (because it really needed to be broken up into smaller queries) and we gave them the same estimate.  It was still too high for them.  Six months later they came back yet again and asked if the price was the same.  It was not because we had raised our base rates.  We’ve never heard back from them and I wonder if they’re still in business.

Many clients are a delight to work with.  Not all of them will be long term clients but some will.  If you don’t get a warm fuzzy feeling after communicating with the client a few times you should really figure out why.  You’re going to know their project better than they do so you’d better figure it out before starting a big project.

Ironically some of our longest term clients were hard to work with at first.  See, they had bad experiences with other developers and were wary of being burned again.  Keep that in mind too. They’re being hard on you because they weren’t with their last developer.

These are just a few of the red flags that should concern you when talking with prospective clients.  What red flags do you look for?

ARGen 3.0.3

BKeeney Software Inc. is proud to announce an update to ARGen, our ActiveRecord Generator utility for Xojo developers. This minor update includes dark mode support, speed improvements, and important updates for generated projects. Updating to 3.0.3 is recommended for all ARGen users.

ARGen is available for macOS and Windows. It can be used for free in limited mode, and is priced at $99.95 to unlock all features. Existing version 2.x users will automatically be provided an upgrade opportunity when launching version 3.

3.0.3 Release Notes:

Changes:

  • Added Dark Mode support
  • Simplified manual relationship management
  • Selecting a different SQLite database now clears the password field
  • kMaxReturn is now a protected constant for cleaner code
  • DBUpdates module code is now cleaner
  • Improved instructions in some locations
  • Base project templates optimized
  • Preferences module no longer writes to SpecialFolder.Preferences
  • iOS Create Data Sources defaults to true
  • Updated links to Xojo documentation
  • Generated localization module constants are now protected

Fixes:

  • DBUpdates.SetDBVersion no longer uses a BKS extension synonym for str()
  • Fixed return statement for iOS apps using 2018r2
  • Projects with empty name now have default save name
  • BKS Created/Modified overrides no longer generate properties that fail to Register
  • Corrected minor UI bug on Windows
  • Project listing loads faster
  • Speed improvements throughout the software
  • Projects created but never saved are no longer retained when closed
  • Checking for updates at launch now works
  • Preferences window will show the last update check time

Pricing, examples, and more details can be found at the project homepage at https://bkeeney.com/argen/