XDC 2019 Is Almost Here!

The Xojo Developers Conference (XDC) is just around the corner.  In less than two weeks Xojo developers from around the world will gather in Miami to talk Xojo for three full days.  The speakers have sent in their slides and gotten feedback from Xojo and flight and hotel reservations made.

This is my favorite part of the year!  Really.  BKeeney Software has been around for nearly 18 years and in that time I’ve gone to many Xojo Developers Conferences including those sponsored by Xojo, sponsored by Monkeybread Software, and even held a few I helped host with the defunct Xojo developers user group.  

Many of the developers that attend are my friends.  Many more are colleagues, and competitors.  Some are current and old clients.  Some of those clients I met at XDC looking for developers for their project since there will be no greater concentration of Xojo developers on the planet!

You’d think that with as many developers conferences under my belt there would be nothing new to learn.  I disagree since Xojo is always morphing into the next phase of its existence.  When I started, 68k Mac apps were transitioning to PowerPC.  They added Windows and Linux targets.  They added Cocoa for MacOS, 64-bit builds for Mac, Windows, and Linux, the ability to create web applications, Raspberry Pi apps, and mobile applications for iOS.  

I expect this year we’ll learn a lot more about Xojo for Android which will be a significant new target and make iOS that much more relevant with Xojo.  We’ll learn about InterOps that aims to make adding libraries much easier for iOS, MacOS, and Android.  And I’m sure we’ll see a lot about Web 2.0 that will make Xojo web applications more powerful and more robust.

At the end of the week, it’s always sad to go home.  The bonds you make while sitting across the table from someone at a meal, or over drinks at the end of the day, is something that you can’t get in the forums, email, or via videos from the conference.  Don’t get me wrong, the Xojo forum is one of the friendliest developers places I’ve ever experienced, but there is something truly powerful about chatting with people and being able to read their body language and talk about their developer experiences that far outweighs the convenience of the electronic venues.

If you have the means I highly recommend making it to XDC.  It’s well worth it.  You’ll get to meet some awesome people, learn a bunch of new things, probably see some alpha or beta of new features, and overall have a good time with your extended Xojo family.

If you’re going and we haven’t formally met, please feel free to stop me and introduce yourself.  Remind me how you came to find me and what products, if any, you use.  Tell me what features you like, or don’t like.  Just say hi and then go talk to the many other Xojo developers there – you might just find friends for life.

Of course I’ll blog about the keynote and the cool new things that I see at the conference.  See you in Miami!

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/ 

Evaluating A Xojo Consultant

We had an interesting conversation with a prospective client last week.  Well, I should back up and say this isn’t the first time we talked to them as we were a finalist for a project of theirs two years ago.  Turns out their Xojo consultant is having a hard time completing the work and not giving them deliverables in a timely manner.  This is for a project we estimated at less than six months worth of work.

The client is looking for someone that could come in and complete the project for them.  They were hoping that a large majority of the work could be reused.  My response was that this was unlikely for several reasons.  The first being that they used their own kit which means a set of classes, subclasses, and libraries that we are unfamiliar with and for me to use them without serious investigation (i.e. time and money) would be less than ideal.  Plus, if I’m the developer for the project I’m now responsible for it working and I’m taking a gamble on code that I don’t know and haven’t vetted.  

My second thought was wondering if their overall design had been the cause for some of the delay.  Perhaps they coded themselves into a corner.  It’s an awkward conversation to have with a client – especially after they’ve spent a boatload of money.

Regardless, I’m sure our conversation was not what the client was looking for.  They wanted a project savior because their consultants had deceived them in their capabilities and in their ability to deliver.  

We politely asked who their consultant was and they told us.  A brief internet search pulled up the company website and their *one* Xojo related post.  Everything else on their website is hardware and .NET related.  If I was evaluating a Xojo consultant that would give me some pause for concern.  You really want a consultant that does a lot of Xojo projects.  Xojo is not like .NET or Java or any other language.  It has its own set of strengths and weaknesses (just like every other language) and I’ve seen it all too often where a developer tries to make Xojo do what <insert language here> does.  It’s almost always a disaster.

We’ve been using Xojo for over 16 years.  If I’m not friends with most of the Xojo consultants out there I at least know of them and their reputation.  I have lost bids to my competitors and if the prospective client will tell us who they chose I can at least give a thumbs up to those that I know and trust since I know the client will be in good hands.  For those that I don’t know I don’t give any opinion.  But it’s also been my experience that those consultants that stick around are good and are active in the community.

