Leaderboard

Yes, PAServer is needed to pull the necessary tools and libs from the target Linux machine. After this stage it is needed for deployment/debugging (but the Linux debugging in Delphi is a joke, simple WriteLn's in code can do better...) The best documentation I've seen so far is here: http://docwiki.embarcadero.com/RADStudio/Rio/en/Linux_Application_Development and here: https://chapmanworld.com/2016/12/29/configure-delphi-and-redhat-or-ubuntu-for-linux-development/

You were asking for options, and if the signatures are well defined and limited thats a possible option too. So that meant you could use overloads for the most common ones. E.g. I try use mostly compatible signatures, also for different domains in my projects. The array of const can catch then all the rest.

function VarToStr(const VarRec: TVarRec): string; begin Result := ''; // compiler happy case VarRec.VType of vtInteger: Result := IntToStr(VarRec.VInteger); vtInt64: Result := IntToStr(VarRec.VInt64^); vtString: Result := string(VarRec.VString^); vtPChar: Result := string(VarRec.VPChar); vtPWideChar: Result := string(VarRec.VPWideChar); vtAnsiString: Result := string(AnsiString(VarRec.VAnsiString)); vtWideString: Result := string(WideString(VarRec.VWideString)); vtUnicodeString: Result := string(VarRec.VUnicodeString); vtChar: Result := Char(VarRec.VChar); vtWideChar: Result := VarRec.VWideChar; end; end; end; Something like what you need. Extracted from bigger function and edited in browser so bugs are possible

For files, you can use something like this: [Files] Source: "TestFile.jpg"; DestDir: {code:MyDestDir}; Flags: replacesameversion [Code] function MyDestDir(Dummy: string): string; begin if WizardIsComponentSelected('PortableComponent') then result:=ExpandConstant('{app}')+'\A' else result:=ExpandConstant('{app}')+'\B'; end; Icons - I would base them on Components, so create a component, which is enabled just for Normal type, and assign all icons to this type.

Something like this? [Setup] Uninstallable=not WizardIsComponentSelected('PortableComponent') [Types] Name: normal; Description: "Normal setup" Name: portable; Description: "Portable" [Components] Name: "Main"; Description: "Test files" Name: "PortableComponent"; Description: "Portable"; Types: portable [Files] Source: "TestFile.jpg"; DestDir: "{app}"; Flags: replacesameversion

It depends on how lBroadcaster's OnReceive callback is implemented. If that event is called in the context of the "inside thread", then yes - this locking is necessary and it is correctly implemented.

Sorry, I read that wrong. I though the ones in red were the free ones. I was talking about parsing the Google SERPs, not using the API. From some research I've done, the API does return "search results", but it's a subset of what you see when you run a query, and may be subject to variations based on data you may or may not have, like LAT+LON location info (ie, what does "near me" mean? an IP-based location can be far away from where you really are). I haven't actually played with the API yet, just basing this on numerous comments and complaints I found around the internet. Like the map often found at the top of the page with the top-3 locations on it ... that's apparently "derived", along with all of the sponsored ads and other stuff. How exactly they come up with those three selections is anybody's guess. Some people care about that, some don't. (That's something I was specifically looking to identify.) IOW, there's both "primary" and "derived" data displayed on SERPs you get back from Google. From what I could determine, the API only gives you the "primary" data, which is fine for most needs. And the API can get rather expensive in some circumstances.