I need an Expert

January 13th, 2017

Over the years various files that should be included in the Delphi installation package have gone missing such as MidasLib for 64 bit builds for instance and now ExpertsCreators.dcp (I still can’t get my head around the package name - shouldn’t it be “ExpertCreator.dcp”).

I was going to try out DMVC and of course the 5 minute instructions didn’t work.  Not that it was oversight Daniele Teti’s part, but because he uses the Enterprise version in which they are included, and I am using the Pro version in which they are missing.   The DMVC and DUnitX projects are both impacted by the same issue.

Today I thought I would try the Berlin Pro edition to see if it has the file and sure enough, it’s still missing.  This has been an issue for coming up on a year now.

When I asked Daniel to include the DCP file he refused, citing a license violation.  To think EMBT/Idera is concerned about copyright violations!  Perhaps they should be more concerned with correcting their oversights, even if it’s such a small one…

This is another example (is it RAD Studio or Delphi?):

Navigating an Unresponsive IDE

January 3rd, 2017

I’ve found that Ctrl + clicking an identifier while debugging an application often causes the IDE (at least Seattle) to become completely unresponsive.  Using Ctrl+Shift+Esc to invoke the Task Manager seems to interrupt the IDE’s thread, returning it to a usable state.  While I try to avoid Ctrl+click navigation while debugging, it is just so useful (when it works) and I’ve been using it so long, that it’s a hard habit to break.

Recovering from AutoRecover

December 20th, 2016

Here is a great example of a UI which could be much more intuitive. I got this after my machine spontaneously rebooted last night.  I am running Embarcadero® Delphi 10 Seattle Version 23.0.21418.4207.

A Great UI

A Great UI

It doesn’t say how you are to save the files, and although Beyond Compare has been bundled with Delphi for a long time you cannot see any of the changes between the recovered version and that currently on the file system (if they are different). There is no right click menu, help option, or any indication of what happens to the recovered files if you click the close button. Are they lost forever, or can you recover them later if you wish? Are they in a specific folder other than that shown (because the filenames shown are the  original ones).  For those with a keen eye you will also see that great care was taken when formatting the filenames since the datetime of recovery (I assume) is part of the filename (there is no space separating them).

Worse yet, double clicking on them to load the file into the editor gives the infamous Dangling reference count dialog, for every file recovered.  As a result, loading them into the IDE provides no benefit.  You cannot use Beyond Compare to check them against any backup files that may exist.

Clicking the Close button on the previous save dialog, I am prompted if I want to discard all the recovered files.  I said No, but now I have no idea what the IDE just did.  Even the help doesn’t completely describe how the feature works and how to recover the files if you close the initial dialog and do not discard the recovered files.

Looks to me like another half baked feature…

The Delphi Win32/64 Compiler Could be Smarter

November 18th, 2016

It’s a good practice to always treat compiler warnings as errors, to ensure your code is correct, so it’s a little annoying when the compiler warnings are not necessarily true.  For instance, you have an enumeration like the following:

 TMeasuredFrom = (mfCenter, mfUpstream, mfTopLeft);

then in some method you code the following:

function TXXX.GetXXXValue(const Value1, Value2: Double): double;
begin
  case FMeasuredFrom of
    TMeasuredFrom.mfCenter:
      Result := Value1- Value2;
    TMeasuredFrom.mfUpstream, TMeasuredFrom.mfTopLeft:
      Result := Value2 - Value1;
//  else
//    Result := 0; //prevent compiler warning
  end;
end;

the compiler will give the following warning unless you reinstate the else for the case :

[dcc32 Warning] XXX.pas(230): W1035 Return value of function ‘TXXX.GetSomeValue’ might be undefined

Now you can turn off the warning using

 {$WARN identifier ON | OFF | ERROR | DEFAULT}

but the identifier you need to use is not what the compiler outputs (in this case W1035).  No that would be too easy…you have to use NO_RETVAL, which is more mnemonic but begs the question as to why the compiler doesn’t output this identifier instead in the first place!

Not only that, but the compiler directive cannot be embedded in your method bodies to preserve state and move with your code.  For example:

function TXXX.GetXXXValue(const Value1, Value2: Double): double;
begin
{$WARN NO_RETVAL OFF}  //turns the warning off
  case FMeasuredFrom of
    TMeasuredFrom.mfCenter:
      Result := Value1- Value2;
    TMeasuredFrom.mfUpstream, TMeasuredFrom.mfTopLeft:
      Result := Value2 - Value1;
  end;
 //turns it back on so the compiler still warns about this method
 {$WARN NO_RETVAL default}
end;

//this directive outside the method body must be used otherwise
//the warning is off for subsequent methods in the unit.
{$WARN NO_RETVAL default}

What we really want to do is ignore this warning for this method only so other warnings that may appear in this unit can be addressed in the future without having to see the one for this method which we know requires no action.  We don’t want to have to put directives outside the method body since most refactoring tools don’t understand directives and comments etc that are adjacent to a method and keep them with the method.

What I would like to see is a a different setting for this method; OFF_FOR_METHOD that disables the warning for the current method.

That said, maybe the compiler should just be smart enough to see that you are returning a value based on an enumerated type, and that all enumeration values are accounted for, so the method will return values for all possible code paths.

DavidI is Apparently Leaving EMBT

September 23rd, 2016

According to this article, DavidI is leaving EMBT to work for Evans Data.  Very interesting times, with Nick Hodges returning and DavidI leaving.

The Lengths we will go to for a Bug Fix

May 25th, 2016

For anyone using the Win64 Debugger in DX Seattle, you have probably experienced this little gem:

Debugger is Buggered

Debugger is Buggered

