Some Delphi settings require you to run with an Administrative UAC token
Posted by jpluimers on 2019/10/16
Though user-defined Code Templates live under %UserProfile%\Documents\Embarcadero\Studio\code_templates\Delphi, the stock ones (standard ones shipping with Delphi) ones do not: they live under %ProgramFiles(x86)%\x\Studio\y.0\ObjRepos\en\Code_Templates.
Above, x usually is Embarcadero, and y is your Galileo version number; see for instance Update to List-Delphi-Installed-Packages.ps1 shows HKCU/HKLM keys and doesn’t truncated fields any more.
Unlike user registry settings, which are copied from HKEY_LOCAL_MACHINE to HKEY_CURRENT_USER, the stock Code Templates are not.
This means that if you want to change the stock Live Templates (for instance disable them) from the IDE, or from the Windows Explorer, you need to run them with an UAC token to elevate them to Administrator level permissions.
Oh, did you notice the consistency between
code_templatesandCode_Templates? Delphi is full of these consistency surprises**
via: [WayBack] EDIT…..ANSWER: Right-click and run Delphi IDE as “Run as Admin”.. remove the template. Start IDE normally. .. IMHO, you shouldn’t have to do this… – Vin Colgin – Google+ who commented:
Vin Colgin:
+Uwe Raabe yes. Imho. Delphi should use a UAC helper app to change things that need elevated permissions… just like we all have been doing with shipping software since Windows Vista. But nobody asked me. Imho.
as a response to
Uwe Raabe:
Usually you don’t have access rights to Program Files where the standard code templates live. Therefore you cannot remove any of these from inside the IDE. Either adjust the behavior to your needs (that will make a copy) or remove it from $(BDS) with admin rights.
** Some more consistency examples:
Just pick a few functions from these or more recent Delphi versions:
- [WayBack] Delphi 2007
StrUtilsunit - [WayBack] Delphi 2009
StrUtilsunit - [WayBack] Delphi 2009
AnsiStringsunit
For example (there are many more):
- [WayBack] AnsiContainsStr(const AText: ; const ASubText: ): Boolean;
- [WayBack] AnsiContainsText(const AText: ; const ASubText: ): Boolean;
- [WayBack] AnsiEndsStr(const ASubText: ; const AText: ): Boolean;
- [WayBack] AnsiEndsText(const ASubText: ; const AText: ): Boolean;
- [WayBack] functionAnsiIndexStr(const AText: ; const AValues: array of ): Integer;
- [WayBack] AnsiIndexText(const AText: ; const AValues: array of ): Integer;
- [WayBack] AnsiLeftStr(const AText: AnsiString; const ACount: Integer): AnsiString;
- [WayBack] AnsiMatchStr(const AText: ; const AValues: array of ): Boolean;
- [WayBack] AnsiMatchText(const AText: ; const AValues: array of ): Boolean;
- [WayBack] AnsiMidStr(const AText: AnsiString; const AStart: Integer; const ACount: Integer): AnsiString;
- [WayBack] AnsiReplaceStr(const AText: ; const AFromText: ; const AToText: ): ;
- [WayBack] AnsiReplaceText(const AText: ; const AFromText: ; const AToText: ): ;
- [WayBack] AnsiResemblesText(const AText: ; const AOther: ): Boolean;
- [WayBack] AnsiReverseString(const AText: AnsiString): AnsiString;
- [WayBack] AnsiRightStr(const AText: AnsiString; const ACount: Integer): AnsiString;
- [WayBack] AnsiStartsStr(const ASubText: ; const AText: ): Boolean;
- [WayBack] AnsiStartsText(const ASubText: ; const AText: ): Boolean;
Of the above methods:
- 9 have a starting const AText: ; parameter
- 3 have a secondary const AText: ; parameter
I get it that these won’t be changed because they have been this way for more than a decade, but in my book, designing that way back then in the first place would show lack of code review or seniority in the team, no matter if part of these functions look like [WayBack] StrPos and [WayBack] AnsiPos in the [WayBack] SysUtils unit.
A while ago, [WayBack] Paul TOTH Found out that the below two functions have their parameters in reverse order:
var Comp : function(const s1, s2: string): Boolean; begin if CheckBox1.Checked then Comp := ContainsText else Comp := AnsiStartsText;why are the parameters in a reverse order !!!
There was an issue filed on some of the above functions in 2016, which was only getting a feedback from the internal bug tracking service almost a YEAR LATER:
Jira-Quality Sync Service added a comment –
Sync status from internal system, internal issue closed on Dec 22, 2016 by Marco Cantù with comment:
Even if having similar functions with different sequence in params was a bad idea on our side, changing the sequence of parameters for EXISTING functions and breaking the semantics of existing code seems even worse. So we are not going to do this.
–jeroen
The Wiert Corner - irregular stream of stuff 
Changing the sequence of parameters for EXISTING functions seems a very bad idea, as this changes the semantic on existing code that compiles. In general I’d agree tat consistency is important. But I disagree parameterless calls are such a smart move in terms of readability.
I’m inclined to close this request as “won’t do”