Login to participate
Register   Lost ID/password?

Louis Kessler's Behold Blog

Getting Behold Running in Delphi XE8 - Mon, 6 Jul 2015

Last post, I updated my development tool and installed new versions of my three 3rd party applications. Now it was time to get Behold working again in the new Delphi XE8 environment.

Theoretically, if all updates made to an environment are backwards compatible, then old code would just run unchanged in the new environment. But they seldom are. Work needs to be done to convert.

To get started, I included the 3rd party packages without my customizations to see if what was left would still run. Then I compiled, and knowing that there was little likelihood of it working, I got:

2 Errors, 5 Warnings, 1 Hint

One error was an incompatible type between Integer and TRVTag. This was a change I remember reading that RichView had made a few years ago to use strings instead of integers for their tags. The second was the error aborting the compile because it couldn’t compile the unit. For now, I just changed the declarations to eliminate the error and proceed.

image  image

That doesn’t sound so bad for a first attempt, to have only 1 error. But I know how these compilers work. You fix one error and the compiler can then look at more code. Sure enough, after I fixed it, I now had:

16 Errors, 5 Warnings, 2 Hints

EurekaLog was now the culprit. The errors indicated major changes to that package, and indeed when I checked out their site, I found that Version 7 was almost completely rewritten.


I wasn’t trying to get EurekaLog to do much. It was passing information from unexpected errors to a special form I had set up for that purpose. I looked to see what changed, and it wasn’t simple. I always give myself a couple of hours to see if I can figure out any problem. I go through their documentation and try various things. If stumped I might check StackOverflow and maybe ask a question there about how to do it. But I could not make any headway on this, so I went to the next step and submitted a support ticket on the EurekaLog site with my problem and requested a method to fix it. I got a response quickly, within a couple of hours (on a Saturday!) and that answer led me to some good examples, but they weren’t quite enough to help me. So I added to my ticket and while waiting went back to fix the rest of what wasn’t working.

I commented out the offending EurekaLog statements and that allowed Behold to compile and run. It was nice to see Behold running from XE8. It ran fine, looked fine (except for a minor problem with the toolbar icons), and did not have any obvious problems.

There were still lots of warnings and hints to fix. These included fixing declarations, replacing a deprecated symbol or routine with another, and new messages about possibly uninitialized variables that the XE8 compiler was picking up that 2009 didn’t.

I worked my way through the most important compiler warnings and hints. In doing so, I must have recompiled the program 200 times over 2 days, finding and fixing things that worked under the old environment but not in the new one. I finally managed to get through them, leaving only a few hints about variables that are only valid on some operating systems.

With everything finally working with 32-bit processing, it was time to try 64-bit.

On my first 64-bit compile, I was quite surprised that there were new errors. The 64-bit compiler must have different checks in it. For example, one warning that came up was for code that I’ve had in place for as long as I can remember. It had never given me a message before. It was:

N := MaxN;    { Execute the loop at least once }
while N = MaxN do begin
   N := …;

The warning message on the first assignment statement was that the value assigned to N was not being used. 32-bit compilation never gave me this. 64-bit must optimize differently. So to eliminate the warning, I changed this to:

   N := …;
until N <> MaxN;

There were a bunch of little fixes like this I could make. But then I was getting errors again. The 64-bit compilation wanted me to address the RichView change of their tags from integer to string values. I was going to try to use a setting in RichView that allowed using the old style, but then I found the 64-bit compiler was not accessing those settings. I posted a query on the RichView forum. While waiting for a reply, I found that using the old style was not recommended, so I decided to go through the work and change it. It took me a few hours to update what was needed here. Once I did, Behold was able to compile and run in 64-bit.

The last thing to do was to add my customizations back into the RichView and ElPack routines. I had customized a 3 RichView units and 4 ElPack units to enhance them to provide some functionality I needed for Behold and to fix some bugs in them. There were changes to 7 different units. They represent dozens (maybe even hundreds) of hours of work I spent many years ago to isolate problems or limitations in these packages and figure out how to get them to work the way I needed.

I had delineated all my changes clearly with comments in my customized units, so they were easy to find. One of my typical changes looked like this:

{ LK - Jul 15, 2012 : Start of code to allow invisible text }
  rvInvisible = 21; {= rvInvisible in _links.pas}
{ LK - Jul 15, 2012 : End of code to allow invisible text }

Now the question was, how much did these units change in 7 years? Fortunately, these were mostly low-level units with core functionality. The new version of these units did not change much from the old version, and I was able to simply slot my customized code back in, occasionally with minor modifications. I had the RichView units working in just 15 minutes.

But then it took me 2 hours to get the 64-bit version compiling. Some sort of strange dependency in the use of one unit by another was only revealing itself one unit at a time. And this was just in the 64-bit compile, not the 32-bit compile. It was very strange. I never did figure out what this was, but I thankfully reached the end of the loop after going through only 60 of the 200 units.