If you’re hiring a Xojo consultant you should always ask for references.  If you’re going to spend tens of thousands of dollars (or more) with them you should do a little homework.  Don’t buy their assurances.  If they are really reliable then they will find references for you to check out.  This will let you know if they do good work, are on time, and on budget.  Are they reliable?  Are they hard to work with?

If you’re new to Xojo consulting that’s okay too – we were all new once.  Be honest with the client and do your best to prove to them that you’re up to the challenge.  

The Xojo community is very accepting and the forum is filled with developers that have provided answers to newbies, provided source code examples, and even established public repositories to share their code.  Have they spoke at any Xojo developers conferences?  Written for Xojo Developer magazine?  This public work can, and should be, part of the reference list.  This shows the prospective client that you really know and work with Xojo.

Hiring a Xojo consultant isn’t that difficult.  There are a number of qualified consultants that will create a great project for you.  The first step is to fill out the form at Find a Developer page on the Xojo website at https://www.xojo.com/resources/consultants.php.  This will get your project in front of everyone looking for work.  Then it’s up to you.

Ask about their Xojo work they’ve done in the public.  Ask for their references.  Heck, ask them what they love and hate about Xojo (that might be a long conversation).  If you don’t do your homework you might be wasting an opportunity in not getting your project to market, or waste tends of thousands of dollars for work that doesn’t get delivered.

XDC Video Sale

The Xojo Developer Conference (XDC) is a fantastic event.  I highly recommend going to one.  The 2019 XDC event this year is May 1st through the 3rd in Miami, Florida.  I look forward to XDC as you will not find a greater density of Xojo developers on the planet!  Everyone there is all-in on Xojo and you can easily talk Xojo non-stop for three full days (or longer).  More details on XDC at https://www.xojo.com/xdc/

At XDC 2015 they started recording the sessions and attendees get these recordings as part of their conference admission.  This was a great addition because it made choosing between sessions a lot easier because you know you could watch it later.  Plus you could rewatch sessions whenever you wanted.

The XDC videos are also for sale after the conference.  They were not inexpensive but certainly cheaper than going to the event.  Xojo recently announced that the XDC videos from 2018 are now available for $99.  The 2016 videos are available for $75.  These are great prices for 64 videos that cover everything from the Keynote by Geoff Perlman, to database topics, to Windows and Linux and iOS and everything in between.  I haven’t totaled up the exact hours but if my rough calculations are correct the two years of videos adds up to over 1900 minutes of video.  I guarantee there’s a topic you’re interested in that is in this list.

I’m so looking forward to XDC 2019.  Not only to escape a fairly brutal winter in the midwest but to reconnect with my friends and talk Xojo non-stop for days on end.  But also to go to sessions that haven’t been done before.  Many of the speakers had done their favorite topics several times and chose different topics (I did this intentionally to get outside my box).  You can find the season list at https://www.xojo.com/xdc/sessions/

As I usually do I’ll do blog posts on the more interesting topics.  I expect to hear more about Web 2.0, Interops, Android, Xojo Plugins and much more.

Hope to you see you at XDC.  If we’ve never met please stop me and introduce yourself and tell me how you ‘know’ me.  Some read the blog and some have bought our Xojo developer products.  I love to hear about your experiences and how I can serve you better.

Updating Records with Transactions

In my last blog post I talked about inserting records into a SQLite database and found that using transactions makes them incredibly fast.  Does the same hold true for updating an existing record?  We’ll find out.

In this set of tests I inserted 100,000 records and then randomly selected 10,000 records to update with our same random name, age, and date values.  In theory this means I have records distributed all over the range of the database.

In the first test we use a simple RecordSet which means we have to query for it first.  Then call its Edit method, change the values and call update.  It’s a two step process.

For i As Integer = 0 To ari.Ubound
   Dim rs As recordset
   rs = db.SQLSelect("Select * from t_table where table_id = " + Str(ari(i)))
   If db.error Then
      If db.Error Then
         MsgBox "DB Error: " + db.ErrorMessage
         Return
      End
   End
   rs.edit
   rs.Field("Name").stringvalue = GetName
   rs.Field("Age").integervalue = GetAge
   rs.Field("TheDate").DateValue = New date
   rs.Update
   If db.Error Then
      MsgBox "DB Error: " + db.ErrorMessage
      Return
   End
Next

Unsurprisingly, this method took about 49 seconds for 10,000 records.

In test two I switched to using a PreparedStatement to update the record.

