TPersistent.com

Today I got frustrated by XE2 rewriting the DPR source file when switching between 64 and 32 bit Windows targets.  Eurekalog doesn’t compile yet for Win64, so I added a conditional directive around that unit in the DPR source.  When XE2 undid my change, I turned to Quality Central to see if one of my numerous reports regarding conditional compilation issues has been addressed.  I use the Windows QC Client even though it’s a very old style MIDAS type interface which isn’t the most intuitive, at least it works (including voting).

The windows QC Client has been around forever, yet strangely, it’s still version 1.

QC for Windows About Box

This got me thinking about how many updates I’ve produced over the last year on my current project alone.  We started the year with version 3.0.0.0 and are up to 3.2.0.7.  That means some significant changes to an already mature product.  To get an idea of how my reports were progressing, I took a look at my user stats:

My User Stats

The submission information really doesn’t give much insight.  For instance, it doesn’t indicate the average age of a report that is open or closed, and doesn’t even give counts of the number of reports marked as not reproducible, duplicate, fixed, or still languishing in the reported state.  A lot more could be done for this dialog alone (charts anyone?).

Since I didn’t understand the difference in the Voting group between Total and Total Votes (they are after all in the same group box, so what else could Total refer to, but the total # of votes), I thought I would check out the help.  Choosing Help - Quality Central Web Site from the menu takes you to the main QC Website where it says Embarcadero Developer Network on the banner graphic, but there are still numerous references to CodeGear.  How long has it been since EMB bought CodeGear?  Oh yeah….thanks Google…8 May 2008….about 4 years ago now.

I decided to check out the general help for the QC Windows client even though it has not been updated since John Kaster did so on December 15, 2006.  It’s contents are meager one page, and there is a comment from Kris Kumler on Jan 22 2009 politely asking for the missing content to be added.  Of course, the User Stats information I was looking for isn’t present.

It’s been my experience that both people and companies spend their time on things that are important to them.  They often say one thing, and do something else, so watching what they do gives the most accurate picture of what they feel is important.  It’s also been my experience that once an application hits the streets, users find issues that even the best internal testing misses.  In order to produce a better product, you need as much accurate feedback from users as possible and using state of the art tools to collect as much information as timely as possible is paramount.

We use Eurekalog to capture error reports, and a ticketing system for users to submit enhancement reports.  I’ve found Eurekalog reports to be indispensable in figuring out how to reproduce a problem because users are often unable to communicate what they were doing that lead to the problem, sometimes due to a lack technical knowledge, or an understanding of what information is useful.  Sometimes they simply don’t care enough to spend their time to help you.   That’s why I envy EMB’s position; having highly technical people provide bug reports, and willing to spend their time to try to get it fixed because they use the tool daily and it’s important to them.

So why is it then that the oldest of my QC reports have been in the Reported state since 1/24/2007?  My oldest Delphi related report still in a Reported State with no comments is 7/22/2011.

I used to oversee a support department of 3 technical support representatives that supported 5 different medical billing and practice management solutions.  I personally reviewed the support call logs, acted as second level support, engaged development to address issues, and even called random clients to inquire about the quality of the support they received.  If I would have let support issues get 5 years or even a year old without addressing them, I would have been let go.

I would rather pay a support fee, than a maintenance fee that guarantees a new product version.  Support fees mean issues get fixed in a timely fashion instead of packing more features dreamed up by marketing into the box.  How do you feel about QC?  Do you think your reports get the timely attention they deserve?  Do you think the QC processes are well documented and transparent?

BTW, Ford’s mantra is probably what saved them from needing a bailout, and resulted in their recovery from hard times…  The economic value of investing in quality has been repeatedly proven.

It is not necessary to change the DCP output folder because the defaults automatically take into account compiling for different platforms.  In the Tools - Options - Library settings if you select Win32 you will notice that the Package output directory is set to:

$(BDSCommonDir)\bpl

and the DCP output directory is set to:

$(BDSCommonDir)\dcp

which works great since the IDE is a 32 bit EXE and this folder will be on the search path so the IDE can load the design-time packages.  This provides backwards compatibility, but the moment you start compiling the same package for additional targets it becomes cumbersome.

If you select Win64 or OSX you will notice that the package output directory changes to:

$(BDSCommonDir)\bpl\$(Platform)

It’s interesting that you cannot modify the Library Path globally, so if you have a product that compiles for multiple platforms you have to add the necessary bits into each Platform’s version of the Library Path.  This is an enhancement I have suggested in QC#105378 .  Personally I have always preferred explicit specification rather than implicit, and as such I think the default Package output directory should be:

$(BDSCommonDir)\bpl\$(Platform)

and likewise the default DCP paths should be:

$(BDSCommonDir)\dcp\$(Platform)

This is sort of like defining a class as

TMyObject = class
end;

vs.

TMyObject = class(TObject)
end;

I believe consistency in usage promotes more readable and thus more maintainable code and IDE environments.  From my experience it’s also easier to manually purge your output folders, and confirm the appropriate units are being generated if a consistent directory structure is used.  If you agree, please vote for QC #105377.

In the case of hcOPF the Library Path needs to contain the following:

$(hcOPF)\Lib\D16\$(Platform)\$(Config)
$(hcOPF)\Source\Resources
$(hcOPF)\Source\Include

If you happen to notice that the Path is greyed when you add it to the dialog, don’t panic.  For some reason, the Directories dialog has problems validating Paths that contain $(Platform)  which is evident by the first path in the list

$(BDSLIB)\$(Platform)\release

also appearing in grey.  I have entered a QC report (#105375) for this, so please vote for it.

So DCP and BPL output folders are handled by default in a suitable fashion by the IDE, unless you’re like me and prefer a more uniform directory structure in which case you can change the Win32 DCP and BPL path defaults in the Tools - Options - Library dialog.  If you change these paths, packages which do not have an override value specified in their Project - Options, will output to the new default directories.

At a minimum developers need to make sure their Unit output path does not collide which means using a structure something like .\Lib\D16\$(Platform)\$(Config) as I alluded to in my previous post.  This is also handled by default if you’re creating new packages in XE2.  If you’re upgrading existing packages, make sure to set the unit output path to use $(Platform)\$(Config) as well.

One thing I find intriguing is that under Project - Options for ‘DCP output directory’ there is an entry for the Target ‘Debug Configuration - All Platforms’, yet there is not one for ‘Release Configuration - All Platforms’.  Maybe someone can explain this one to me…

I’ve put quite a bit of effort as of late getting hcOPF ready for Win64 compilation, and as part of that effort, re-factoring it to support FireMonkey.  The actual code and package changes were relatively minor when compared with trying to understand what was required.  To me this validates the design of the framework that it can be adapted rather easily to support new frameworks and platforms.

There are no new recommended guidelines for DesignTime and RunTime packages AFAIK now that XE2 supports FMX and VCL.  To complicate things further, add in Unit Scope Names, the fact that the IDE automatically renames FMX package projects when you target the OS/X, and all the conditional directive permutations, and it can drive you bananas!

On top of that, the IDE does not provide default guidance when upgrading packages from earlier IDE versions.  It does not default the unit output directory to .\$(platform)\$(config) as it does for new ones, so when you compile for one platform you overwrite your DCUs for another, and really confuse things.  For this reason, you might notice that for All configurations - All platforms hcOPF uses a unit output directory of $(hcOPF)\Lib\D16\$(Platform)\$(Config) where $(hcOPF) points to the root directory of the framework.  It would be great if there was an environment variable for the IDE version.  Then you could use something like $(hcOPF)\Lib\$(DelphiVersion)\$(Platform)\$(Config).

I am pleased to announce that hcOPF now supports FireMonkey (Win32/64 and OSX32) as well as VCL Win32/64 targets with a few caveats:

1) when compiling for the Mac or any 64 bit target you must skip compilation of the design time packages.

2) The HengenOPFValidatorsFMX/VCL packages do not support 64 bit targets since it uses the open source PerlRegEx component instead of the RegEx support present in XE and above.

