Anders Melander

Without knowing anything about your architecture I would say that you need to move the content of each of the tabs into individual frames and then create and destroy these frames on-demand.

I don't know but I think in this case it has more to do with limiting the deployment size than with limiting the consumed address space.

I think you'll have to debug a bit then. Set a breakpoint on the call to TextToShortcut and trace into it to see what's going wrong.

Thanks. That must be the abbreviation of "Steuerung" I guess. Makes sense. The translated RTL resource strings are also available in the ITE translation memory and that is installed regardless of Delphi's language.

I think I'll put that on a t-shirt: "Hope - Helping Delphi survive since 1996"

You need to translate the sShortcutCopy text in BTM to German and the translated text should use the German key names. I don't know what those are. The key shortcut names are defined in Vcl.Consts: SmkcBkSp = 'BkSp'; SmkcTab = 'Tab'; SmkcEsc = 'Esc'; SmkcEnter = 'Enter'; SmkcSpace = 'Space'; SmkcPgUp = 'PgUp'; SmkcPgDn = 'PgDn'; SmkcEnd = 'End'; SmkcHome = 'Home'; SmkcLeft = 'Left'; SmkcUp = 'Up'; SmkcRight = 'Right'; SmkcDown = 'Down'; SmkcIns = 'Ins'; SmkcDel = 'Del'; SmkcShift = 'Shift+'; SmkcCtrl = 'Ctrl+'; SmkcAlt = 'Alt+'; I.e. find out what SmkcCtrl is translated to in German.

I'm not sure what that is supposed to do (I don't read German that good). If the purpose is to translate the texts returned by TextToShortcut then it is unnecessary since the texts are already resourcestrings.

You need to swap the order of FixMenuShortcuts and SwitchSoftwareLanguage...

What's the point? The arguments would still be evaluated up front. You need the cooperation of the compiler to avoid that.

BTM only translates strings and shortcuts are stored in the DFM as integer values. It's really not good practice to translate the shortcuts anyway. For example the user would expect Copy to be Ctrl+C regardless of the language. Instead you can translate the accelerator keys since these are part of the menu text. E.g. &Copy -> Copy = &Kopieren -> Kopieren If you really want to translate the shortcuts, and have BTM handle translation of them, then I'm afraid you'll have to store them in text format as resourcestrings and then use TextToShortCut to convert the text to a shortcut at run time: resourcestring sShortcutCopy = 'Ctrl+C'; begin MenuCopy.ShortCut := TextToShortCut(sShortcutCopy); end;

Yes, I understood that. My point is that searching for this pattern, which is a perfectly normal and valid pattern, would be premature optimization. If there is a performance problem in an application then you analyze the application (for example with a profiler) and locate the hot spots. It is then then easy to identify this pattern in those hot spots just by reading the code. You don't need a tool for that. It's like having a tool for identifying loops because loops are slower than no loops.

"Time limited license"... Thanks, but let's not. Also it seems they've opted to keep the map file info separate from the application. I guess that makes sense on mobile due to the size. Not so much on desktop.

It's not that hard to spot. Why would we need a tool for that?

I usually wait until after my morning coffee. Very good point. Few people enjoy watching paint dry - unless it's body paint I have "solved" quite a few performance problems simply by adding a splash screen and/or a progress bars.

Well, you shouldn't really be solving that by giving the application full access to everything - but that's a different issue.

On Windows you can use an exception logger such as MadExcept or Eurekalog. I don't know of any solutions for maxOS.

I have no idea about what that is. You cannot drag between applications running with different elevated privileges (e.g. run as administrator) so make sure that you aren't running Delphi elevated - or disable UAC.

There's no difference between ITE and BTM in that regard. They use the exact same RTL mechanism. Ie. the BTM and ITE resource modules are identical. It's only the localization editor/manager/compiler that's different. I believe LoadNewResourceModule used to be in the RichEdit example (no longer included with Delphi but you can find it on the net). Instead you can use LoadResourceModule, in the system unit, or my version of LoadNewResourceModule, in the amLocale unit of the BTM source.

Thanks. Please read the last part of the answer for info on controlling the active language: ...But be aware that once a form has been created (and thus the DFM loaded from the resource module) you will need to either recreate the form or reload it from the DFM resource (not recommended) in order for it to use the new language.

I believe you're thinking of the pfInKey value of TField.ProviderFlags. <rant>I know the help has improved but why the hell isn't there a link in the help from the ProviderFlags property to the type of the property. Don't they have computers that can do this stuff for them?</rant>

What do you mean? Can you rephrase the question, please.

That's a very short sighted attitude. Technical debt accumulates and your memory will not get better with age, or so I've heard

No I don't think so. You've just made your code more complex and harder to maintain and gained almost nothing.

Define "well" I'm pretty sure it can easily beat me. https://www.chessprogramming.org/Nero

There isn't really a "primary key" index on a TFDMemTable. You can have multiple indices on a table and one of them can be the "current index". http://docwiki.embarcadero.com/Libraries/Sydney/en/FireDAC.Comp.DataSet.TFDDataSet.Indexes I guess you can specify the soPrimary option on an index but I'm not sure if there's any practical difference from the soUnique option. http://docwiki.embarcadero.com/Libraries/Sydney/en/FireDAC.Comp.DataSet.TFDIndex.Options