Dim sql As String = "Update t_table Set Name = ?, Age=?, TheDate =? WHERE table_id = ?"
Dim ps As SQLitePreparedStatement = db.Prepare(sql)
ps.BindType(0, SQLitePreparedStatement.SQLITE_TEXT)
ps.BindType(1, SQLitePreparedStatement.SQLITE_INTEGER)
ps.BindType(2, SQLitePreparedStatement.SQLITE_TEXT)
ps.BindType(3, SQLitePreparedStatement.SQLITE_INT64)
For i As Integer = 0 To ari.Ubound
   ps.Bind(0, GetName)
   ps.bind(1, GetAge)
   ps.Bind(2, New Date)
   ps.bind(3, ari(i) )
   ps.SQLExecute
   If db.Error Then
      MsgBox "DB Error: " + db.ErrorMessage
      Return
   End
Next

When run for 10,000 records this takes about 47 seconds so there is a little bit of time savings by not querying the database for the data to begin with.  It’s also possible that the PreparedStatements aren’t nearly as efficient as one would hope.

I then repeated the same tests within a Transaction.  In both cases updating records effectively took no time at all!  If I increase the number of Updates to 10,000 both the RecordSet update and the PreparedStatement takes about 8 seconds.  

I’m surprised at these results because you would think that doing the query required for the RecordSet would take more time but it’s no different than using the PreparedStatement SQL Update.  Why is that?  I have a couple of theories.  First, the table isn’t very complex with only 4 columns and I’m only ever querying and updating based on the primary key.  I’m sure a more complex query would slow things down.  We also have no indexes on any the columns which can cause the database to do more work behind the scenes.

Regardless, we learned a few things today.  First, database transactions are critical to large scale database manipulation in a timely manner.  Second, it doesn’t matter if you use RecordSet Edit/Update or if you use PreparedStatements as either one is fast enough.

What sorts of questions do you have about databases that I can test for you?

Database Transactions in Xojo

Every now and then someone on the Xojo forum wonders why inserting data into an SQLite database is so slow.  Databases are designed to hold billions of records and do it fast, right?  So why is their application so slow?  The answer is they are relying upon the built-in transaction in Xojo.

By default SQLite databases do an automatic transaction for you.  This means that as soon as you attempt to insert, update, or delete data the work to write that change to disk happens as soon as possible.

For example, let’s take the following bit of code to insert data into a table:

For i As Integer = 1 To kMax
   Dim dbr As New DatabaseRecord
   dbr.Column("Name") = GetName
   dbr.IntegerColumn("Age") = GetAge
   dbr.DateColumn("TheDate") = New date
   db.InsertRecord "t_table", dbr
   If db.Error Then
      MsgBox "DB Error: " + db.ErrorMessage
      Return
   End
Next

GetName gets a random name from an array that has 26 names in it and adds a random integer between 1000 and 10000.  GetAge returns a random integer between 1 and 74. 

This is pretty simple insert and if you run this 10,000 times it takes roughly 49 seconds saving to a desktop SQLite file on my 5k iMac.  And in so doing the application is locked up for that entire time because I’m in the tight loop.  This is simply unacceptable.

I’m sure someone is screaming why are you using the DatabaseRecord!  It’s slow!  It’s inefficient!  You should be using PreparedStatement’s!  Okay, so using pretty much the same logic:

Dim sql As String = "Insert into t_table (Name, Age, TheDate) Values(?, ?, ?);"
Dim ps As SQLitePreparedStatement = db.Prepare(sql)
ps.BindType(0, SQLitePreparedStatement.SQLITE_TEXT)
ps.BindType(1, SQLitePreparedStatement.SQLITE_INTEGER)
ps.BindType(2, SQLitePreparedStatement.SQLITE_TEXT)
For i As Integer = 1 To kMax
   ps.Bind(0, GetName)
   ps.bind(1, GetAge)
   ps.Bind(2, New Date)
   ps.SQLExecute
   If db.Error Then
      MsgBox "DB Error: " + db.ErrorMessage
      Return
   End
Next

This takes about 48 seconds.  No big time savings there.  Obviously that’s not the improvement we need.

What we need to do is put these inserts in a database transaction using the following bit of code before the loop starts:

db.SQLExecute("BEGIN TRANSACTION")
If db.Error Then
   MsgBox "DB Error: " + db.ErrorMessage
   Return
End

And then at the end use:

db.Commit

Using the DatabaseRecord method takes a whopping 1 second with 10,000 records.  Using the prepared statement is so fast that my measured elapsed time in seconds is effectively 0.  

