Uwe Raabe

Lars also showed a valid approach in his blog post. There is nothing wrong with using variables. As always you have to know what you do.

Now I have seen the link to the sample code. Will look into it.

I imagine what is happening and I assume it to be expected behavior, although I admit one has to know how variable capturing works to get it. It is even documented (Variable Binding Mechanism) There is still a lot of guessing about what is THandlerClass, OnHandle and how AddHandler is defined and what it does with its parameter, so it is difficult to give a detailed analysis.

The file might have been created on another machine.

function GuessDecimalSeparator(const Value: string): Char; { Assumes that the decimal separator is the last one and does not appeat more than once. Only dot and comma are treated as possible decimal separator. } const cSeparators: array[Boolean] of Char = ('.', ','); // possible decimal separators var idx: Integer; begin Result := cSeparators[False]; // default if none of the separators is found - alternative "True" idx := Value.LastIndexOfAny(cSeparators); if (idx >= 0) then begin Result := Value.Chars[idx]; if Value.CountChar(Result) > 1 then begin { if it appears more than once we use the other one } Result := cSeparators[Result = cSeparators[False]]; end; end end;

Define "fail". For German language settings it returns a comma, which is probably correct in most cases. If the choice is either comma or point, the algorithm can be adapted to that. Otherwise the task is just not fully defined for all inputs. So what would you call a correct result when the decimal separator is not part of the string?

function GuessDecimalSeparator(const Value: string): Char; { assumes that the decimal separator is the last one and does not appear more than once } var idx: Integer; begin idx := Value.LastIndexOfAny(['.', ',']); // possible decimal separators if (idx >= 0) then begin Result := Value.Chars[idx]; if Value.CountChar(Result) = 1 then Exit; end; Result := FormatSettings.DecimalSeparator; // Default end;

I expect to see no splash form on the taskbar in the first place - neither with or without icon. When I create a new VCL application I have an additional line after Application.Initialize which leads to that behavior: Application.MainFormOnTaskbar := True;

In Delphi a set is denoted with square brackets. Unfortunately a constant array is also denoted with square brackets. I have to admit that I am not happy with this language design decision either. The term [10] as well as (i being an integer) can be both a set or array constant. There is no rule for the compiler to choose one or another. There are scenarios where the compiler chooses different than the developer intended. If you feel that the compiler is doing wrong here, please open a bug report with this example.

Probably because in the second case "[10]" is seen as a set constant by the compiler. It works if you declare a variable with a proper type: var b: boolean; a: array of Integer; r: TMyRecord2; begin try a := [10]; r := r * a; // this line is compiled b := r = a; // this line is not compiled except on E: Exception do Writeln(E.ClassName, ': ', E.Message); end; end.

As I am still looking for a usable GIT client that matches the ease of the TortoiseHG workbench, I should probably evaluate SourceTree again.

The components you see in the Form Designer are those inside the BPL loaded at design time. As long as you don't re-compile this BPL you will work with the old version of the component. This can be different than the version compiled into your EXE, as long as the new source files are found somewhere in your search path.

This is an class approach. The benefit is the full encapsulation of the private parts inside the implementation section. unit uGlobalData; interface type TGlobalData = class type TValue = record ValName: string; ValInProject: boolean; end; public { these should probably be properties instead } Id: Integer; RecName: string; Values: TArray<TValue>; procedure PrepareGlobalRec; virtual; abstract; end; function GlobalData: TGlobalData; implementation type TGlobalDataImpl = class(TGlobalData) private type TLocalRec = record LocalRecStr: string; // ... end; procedure LocalProc1; procedure LocalProc2; var LocalStrVar: string; LocalRecVar: TLocalRec; public procedure PrepareGlobalRec; override; end; procedure TGlobalDataImpl.LocalProc1; begin end; procedure TGlobalDataImpl.LocalProc2; begin end; procedure TGlobalDataImpl.PrepareGlobalRec; begin // prepare GlobalRec data LocalStrVar := 'local test'; LocalRecVar.LocalRecStr := 'test'; LocalProc1; LocalProc2; end; var GlobalDataInstance: TGlobalData = nil; function GlobalData: TGlobalData; begin if GlobalDataInstance = nil then begin GlobalDataInstance := TGlobalDataImpl.Create; end; Result := GlobalDataInstance; end; initialization finalization GlobalDataInstance.Free; GlobalDataInstance := nil; end.

This has been the case for quite a while. The URL points to the defunct QualityCentral.

Indeed! I can reproduce it with IDEFixPack installed.

Cannot reproduce. Datatype dropdown list contains unique values here.

I wonder how this folder is going to be used as Shared folder. For a non-admin installation that should rather be %APPDATA%\Raabe Software\Shared and not %APPDATA%\Raabe Software\MMX Code Explorer. On the other hand I can imagine some buggy setup scheme from my side. So whatever that registry RootDir entry points to, copy the Indexers folder into that folder and you should be done. I will investigate the setup for any glitches - or better - rethink the folder architecture in general.

The Indexer templates are expected in the Indexers sub folder from the shared folder set in registry under HKEY_CURRENT_USER\Software\Raabe Software\Shared\RootDir. It is quite possible that something went wrong during the installation and the indexer files were not copied to that folder. I will check the setup for that.

For these cases I prefer moving the settings to a separate settings class independent from the settings form. Then I can create and initialize an instance of this settings class at startup, load the settings from some storage and adjust with some command line parameters. Then the settings are available all over the application without having to rely on the settings form creation. I often have the case where I need access to the settings long before the main form is created. This would be hard to achieve using the settings form as the central storage for the settings.

High(x) is implemented as Dec(Length(x)), while Low(x) can already be evaluated by the compiler. High and Length have some execution overhead to check for a nil array, so caching the value might be worth it.

The time saved by using ContinuaCI and FinalBuilder is worth much more than the cost for these tools - unless you are working for free, though. When comparing prices, don't forget to compare benefits, capability and comfort. Free is never an argument on its own. Oh, and the Solo version of ContinuaCI actually is for free. I tried several times to make use of Jenkins (actually I started with Hudson), but each time I gave up due to the effort necessary to get things done and the maintenance being a bit cumbersome (to speak nicely). So no one can say I didn't give it a chance. ContinuaCI has still room for improvement, no question, but @Vincent Parrett and his team are always open for feature requests and usually amazingly fast when it comes to fixing bugs.

The unthemed IDE is totally different. BTW, that screenshots somehow reminds me of Delphi 7 (which really makes me shudder).

Indeed! The time and effort to get a build project up and running (and actually doing what you want!) in ContinuaCI and FinalBuilder beats Jenkins by magnitudes.

Actually, I don't know and, to be honest, I don't care much. Usually there are other places slowing down a program and the gains from rethinking an algorithm or an architecture are probably better targets.

Well, it doesn't - it stands for Light/Dark Theme and Desktop (at least the rectangle behind it).