3) Certain packages of course cannot be used on certain platforms like ADO and the Validators on the Mac since they have Windows specific implementations.

4) As always some packages require third party commercial libraries, such as the HengenDevExpressXXX packages which require the Developer Express Quantum Grid suite (highly recommended).

5) Win32 BPLs go into the default $(BPLDir) and those for OSX32 and Win64 go into their respective subdirs

In a future version I hope to add support for iOS as well as providing validator support for FMX.  Currently hcOPF will not compile using FPC because it does not support the implements interface delegation syntax that EMB’s compiler does.  Eventually I plan to support FPC and SQLite.

If you want to start Monkeying around with hcOPF, check out the FireMonkey SVN branch.

I’ve made no secret that I loved CodeRush for Delphi.  I still mourn the loss of Mark Miller from the Delphi community.  CodeRush was, by no means perfect.  Some of the issues I had with it may have been due to Delphi bugs, undocumented APIs, or bugs in CodeRush itself.  All I know is that I was much more productive with it, than with the standard IDE, and unfortunately, that still holds true today.  CodeRush, circa 1997 has great code navigation and smart templating.  Compare that to XE2 today:

If you create an FMX application and in the main form, type in pr and hit Ctrl+J to use the template this is what you get:

procedure MyProcedure();
begin
end;