If I up the number of records inserted to 1,000,000 I get an interesting result.  The DatabaseRecord method takes 27 seconds where the PreparedStatement method takes 47 seconds.  And if I declare the PreparedStatement inside the loop it now takes 55 seconds.

What have we learned in this blog post?  First, using a database transaction is considerably faster than using the default transaction behavior.  Second, using DatabaseRecord is pretty fast and depending upon the number of record inserted it might be considerably faster.  Honestly, I didn’t expect this.  

In the next blog post I’ll look at Record updates and what are the best methods.

Formatted Text 3.2

Lenexa, KS (February 12th 2019) — BKeeney Software Inc. releases a major update to Formatted Text Control. Developers can now implement tab leaders, change character spacing, implement text drop shadows, and use standard keyboard handling in their applications that require a robust word processing control. This version contains dozens of new, changed, and updated items.

Formatted Text Control (FTC) is a set of classes that offer developers word processing capabilities for their Mac and Windows desktop applications. FTC has several viewing modes that gives users a choice of Page View, Edit View, or Single Line view. FTC supports inline graphics, hyperlinks, and text formatting that the built-in Xojo TextArea control just can’t do. Users can import and save text, RTF, and XML format documents.

FTC version 3.2.0 is a free update to all 3.x users and is recommended. Existing users should be notified via FileShare but can contact BKeeney Software at support@bkeeney.com if they have any questions.

FTC is sold as unencrypted source code and costs $150 USD. More information and demo projects are available at https://www.bkeeney.com/formatted-text-control/ .

Complete change list:
New Items:

  • Contains code from the ImagePlay Effects Library – http://imageplay.sourceforge.net 
  • Tab Leaders implemented
  • Issue #3832: Implement Control + Up/Down Arrow Key Handling
  • Issue #3833: Implement paragraph moving via keyboard handling
  • Issue #3700: Drop Shadow available on Windows and Linux
  • Issue #3795: The FTDocument properties characterStyles and paragraphStyles need to be accessible to subclasses.

Added CharacterStyles and ParagraphStyles getter/setters so developers can create their own style editor.
* Character Spacing implemented (requires Xojo >= 2015.4)

Bug Fixes:

  • Issue #3650: CustomObjects Demo: Added FTFile.Clone method so it works with FTIterator propertly.
  • Issue #3653: macOS: “getDoubleClickTime” – Cocoa replacement for old CarbonLib call
  • Issue #3699: Add Win64 Declares
  • Issue #3654: Hi-DPI Mode: FTPicture – Handles drawn incorrect and matches wrong.
  • Issue #3702: DragRect is half height in HiDPI
  • Fixed an issue with FTParagraph clones that have a different ID after going through the FTIterator
  • Issue #2007/3605: Candidate Window Shows up in Wrong Location
  • Issue #3646: FTParagraph.getXML saves wrong TabStop Properties
  • Issue #3709: FTPicture ignores Nudge property
  • Issue #3748: FTDocument.selectionBold,Italic, shadow, strikethrough, subscript, superscript, underline now works properly
  • Issue #3752: FTRBScript: Fix for printing line numbers
  • Issue #3763: RTFReader/FtcRtfReader ignored the left/right margin and first indent of paragraphs.
  • Issue #3764: RTFReader ignored “\sb” SpaceBefore of paragraphs.
  • Win64 Issue: Modified FTCUndoPaste.constructor and FTCUndoManager.savePaste to allow pasting (Xojo Compiler Issue. Feedback 53967)
  • Issue #3750: Suggestion & comparison of the Office applications for the display optimization of the paragraph background color
  • Issue #3775: Implement Corner Color Property in Formatted Text (Switch between Light/DarkMode – Xojo Version >= 2018.3)
  • Issue #3777: Implement Page Shadow Property in Formatted Text (Switch between Light/DarkMode – Xojo Version >= 2018.3)
  • Issue #3755: Printing has the side-effect of scrolling the editing window to the top
  • Issue #3794: FTDocument.getSelectedParagraphs returns first paragraph of multi-paragraph doc regardless of insertion point
  • Issue #3796: FTStyleRun.copyStyleData does not copy background color
  • Issue #3820: RTFWriter missed “\par” after the last Paragraph
  • Issue #3774: FormattedText — changeParagraphMargins method name changeParagraphMarigns
  • Issue #3762: FTDocument.selectionFontColor returns sameColor false when it should be true
  • Issue #3842: FTStyleRun.updateWith Style sets textColor black when undefined
  • Issue #3806: FTDocument.addParagraphStyle and addCharacterStyle bypassed by insertXML and cannot be overridden in subclass
  • Issue #3818: Print RB Code Editor: Unwanted positive y-offset of the content compared to its line number
  • Issue #3637: FTCParagraphStyle.backgroundColor won’t set correctly
  • Issue #3910: RTF-Reader ignores local value for first line indent in paragraphs
  • Issue #3914: First Paragraph on Page with Background Color ignores Before Space
  • Issue #3917: Paragraphs Background Color ignores Hanging Indent