This seems to happen more frequently with multi-threaded applications, and unfortunately is not the only issue with the debugger.  Being unable to step into interfaced method calls which was reported on 12/1/2014 4:49:50 PM (541 days ago) is a real pain for 64 bit development.  Both issues are present in Seattle Update 1 and both are still unresolved with the release of Berlin.

I have been meaning to investigate how to use one of my support incidents to escalate RSP-14144, and apparently I am not alone in wondering how to get the priority changed for bugs to be addressed.  Keith Dopson has offered free meals, accommodations and shuttle service for EMBT to address RSP-13503 which surprisingly EMBT has not been able to duplicate. Kudos to you Keith! I hope it works out as we will all benefit.

Update - RSP-14144 was synced with the internal bug system yesterday. Apparently it is resolved in Berlin.

Not The Ideal Idera Experience

May 19th, 2016

My DX Seattle installation starting throwing access violations whenever a form was loaded into the IDE last week.  I had started to install Berlin on the same machine, so I wasn’t sure if that or some other installation had triggered this situation.  Having to bounce the IDE every 5 minutes was increasing my frustration level to the point I was about to nuke the whole machine, when I thought I would try a quick google to see if I could find the cause.  I found this thread, so I toggled on Tools - Options - Form Designer - Show Non-Visual Components and it worked!  I decided to search the bug reports only to find it has been fixed in Berlin.

I have an update subscription.  I was not notified that Berlin was released.  I found out from reading beginend.net posts well before I received a general marketing email on April 20th.  I wasn’t notified that a bug which might affect my product was fixed.  While I can subscribe to individual issues, I do not believe that I can get notifications for all bug fixes for my product edition.  Something Idera might want to look into…

A Case for YAGNI?

May 6th, 2016

I have worked with Delphi for a long time now (since D1), and am embarrassed to say that for the first time today, something occurred to me I have never thought of before.  I was waiting for DX Seattle to finish compiling a rather large project, or more accurately link it.  I was threading some legacy code and wanted to verify my changes could be compiled.  This is a very common usage scenario for Delphi.

It occurred to me that linking the EXE was a complete waste of time, and that link cycles are longer than normal because we are creating a detailed MAP file in our debug configuration.  I could eliminate this file, but we often use it with other tools.  I was thinking I should use Delphi’s Project - Syntax Check menu option instead.  So I tried it, and it ran through all the units in my source path that were referenced in the current project (directly or indirectly).  I thought to myself that the documentation which claims that “an efficient way to verify before compiling that a large project will build correctly” is not exactly accurate.  If it is so efficient, you would think it would be the preferred option to use, and it would have a menu short cut.

A more efficient way to to check for correct syntax is using Project -> Compile because it only re-compiles units that have changed since the last compilation.

So I was thinking, why wouldn’t the Syntax Check option do the same as a Compile, only checking changed files, or why wouldn’t the Compile avoid linking?  Most of the time linking is not necessary and could be performed when you hit F9 or Shift + F9.

The Parsing Problem

May 2nd, 2016

One of the major stumbling blocks Delphi tool developers have to overcome is the parsing problem.  Any add-in that allows re-factoring of code at any level must first parse it accurately enough to provide the additional functionality.  While Visual Studio has a VSIP (Visual Studio Integration Partners) program, EMBT has nothing to my knowledge.  They seem to discourage third party tool developers by not documenting the OpenTools API, or extending it to open up possibilities that are found in other IDEs from other vendors.

I don’t think this necessarily intentional, but the effect it has on the productivity of the IDE is enormous.  Up until the release of XE8 (IIRC) basic code navigation was missing from the IDE.  With the acquisition of Castalia the base product finally had a way to jump to method implementations short of using Ctrl+Shift+ Up/Dn Arrows after finding the method name.  By that time, most everyone was using a combination of GExperts and/or CnPack.

If you look at tools like ReSharper, or CodeRush for C# you will see just how far the Delphi IDE toolset is lagging behind.  Why?  Primarily because as the Object Pascal language has evolved under EMBT (kudos to them for doing so), there has not been a published language specification.  Third party tools reliant on their own parser have been left behind.  I’m not sure about those based on the Castalia parser derived from Martin Waldenburg’s parser.  I assume Castalia has also fallen behind since it’s last update was in October 2011.

Inevitably, some of these tools will no longer parse what is now valid Object Pascal.  I just ran into one today.  A tool that has been in the Delphi space since 2001.  I downloaded Peganza’s Pascal Analyzer and tried to run it on one of our projects to see what it could offer.  It failed in third party code that heavily uses generics (Spring for Delphi) in the Spring.Collections.MultiMaps unit line 49 of my version which reads:

fDictionaryEnumerator: IEnumerator<TPair<TKey, ICollection<TValue>>>;

with the error:

Syntax error type #123 (<) at Spring.Collections.MultiMaps row 49

Code re-factoring and analysis tools are critical for writing Enterprise level applications that must run 24×7.  I wish EMBT would open up the IDE so we could get rid of the spinning hourglass while code is parsed in the main IDE thread, and make the IDE more responsive.  While better in terms of not crashing with “Out of Memory” errors, DX Seattle is slower, still has leaks, and has issues of it’s own with 64 bit debugging.  An IDE needs to be stable, performant, and provide the developer with a rich set of tools for re-factoring their code.  There is much to be done on this front IMHO.  I think, formalizing the language and opening up the internal parser information would go a long way.  Even better, would be open source the IDE and let the community fix it :-)

Temporary Outage

April 22nd, 2016

You may have noticed that my blog has been off line for a while now.  Took me a couple weeks to find the time to rebuild my machine after a hard disk failure.  It’s still not 100%.  Images are not appearing with the blog articles for some reason.  I hope to have that resolved this weekend.