What is in Italics is selected so you can replace it.  This leaves a little to be desired.  For one thing, pressing Ctrl+C to invoke code completion won’t even do anything, so the code won’t compile because there isn’t a preceding method prototype.  Add the fact that the entire unit is a form and the method generated by the template is not even for the form class, and it’s almost comical.  The template appears to be completely ignorant of the context in which it was expanded, and you might expect a modern IDE to ask for the scope of the new method, and automatically insert the declaration into the type or implementation section using the appropriate scope.  This kind of functionality actually makes you wonder if anyone at EMB is dogfooding the product.

Then there is code navigation.  You can use the Ctrl + Up/Dn Arrows to jump between method declaration and implementation.  Sometimes it gets a little confused if you use overloaded methods, but this works pretty well, but how do you jump to the implementation or interface section?  The standard IDE doesn’t provide such functionality, and this is a common activity when creating or changing method prototypes.  So common, in fact, both CnPack and GExperts have provided this functionality in additional to method searching.  As someone new to the IDE, you likely wouldn’t know you have to install third party products for such basic functionality, and when looking at the purchase price of XE2 it seems you get a whole lot less, even though these third party add-ins are free.  The downside to these tools is that they also use their own code parsers, so many of them have a limited understanding of new language features, and require even more code to continuously run in the editor to provide the additional capabilities.  I really wish EMB would provide a CodeDOM for the development of such add-ins and incorporate some of this functionality into the standard IDE.

The examples I’ve given are only the tip of the iceberg.  I have QCed a number of these issues, including bugs in code completion that result in AVs at run-time because it inserts invalid code.  Since then, XE2 has shipped, and 4 updates have been issued, but the bugs I reported in QC still remain.

Software is one product in which quality matters more than most.  It affects the day to day experience of the user.  While quality has definitely improved in the Galileo IDE since CodeGear was spun off, and has continued under EMB, IMHO there is still much to be done.  I often wonder what the state of the IDE would be, if the D7 IDE had not been replaced with the Galileo IDE, and instead all that effort for the new IDE and to add new features like UML modelling which few people use, had been put into making the existing IDE even more RAD.  When the stock IDE has the same basic functionality it had 15 years ago when it was branded as RAD (where R stands for Rapid), can you still call it RAD 15 years later in computing time?

Personally, I would have rather have better IDE navigation, templating, and refactoring productivity features than half baked features like ErrorInsight, which gives so many false positives, I normally just ignore it.  I certainly hope that EMB considers an a la Carte pricing model at some point, and concentrates of fixing issues with the IDE as well as fleshing out FMX for the next release.  For now, I’ve passed on the XE2 update offer for my personal use until some of my QC issues are fixed.  Perhaps QC votes should be changed into dollars, so you can vote with your pocket book

If it comes down to a question of doing it well, or not doing it at all, sometimes less is more.