Changes:

  • Renamed FormattedText.xDisplayPosition to FormattedText.hScrollValue to better reflect what it is.
  • Renamed FormattedText.lastXDisplayPosition to FormattedText.lastHScrollValue
  • Renamed FormattedText.yDisplayPosition to FormattedText.vScrollValue to better reflect what it is.
  • Renamed FormattedText.lastYDisplayPosition to FormattedText.lastVScrollValue
  • Renamed FormattedText.GetResolution to FormattedText.GetMonitorPixelsPerInch to better reflect what it does.
  • Renamed FTDocument.SetResolution to FTDocument.setMonitorPixelsPerInch
  • Renamed FTDocument.GetResolution to FTDocument.getMonitorPixelsPerInch
  • Renamed FTDocument.Resolution to FTDocument.MonitorPixelsPerInch
  • FormattedText.DISPLAY_ALIGN_CENTER/LEFT/RIGHT replaced with Display_Alignment enum
  • FormattedText.MODE_PAGE/NORMAL/EDIT/Single replaced with Display_Mode enum
  • FTLine.FIRST_LINE/MIDDLE/LAST/BOTH replaced with Line_Type enum
  • FTPicture.Handle constants converted to FTPicture.Handle_Type enum
  • FTParagraph.Alignment constants converted to FTParagraph.Alignment_Type enum
  • Removed Alignment constants from RTFConstants module
  • Changed how hyperlinks are drawn in FTObject.drawHyperLink
  • Changed how the gradient shadow is drawn in FTPage.drawPageViewMode
  • Changed how strikethroughs are drawn in FTObject.drawStrikethrough
  • Changed how underline is drawing in FTObject.drawUnderline
  • Can now read/write shadow properties from/to RTF Documents
  • Added AcceptFileDrop to test window for testing custom objects. Added FTFile into project.
  • Changed how Styles are saved and read in XML format.
  • Issue #3802/1456: Command + (Shift Key) + Arrow Keys doesn’t move insertion point correctly
  • Changed RB Script classes to Xojo Script.
  • Now have TabLeaders (WORK IN PROGRESS)
  • Embedded FTC demo now does text formatting with keyboard shortcuts.
  • Removed unused FTDocument.DocOffset method.
  • Fixed TargetCocoa and TargetWin32 constants with more appropriate ones for 2018 R4.
  • Removed duplicated code line in RTFReader.SetupKnownCommands
  • Updated ParagraphWindow to easy format First Line and Hanging Indents

PARTIAL IMPLEMENATION:
* Issue #3753: PageBreaks won’t load from RTF

BKS Tab Control – Drag Rearrange Tabs!

Lenexa, KS (February 8th 2019) — BKS Tab Control update can now drag rearrange

BKeeney Software releases a minor update for BKS Tab Control enabling users to drag and drop to rearrange tabs. Developers can enable or disable this feature using a switch in the Xojo IDE. A new event, TabOrderChanged, is raised when the user performs a drag-rearrange.

The BKS Tab Control is a set of classes that offer developers a classic “tabs control” for Xojo Desktop applications. The Tab Control can attach to any RectControl or Window, and will maintain a relationship to this parent control if and when it changes size. Tabs can be displayed in one of four directions (North, South, East, West) and individually offer options like a close button, an icon, a background color, and can be disabled.

Other features:
  • Optional CloseBox can be positioned on the left of right
  • If the CloseBox is selected a CancelClose event is fired
  • Optional Icon can be positioned on the left or right
  • Each tab can be independently styled (colors, fonts, text decorations)
  • Each tab can be disabled
  • Tabs that overflow may be accessed with an overflow popup menu
  • Works in HiDPI, non-HiDPI, and dark modes

BKS Tab Control has been tested in macOS, Windows, and several varieties of Linux with Xojo 2018 R4 and back to Xojo 2017 R1. The control may work unchanged in older versions of Xojo.

BKS Tab Control is sold as unencrypted source code and costs $75 USD. Existing customers can download the update with the original link on their sales receipt. More information and a demo project are available at: https://www.bkeeney.com/allproducts/bks-tab-control/