I stumbled a bit while updating the ElPack units with my custom code. In the ElIni unit, which handles reading and writing the Behold Organize file, the ElPack unit did not read ASCII files properly. I had the customized code to do this correctly. But it did not seem to be working. I installed, tested and removed that code 3 or 4 times. Behold was not reading any of the information from the customized Behold file at all. Then then it hit me. My code wasn’t what was wrong. The customized Behold file I was trying to read was empty. There just wasn’t anything to read. I kicked myself about this oversight. Only cost me 2 hours.

So that was it. Behold is now all updated and is now pretty well working under my new Delphi XE8 environment. I’m still waiting for the EurekaLog support message and I’ll get back to that later.

At this point, I couldn’t help myself. I just had to do run some comparisons of Delphi 2009 performance versus Delphi XE, and then of 32-bit performance versus 64-bit performance. The results were interesting:

Compared to the current Behold Version 1.1 release (which was compiled with Delphi 2009), the new 32-bit compilation under XE8 is about 30% faster and uses about the same memory.

Then I found that the 64-bit compilation is about 12% faster than Version 1.1, but is about 18% slower than 32-bit speed. And 64-bit uses almost 50% more memory.

This surprised me. My computer has a Windows 64-bit operating system. I would have thought 64-bit processing should have run faster than 32-bit processing on my machine, but I guess the manipulation of all that extra memory the 64-bit program takes also adds a time penalty.

Once I convert Behold’s in-memory data structures to a true disk-based database, that will eliminate much of its memory use. Then time will be more dependent on 32-bit versus 64-bit database access. Once that’s done, I’ll recheck these results and won’t be surprised if 64-bit happens to emerge as the winner.image

Updating My Development Tool - Fri, 3 Jul 2015

I’ve been working with Delphi as my development tool for Behold since about 1996. I’m fortunate that the language has continued to be maintained and upgraded during that time, even though it changed ownership several times.

The version of Delphi that I have been using to develop Behold for the past 7 years has been Delphi 2009, which I upgraded to from Delphi 4 in October 2008. That was a necessary upgrade because that added Unicode capabilities which is an essential for any genealogy program.

Now that I’ll be adding editing, I must again upgrade my development tool. In March, I purchased Delphi XE7 with a free upgrade to Delphi XE8 which came out in April. Yes, that’s a full 8 versions (about one per year) after Delphi 2009. They started using the XE moniker to represent the 2010’s.


The number one essential that XE8 provides that 2009 didn’t is a new database management environment called FireDAC with interfaces to the SQLite database, which I’ll be using for Behold’s file format. I selected SQLite because its a multi-platform, speedy, single file database with a small footprint that’s embeddable within the program. This also happens to be the same database system that RootsMagic uses.

A second thing XE2 and after provides that 2009 doesn’t is 64-bit support. So finally, I’ll be able to create a 64-bit version of Behold which should provide advantages on 64-bit machines. Once I get to this, I will be interested to compare the performance, memory use and file size limits of 32-bit versus 64-bit processing, although in reality.

The installation of Delphi XE8 was pretty straightforward and seemed to take about an hour. It upgrades to a new directory, so I am able to keep my 2009 Development active in case I have to go back to check for differences between what 2009 and XE8 does. 

I need to upgrade all my 3rd party packages to new versions that will work with XE8.  I want to get my new XE8 environment working, while also keeping my 2009 environment working at least for a while. That way, if something is not working the same as it used to, I could test it in 2009 and determine if it was because of the upgrade, or if there was some other reason. Once I’m satisfied that Behold is working reliably in the XE8 environment, then I will be able to dump the 2009 environment.