As I mentioned in my previous post, I’m starting to play more with FireMonkey, and one of the first things I noticed when writing an application, is that despite 4 updates there are still no action components.  Although I only started using actions long after they were first released, their benefit has been made obvious to me time and time again.  In my current project I use quite a bit of logic in my TAction.OnUpdate events.

I missed them in .NET, and now I am missing them again with FireMonkey.  If you’re filling out the Delphi survey, you might want to put in your vote to include TActionList, TActionManager, TPopupActionBar, TActionToolBar, and TActionMainMenuBar.  All of them are suspiciously missing in FMX, and I would venture that no self respecting Delphi developer would embark upon a project without the core tools we’re used to using in the VCL realm.  Certainly this is one other requirement for “porting” a VCL app to FireMonkey.

Now to get back to working on that FMX app…

I have finally started re-factoring hcOPF to support FireMonkey and Win64.  Win64 was a breeze, but supporting FMX is proving to be a bit of a challenge.

If I was EMB, I would be trying to make FireMonkey a write once compile on many platforms solution, and it is across Linux, Mac OS/X and Windows AFAIK, if you build an FMX application.  However, I would venture that most customers are looking to port their existing VCL codebase to access more markets, or at least leverage their existing knowledge, and might be a little hesitant to bet it all on a newly released UI framework sold and supported by a single vendor (especially after CLX).

All developers know, changing code tends to break what once worked, especially when you introduce more conditional compilation (check out my QC request 94287 to make conditional compilation easier to use).  To accomplish this end, the API usable to FireMonkey applications needs to have as much in common as possible with even VCL for Windows applications because at some point a developer will use code to manipulate the controls.  If it’s possible to use the same code for both platforms, you’ve saved in not having to maintain functionally duplicate code and in dealing with conditional compilation.

The ideal scenario would be to be able to specify either a FireMonkey or a VCL form DFM in a conditional directive, and have all the UI code shared (or minimal conditional compilation).  Of course, if you want to use the advanced functionality available in FireMonkey, perhaps this approach isn’t viable.  If you just want to target Mac OS/X without having to re-write your VCL application forms, and are using FMX for basic presentation of data, this would be ideal!  You wouldn’t have to invest the same effort to determine the merits of FireMonkey as a UI replacement for the VCL because you wouldn’t need to keep two separate UI source code trees in sync while FireMonkey matures.

So far, with my brief exposure to FireMonkey with XE2 I can see a number of problems in achieving the Write Once Compile for Many Platforms concept.  FireMonkey uses .Text instead of .Caption for some control window captions (ie: TGroupBox).  So while the control class may be the same, even some simple UI code cannot be shared with a VCL application.

Even non-visual code may be a challenge to re-use.  For instance, I use GetTickCount() to time activity in hcOPF.  I want to keep hcOPF compilable for users of D7 and above.  I personally feel that my coding productivity was higher in D7 with CodeRush than the Delphi XE with GExperts and CnPack.  Part of the reason for this is the code parsing the IDE performs in the main thread.  Type in Begin incorrectly, and you can be waiting for 10 seconds while the IDE tries to figure out what is going on.  That’s pretty sad on a 6 core system…but I digress.

GetTickCount() is implemented as an inline function in the implementation section in the System unit for MacOS and Linux, and the Windows implementation is in Windows.WinAPI.  Not a big deal to add a few {$ifdefs} to handle that, but GetTickCount() as defined in System is not accessible to other units.  So in order to use it, you will have to copy the implementation from System, and expose it.

From what I have seen of XE2 Update 4, FireMonkey is still not usable from a performance standpoint for replacing a normal VCL form. On my 6 core system with a Radeon 4250 the main form appears and you can visibly see the contents of the form background and content being rendered.  In this case, the form is just 4 edit controls in 2 separate group boxes using hcOPF Object Binding to populate the controls.

I think FireMonkey is a great concept, but adoption would be faster with an API more consistent with the VCL, and I think FMX has a long way to go before it becomes a viable replacement for the VCL and X platform Delphi becomes a true reality for more than the most trivial application written from the ground up for FireMonkey.

