Anders Melander

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...

...or without the temporary buffer: function ComputerName: string; begin var Size: Cardinal := 0; if (not GetComputerName(PChar(Result), Size)) and (GetLastError <> ERROR_BUFFER_OVERFLOW) then RaiseLastOSError; SetLength(Result, Size-1); if (not GetComputerName(PChar(Result), Size)) then RaiseLastOSError; end;

It's unavoidable. For instance if a resourcestring is deleted then the whole range of IDs above it must change their ID. With regard to Windows resources I don't think ordinal resource IDs (not just string IDs) were ever meant to be stable. Instead we were supposed to use .rc and .h files and symbolic names - which is basically what the drc file is.

Good point. Luckily it's just the numeric ID values that change and these values aren't even guaranteed to be stable across compiles within the same platform. This is why BTM (and I'm guessing Soluling too) use the resourcestring names instead of the ID values to identify the strings. The DRC file contains the mapping between name and ID value and this file is used when scanning the source application and when building the resource module DLL. So in order to build a resource module for a particular platform, you just point the build tool to the exe and drc of that platform and you will get a resource module that matches them.

Thanks for the kind words. Much appreciated. Yes, I made a conscious choice not to include any kind of form editor or preview, even though I have these features implemented locally, simply because they never work reliably. The main problem is that in case your forms contains 3rd party controls, then the viewer/editor will need to be able to load the runtime packages containing these controls, and the packages have to be the correct version, for the correct version of Delphi. etc. etc. It's a nightmare. For in-house translation, I think I came up with a better solution to providing context. With a few lines of code one can have BTM follow the focus of the target application. Start the target application, open a form in the application and BTM will automatically select the corresponding module. Click a control in the application and BTM will select the properties of that control. Of course with external translators providing the application, and all the dependencies it might have, might not be feasible (it isn't in our case). In that case a simple screenshot should do it. No need for that. The language modules, as @aehimself said, are just empty resource DLLs with no code. The same DLL stub is used for 32- and 64-bit. Sure there is; It's called a Stop List. You can configure properties or modules to ignore based on a plethora of different rules - or regex if everything else fails. Validation is performed live. In addition, you can validate the whole project via the ribbon: BTM validates a host of different properties such as leading and trailing space/colons/whatnot, delimiters, shortcuts, case (and type of casing), etc. etc. Many validation violations can be resolved automatically. Some are too risky to try and do automatically. I don't know what you mean by "interactive TM/MT/terms". If you mean automatic translation lookup and prompt, then BTM does that too. The UI sucks a bit though. Yes, these are Windows common controls and unfortunately, the VCL developers chose to persist them using their internal binary (and undocumented) stream format. If you look at the DFM file of a form containing one of these controls you will see what I mean. I guess I could write adapters specifically for these controls but so far I haven't had any requests for them.

Ditto. And ditto on your options. Before trying to solve this problem you should determine where your bottleneck is instead of guessing. Is it the DB server, the network, the middleware (FireDAC), or your own code? Examine the CPU, network usage, and DB server (using the activity monitor) during execution. Who's waiting on what? Profile your application or, if you don't know how to do that, just repeatedly pause your application in the debugger and examine the call stack. Chances are that the bottleneck will be somewhere in the call stack. It's a poor man's sampling profiler.

You might not have started anything manually but there are always programs running in the background. This isn't DOS after all. I would suggest you run a virus scanner on that system ASAP. My guess is that "something" has hooked into the clipboard chain and is corrupting the clipboard. If the list contains CF_UNICODETEXT then it should also contain CF_TEXT because the clipboard internally synthesizes between the two formats automatically. It is impossible to only have one of them on the clipboard.

I would start by examining what it is you put onto the clipboard. You can use a simple clipboard viewer for this but it needs to be able to display the data as hex to be of much use. The Drag and Drop Component Suite has a Drop Source Analyzer application that can do it. If you're brave you can use the one I have attached. SourceAnalyzer.zip

https://bitbucket.org/anders_melander/better-translation-manager/src/master/Source/amProgress.API.pas and another, slightly older, version of the same: https://bitbucket.org/anders_melander/dwscriptstudio/src/master/Source/amProgress.pas and even a DWScript wrapper (the second & third screenshots are actually from a DWScript): https://bitbucket.org/anders_melander/dwscriptstudio/src/master/Source/ScriptRTL/amScriptModuleUserInterfaceProgress.pas Displays a non-modal form with a progress bar, a status message, and an optional cancel button. Defer the initial display of the progress form (what you call lazy loading). Default delay is 500 mS. Limit rate of progress update to minimize UI overhead. Default is max 1 update per 100 mS. Selectively pumps message queue to avoid application freeze and enable user to move/cancel progress dialog during use. Progressive or marquee mode. The current implementation uses DevExpress label and button controls but these can just be replaced with regular VCL controls without any loss of functionality. Usage: var Progress := ShowProgress('Hello world', False); Progress.EnableAbort := True; Progress.Progress(psBegin, 0, 100, 'Charging flux capacitor...'); for var i := 0 to 100 do begin Sleep(100); Progress.AdvanceProgress; end; and in Marquee mode: var Progress := ShowProgress('Hello world', False); Progress.EnableAbort := True; Progress.Marquee := True; Progress.UpdateMessage('Charging flux capacitor...'); while (not Progress.Aborted) do begin Sleep(100); Progress.AdvanceProgress; end;

Thanks very much. Works in Delphi 11.0 too it seems. This was driving me absolutely crazy because I was so sure that it wasn't a problem anymore but I just couldn't get it working. Some of my projects are in Delphi 10.3 and some are in 11.0 so that explains the confusion. I'll bet that in a year or so I will be in this situation again but at least there's a chance I will find this thread then 🙂

Run the application in the debugger and when the dialog appears, pause the application in the debugger. You should then be able to examine the call stack in order to determine exactly where in the code the dialog is shown.

Sorry to hijack the topic but: Wow! I had completely forgotten about that gem of a library. There's a Double version to ease the transition: damath.pas Can someone explain the following from the readme for me: Why aren't they correctly rounded? I ask because it's an optimization technique I use a lot.

Fair enough; Then state that these platforms requires Windows 10.