I don’t update my development tool very often. The steps are often problematic. This is what happened updating my 3rd party packages this time around:

  1. TRichView, which I use for the Everything Report, is now up to Version 15.7.1. I had previously been using version 10.1.4 from 2008. I downloaded the new version, which I get free upgrades for. I love the idea of free upgrades in a product, and TRichView’s policy prompted me to do the same with Behold. When I tried to install the new version, the 32 bit-version installed fine, but the 64-bit version did not because the directory for it was not set up yet in my installation of Delphi XE8. I found that I had to load a sample program and rebuild it in 64-bit for Delphi to create the needed directories. A nasty thing this installation did was to delete the TRichView binary from the 2009 version. I had to recreate that binary. Doing so was tricky since Delphi coughs badly when a package is missing and doesn’t let you in easily. I had some fiddling around to do to get it working. This is not something I do every day so I had to look for help or clues and figure out what the proper directories were. But I was able to get this all going in a couple of hours. I added a message on the TRIchView private forum to let the author know about these glitches in the installation so he can prevent them in future versions.
  2. LMD Elpack, is what I use for the TreeView, the grids in the Organize pages, and a few lesser components. I was using their 2009 Version. I needed the 2015 upgrade which includes support for XE8. So I ordered the upgrade. It’s nice that TRichView users get 20% off of any LMD purchase. Installing the ElPack upgrade was easier than TRichView was. The files were loaded into their own 2015 directory that was separate from the previous 2009 directory. And it knew that it was only supposed to be installed into Delphi XE8 and not Delphi 2009. After going through hoops to get the installation package from the LMD protected area, the installation was straightforward and worked reasonably well.
  3. EurekaLog, is what I use to trap errors and show an a error reporting box to the user, rather than just letting the program crash. It also helps me find and fix memory leaks in Behold. It had a special Cyber Sunday deal of 70% off for one day only last November which I took advantage of. That was for Version 7.x.  So now I downloaded and installed the latest 7.2.5 version which supports XE8. I was previously using version 6.0.21 from 2009. Installing EurekaLog had a few problems. First, It wanted to delete the previous version of the program before it would allow the new install. I found a EurekaLog support document on how to install two versions of EurekaLog. I had to go into RegEdit and change Eureka log to EurekaLogOld, then install the new version, and then go back into RegEdit and rename EurekaLogOld back to EurekaLog. Thats not a very nice way to have to do it. But then, it still didn’t work. When installing the new version, it gave two system errors. It couldn’t start InstallDiag.exe or Viewer.exe because VCRUNTIME140.dll was missing from my computer. After researching, I found that happens to be a library that comes with Visual Studio 2015, which of course I don’t have installed. EurekaLog’s installation should not depend on this. I downloaded the file (found from an answer in StackOverflow) and reran the installation of EurekaLog 7. Again I had to do the RegEdit thing for Version 6. Now the installation of 7 into Delphi XE8 worked. But Delphi 2009 still wasn’t working. I went back and found my original 6.0.29 installation and reinstalled it. Behold in Delphi 2009 recompiles and runs again. Yay!  By the way, EurekaLog’s install program is unsigned in both its version 6.x and 7.x – meaning Windows gives big bad warnings about running that “untrusted” program.

Now that was easy wasn’t it? Only about 2 days elapsed time. Behold now again compiles and runs fine in Delphi 2009. Delphi XE8 is also set up with the new versions of the needed packages installed into it. The next step is to get Behold to compile and run in the new environment.

Redefining Plans - Tue, 30 Jun 2015

It was really nice to get version 1.1 out. In doing so, I’ve taken into deep consideration the last line from my Living Up To Expectations post a few days ago, where I said:

Maybe after 1.1 is out, I should directly track towards Version 2.0 and just do what’s necessary to make that happen.

It’s true. I have been caught up in a lot of things with Behold over the past few years. Making a powerful GEDCOM reader, Ancestral Loops, Windows Certification, and other knowledge-based things, and of course many restarts of the Life Events that took a couple of years before I had the right model that I could implement.

Now, I’m not saying that any of these are bad things. All worked to make Behold better.

But when I sit down to think what it is I really need Behold to do, the number one reason why I want it is so that I can personally enter my own genealogy data in an efficient and organized source-based manner that I have long wanted to do.

Unfortunately, none of the above things I’ve been doing have got me closer to that goal. So I have to admit, the criticisms on GenSoftReviews were correct. I’m not getting any closer.

What this demands is a change of direction. Just aim me at my real goal. Let’s get to Version 2 and editing. I can add all the other stuff later as I need it.

Well, let’s even change that last statement to:
     I can add all the other stuff later if I need it.

Once editing is added. I’ll be able to start using Behold myself to enter my own data. That will allow me to see what’s needed and I’ll be able to add needed stuff and make it available to everyone as I do that.

Take a look at my new Future Plans page. I give the things I’m hoping to get into Version 2.0, and then have organized everything else into groups of ideas of things that I might want to do afterwards. But that will depend on what I find is needed rather than just going down the list one by one (which as you and I have both found out, takes forever).

I will try to get the Beta out sooner rather than later. As soon as I have something working enough to show the concepts, I’ll try to make it available. In the meantime, keep checking my blog posts. I intend to be writing blog entries more often as my new means of giving status reports and keeping me on track.

I’ve also decided not to go to RootsTech this February. Earlier, I was hoping to submit 3 presentations and head down there. But now I would sooner spend as much of the time as possible up to then trying to get Behold to Version 2.

I’m still committed to the 11th Unlock the Past Cruise in February where I’ll be giving at least seven talks. That will serve as my conference fun and vacation from our frigid Winnipeg winters this year. If you can afford the Clock and $$, do come and join me.

And if I can get Behold 2.0 all polished up by 2017, that’ll be the time to go to RootsTech!image

I started a new counter on my phone. It says I’ve been programming towards Version 2 now every day for 2 days. Let’s see if I can keep it up.