This weekend I went to install Delphi XE2 with Update 4 on my new development machine.  I had previously installed XE2 on my dev machine at work and in a couple VMs.  I upgraded my dev machine @ work to Update 4 on Friday, and then today, attempted to load XE2 Update 4 on my new dev machine at home, only to be told that I have exceeded the licensing limit.  In order to get the limit increased I have to email support.  It’s the weekend, so now I cannot install XE2 and do any work.

I called the support line for Canada, and of course the office was closed so I submitted a web request for technical support (case 00253157).  Fortunately, despite the inability to register XE2 EMB has allowed 14 days usage, so I’m not dead in the water.  It just nags you to register every time you start the product.  I’m sure this is thanks to all the XE2 “updates” that have required us to uninstall the previous version.  I’ve uninstalled and removed the registry settings (perhaps that was my mistake).

This kind of anti-piracy policy to me, is like hand gun registration.  The real criminals don’t register their hand guns, so it doesn’t prevent anything other than to make it more difficult for an enthusiast to own and use one, and definitely more annoying.

Even though I have previously blogged about DealFind leaving their customers high and dry when the vendor fails to render the service promised, this deal is just too good to pass on, and NAPA has a decent rep….

Today I looked at using ObjPas for XCode 4. The documentation is a little stale, but Phil Hess has provided an excellent guide to getting started as well as why you might want to use ObjPas/FPC with XCode compared to FireMonkey or Objective-C.

When I initially created a new project from the template as per the tutorial, I couldn’t run it. XCode reported an error and I had to scan through the shell script to actually discover it was unable to create a file. I discovered the path where it was trying to create the file didn’t exist, and googled the error to find a discussion on the exact problem.

After fixing the Create File problem as suggested by Simon Chol as follows:

I replace just the one character (armv6 -> armv7) in section
Targets | Items 0 | SharedSettings | FPC_ARM_SHARED_OPTIONS
/users/[...]/Library/Developer/Xcode/Templates/Objective Pascal/iOS/Objective Pascal App

/Cocoa Touch Application.xctemplate/TemplateInfo.plist

I then had to manually paste the following code with the [window release]; selected:

- (void)dealloc
{
[window release];
[super dealloc];

}

I also had to turn off Automatic Reference Counting (ARC) since it is checked by default when creating the project, and I had left it checked, so the compiler complained about the presence of NSAutoreleasePools.

My initial impression was that this approach is far better than using FireMonkey in terms of meeting Apple’s UI requirements, but since there is no code insight, or completion in XCode for ObjPas and you have to declare Outlets and Actions twice (once in Objective-C and once in ObjPas) this would get rather tedious rather quickly.

If you’re going to use the Pascal for development I think the XE2 approach of using XCode for compiling and debugging only is a much better approach.  It also opens up the possibility to one day develop for the iPhone solely on a PC when EMB finally releases their new compiler that supports ARM.

I’ve been a developer now for 19 years….wow!  A lot has changed over that time, but one constant has always been  that software companies who use their own products internally produce better software.  It’s called DogFooding in the industry.

When .NET first came out, a lot of developers were opposed to writing .NET code for performance reasons including load time, as well as the size of the executables, and the speed of the code.  One of the arguments against using .NET was that none of Microsoft’s own products were written in .NET.  Of course a lot of this had to do with the fact that their products were large legacy codebases and .NET gradually crept into the mix.

When WPF first came out a lot of developers thought it was interesting technology, but no one was using it, and the GPU overhead required newer video cards.  WPF usage gradually increased as Microsoft frameworks leveraged it, and then Expression Blend, and Visual Studio 2010 shipped showing that Microsoft was dogfooding their own technology.

The thought occurred to me today, that having to use FPC with XCode for the Mac can’t be a long term solution.  EMB has said they will be shipping their own compiler for the Mac, but what about the IDE?  Any conditional compilation will eventually require code editing in XCode which doesn’t have code completion for Pascal and all the other features of the Delphi IDE.  In addition, at some point requiring two machines (or a VM) when you’re targeting one platform will just become a pain.

I wonder if EMB will follow Microsoft’s example, and use their own UI framework that would have the added advantage of enabling EMB to make the IDE X platform.  That would be the ultimate showcase for their compiler and FireMonkey.