FredS

Which should not be required for a single privilege.

I was using Berlin elevated when I ran that and get the same error msg while running non elevated. My own wrapper around AdjustTokenPrivileges works because it checks the last error after that call regardless of the number of privileges adjusted. In your demo (GetLastError=1300) while running non elevated. This code behaves correctly: // Enable or disable the privilege Result := AdjustTokenPrivileges(LToken, False, LTokenPriv, SizeOf(LPrevTokenPriv), LPrevTokenPriv, LLength); Result := Result and (GetLastError = ERROR_SUCCESS);

Works in Berlin when I change output to an existing folder: 'd:\Notepad.dat' Plus this addition gives me the dialog below if I try to save into a dir which does not exist: ShowMessage('Could not save: ' + LReg.LastErrorMsg); [Window Title] Project1 [Content] Could not save: The system cannot find the path specified [OK]

Just read that on your site, sounds like a great option. As for hardware; Uwe supplied the link, a full Linux version is required (no router). I have that running but I'm thinking about hardware failure and in that case running a license server on the same machine(s) isn't optimal. I do have an Ubuntu Azure VM running and that may be the best way to do this..

I'm going to assume there are no Docker images nor light weight installs (for a Router) of this? This does seem to be an important change to consider, unless one believes in a flawless self updating registration system being right around the corner..

OK, but NOT irrelevant to the Legal License Holder..

Assuming this happened on Monday when you reported and not on the weekend it only took a work week 🙂

I have a couple of instances where this is more useful without the LookupDataset, additions below: interface type TDictionaryLookupList = class(TLookupList) public /// <summary> /// Binds a Dictionary Lookup List to a fkLookup Field /// </summary> class function Bind(const AField: TField): TLookupList; /// <summary> /// Binds a Dictionary Lookup List to a fkLookup Field without binding to a LookupDataSet /// </summary> /// <param name="AKeyFields"> /// Keyfields used to identify the Entry, (Default=EmptyStr) will use the Existing KeyFields value. /// </param> class function BindSimpleList(const AField: TField; const AKeyFields: string = ''): TLookupList; end; implementation type TFieldHelper = class helper for TField /// <summary> Sets Private Field </summary> procedure SetLookupList(ALookupList : TLookupList); end; procedure TFieldHelper.SetLookupList(ALookupList : TLookupList); begin if Assigned(LookupList) then LookupList.Free; with self do FLookupList := ALookupList; end; class function TDictionaryLookupList.Bind(const AField: TField): TLookupList; begin Assert(AField.FieldKind = fkLookup); AField.LookupCache := True; Result := TDictionaryLookupList.Create(); AField.SetLookupList(Result); end; class function TDictionaryLookupList.BindSimpleList(const AField: TField; const AKeyFields: string = ''): TLookupList; begin AField.LookupDataSet := nil; if (AKeyFields <> EmptyStr) then AField.KeyFields := AKeyFields; Result := Bind(AField); end;

I did and stopped due to: RSP-14723. However applying them via that dialog is inconvenient the better way is to use the 'Configuration Manager': One example is to redirect output or change configuration for an entire project group. I used this a lot for UniDAC's FastReport components to change output directories. Each time new version was made available I would simply run the 'Configuration Manager' using an altered Option Set before compiling.

Well, at least we all learn to enjoy xcopy again.. EMBT where upgrading is a no brainer 🙂

create an action aiOnIdle using the forms caption link it to the form name the update event OnIdle Then use that event as needed, beware the OnIdle event won't fire when a modal dialog is up. Unlike the TActionList.OnUpdate event this one will fire as long as the form is enabled.

Dunno, where is the Minimal, Reproducible Example 🙂 If it works on a Windows 10 Sandbox then the code works, all else is up to AVs and Windows security. I tried to get an API Hooking using AppInit_DLLs example to work but that fails for me even in a Windows 10 Sandbox, works in W7 though.

Some of Hooks-Made-Easy updated and now on GitHub.

Feeling ignored? That code is literally from last century and had no incling about WIN64.. Although I haven't really looked at it your changes is what I needed to change in my code. Which by the way is blocked by Delphi and is NOT a commercial solution. There has been little demand for hooks in my current project so there was no need to even look at it other than as an exercise. Another reason not to get involved here is that I and you can find the solution with very little effort, but system wide hooks in Windows 1984.. err.. 10 are not so reliable. The one place we use a hook that absolutely needs to work madCodeHook is used in a signed Driver (special certificate).

You need DLLs for both.