Anders Melander

Yes, probably. There are plenty of workarounds but that wasn't really the point.

The famous Quick Fix™ technique - Sponsored by Intel and your local power company.

Please read the documentation. I have never used or even heard of sonarqube but it took me less than 2 minutes to find the information: https://docs.sonarqube.org/latest/analyzing-source-code/test-coverage/overview/ https://docs.sonarqube.org/latest/analyzing-source-code/test-coverage/generic-test-data/

Not if FunctionReturningInterface returns an IBar interface or anything other than IFoo. The actual code is an object factory where I pass an interface ID (i.e. a GUID) to a method and get an instance that implements that interface back. Something like this: var MyDialog := DialogManager.CreateDialog(IMyDialog) as IMyDialog; // CreateDialog returns an IInterface MyDialog.Execute; DialogManager itself is also an interface so I can't use generics on it. If it had been an object then I could have done like this instead: var MyDialog := DialogManager.CreateDialog<IMyDialog>; // CreateDialog returns an IMyDialog MyDialog.Execute;

Delphi doesn't appear to be supported by sonarqube: https://docs.sonarqube.org/latest/analyzing-source-code/languages/overview/ ...and as far as I can tell sonarqube doesn't generate the coverage data itself but relies on coverage data supplied by other tools.

Not quite fixed it seems 😞 Casting a function result with the interface as operator and the old behavior is back. Reproduced with Delphi 11.2. This works: begin var Foo := FunctionReturningInterface; // RefCount = 1 Foo := nil; // RefCount = 0 ... end; but this doesn't: begin var Foo := FunctionReturningInterface as IFoo; // RefCount = 2 Foo := nil; // RefCount = 1 ... end; // RefCount = 0 Workaround: begin var Foo: IFoo; begin var := TempFoo := FunctionReturningInterface; // RefCount = 1 Foo := TempFoo as IFoo; // RefCount = 2 end; // RefCount = 1 Foo := nil; // RefCount = 0 ... end; or function FooFunc: IFoo; begin Result := FunctionReturningInterface as IFoo; // RefCount = 2 end; // RefCount = 1 begin var Foo := FooFunc; // RefCount = 1 Foo := nil; // RefCount = 0 ... end;

Well, it's just pseudo code that happens to look a lot like Delphi code 🙂 . In my defense, I think it actually works as I intended; It will return a match within the tolerance but it might not return the closest match.

You're right. I tried to come up with a trivial example - and failed. Anyway, you get the point.

So how would you compare floats with tolerance? function BinarySearch(const List: TArray<Double>; Value: Double; Tolerance: Double): integer; begin var Lo := 0; var Hi := High(List); while (Lo ≤ Hi) do begin var Mid := (Lo + Hi) div 2; if SameValue(List[Mid], Value, Tolerance) then exit(Mid); if List[Mid] < Value then Lo := Mid+1 else Hi := Mid-1; end; Result := -1; end;

Okay, so there's basically nothing wrong with the functions. Thanks.

Why? What's wrong with them?

How is that relevant?

I can't see why it's "better", it's certainly more complicated, but yes that's also an alternative. AFAIR resources are mapped into the process virtual address space so that will have to be taken into consideration. I'm not sure you can sign an exe that has had data appended and even if you can you risk that the signature data is added after the data you appended thus breaking the extraction scheme.

Okay then, assuming your exe isn't signed you can try this: At build time (after the exe and language modules have been built): Zip your language modules into a single file. Append the zip to the end of the exe file. Append a int64 containing the original size of the zip to the end of the exe file. You will need to make a tool that does the above. It shouldn't be too hard. At run time: Open a TFileStream on the exe and read the int64 from the end of the exe. This gives you the position of the zip inside the exe. Seek the stream to the position of the zip. Open a TZipFile on the stream and extract the files to disk. If your exe is signed you will need to use a different approach. See https://blog.barthe.ph/2009/02/22/change-signed-executable/ See also: https://stackoverflow.com/questions/5795446/appending-data-to-an-exe

It completely depends on how you want it to look. Show us a mockup of how you imagined it should look and then we can help you.

Potential chicken-egg problem: The translation is based on the exe file. The language module is based on the translation + exe. In order to get the language module linked into the resources of the exe, the exe must be compiled with it. Of course this isn't impossible in any way, and you can even make a tool that adds the file to the exe's existing resources, but then there's the next problem: The resource modules must be extracted from the exe before the exe loads the resource module, which by default happens in the initialization section of system or sysutils, I forget which. All in all, I'd say it's probably easier and more robust to solve the original problem instead of all these workarounds.

But how?

It's been a while but I thought all your customers were using remote desktop against servers hosted and managed centrally by you. Regardless, I guess a self-extracting exe could be used. For example a simple zip self-extractor or even an Inno Setup installer with no GUI. However if your problem is file locking (presumably because the files are in use), I can't see that you won't still have the same problem; If the files are locked the extraction will not be able to replace them. I think it would be better to concentrate on solving the deployment problem instead of working around it.

The DevExpress support groups would be a good place to search for/ask this question. https://supportcenter.devexpress.com/ticket/details/t545652/error-editing-protected-spreadsheet https://supportcenter.devexpress.com/ticket/details/t745921/what-is-the-best-way-for-have-a-spreadsheet-in-readonly-mode FWIW, I think the response given by DevExpress is BS; IMO using an exception to display a message to the end user is an extremely poor solution. This behavior should at least be optional - But good luck getting them to change it.

Read the documentation. Search for FireDAC offline

In principle, all FireDAC datasets are memory datasets. TFDMemTable is just a FireDAC dataset with no database connection. FireDAC supports both "offline mode" and cached updates, so there's really no need to use TClientDataSet in this case. However, it sounds as if the OP really just needs to set up the TFDQuery to fetch all data and then close the DB cursor. Something like this: Query.FetchOptions.Mode := fmAll; Query.FetchOptions.AutoClose := True;

It's a hack. Go for the pragmatic solution instead; It's easier to maintain. For something as simple as this it's simply not worth it to use an obscure hack that requires a 20 line comment explaining to your future self what the hell is going on and why it was necessary.

When, in a few years, you or someone else comes across that code, "interesting" will not be the word used to describe it.

Doesn't Search, Find in files do the same thing? My guess is that it's using the same engine as the broken-beyond-repair refactoring tools (which afaik is implemented in J#, LOL)... It's incredible that they didn't remove this turd of a feature many, many, many years ago. https://docwiki.embarcadero.com/RADStudio/Sydney/en/Refactoring_Code ROTFL

It's built right into the IDE. The only problem is that it seldom works 😞 [Edit: This is what @Pat Foley wrote about] Right-Click and select Search for usages... or right-click and select Find, Find local references to...