Anders Melander

Use the standard system dialogs. They will work with any version of Windows and, most importantly, look and function like the users expect them to. For example DevExpress have begun using their own custom dialogs in their skin editor and in their design-time editors and it's just horrible. The dialogs are skinned even though nothing else is, the usability sucks, lots of things just doesn't work and the usual explorer integration that comes for free with a standard system dialog doesn't work properly, etc. etc. Is there any particular reason why you want to use a custom dialog? Based on the visdom of fortune cookies and my magic crystal ball I foresee that your as of yet unknown changes will lead to as of yet unknown challenges. You're welcome.

Thanks. I have not been able to reproduce the problem with your application or its translation project, using the same version of BTM as you - or the newer. I can see from your application that the BB* modules are in fact RCDATA resources containing PNG images. Since I verify the signature of the resource data to determine if it's a Delphi form these should all have been excluded by the resource scanner. On reviewing the code the only way I can see that this problem would occur is if the resources contained data smaller than a dword. Could it be that you updated the project on a UPX compressed (or something like it) application file? I could reproduce the access violation if I opened your modified project (the one with the BB modules) and then updated the project (which correctly marked the BB modules "don't translate") but this doesn't explain how they got introduced in the first place. In any case I have now added an extra check to handle RCDATA smaller than 4 bytes. New version uploaded.

I don't know what output Sisulizer produces but if it works like BTM/ETM/ITE and produces resource modules (i.e. DLLs) then you can use "Tools -> Import application". Otherwise I guess you'll have to export from Sisulizer to TBX, import the TBX to the Translation Memory and then use that to translate the modules.

Those are the standard Delphi Bitmap resources and since I'm only importing RCDATA (Forms) and Strings (resourcestrings) resources, and I'm specifically asking Windows to only return a list of those, the problem is probably some sort of memory corruption. I have not been able to reproduce the problem. If you can mail me your application (zipped) I will try to reproduce with that. If you click on an already focused cell (i.e. a slow double click) then the cell will go into edit mode. Pressing F2 will also do that. The "slow double click" thing is a very annoying DevExpress "feature" and I usually apply a work around to fix it (e.g. I've done that in the main edit grid). It's been reported a million times but they refuse to fix it or even acknowledge that there is a problem. Anyway, I'll apply the work around to the TM form too.

Remove the space between -n and 1. Like so: -n1 or -n:1 I'm using FindCmdLineSwitch(<name>, Value, True, [clstValueAppended]) to fetch the parameters.

Not really. You are just using an older version of the command line tool 🙂 The latest version is 1.3.8198.28909. My guess is that you selected the installation type "Full installation" which doesn't include the command line tool. That's not intuitive so I'll change that. In the meantime just select the command line tool manually in the installer list.

Okay. So in other words: They're available through the UI from 11.1

Huh? Your profile says 10.1 and AFAIK they were introduced in 10.2. Here's what I have on Delphi 11.0 (same with 10.3):

Ah! - and there's even a IMPLICIT_INTEGER_CAST_LOSS to go along with it. Am I correct in observing that that these hasn't been surfaced in the IDE options dialog?

TL;DR Someone has been able to circumvent a protection mechanism which was designed to prevent a particular category of attacks. The internet: The sky is falling! Apple: Pfft. Chill dudes.

@roynielsen2000@gmail.com The nn/nn-NO TMX issue has been resolved. I have not yet done anything with regards to handling Sisulizer's XLIFF files. New version uploaded.

Yes, to a degree. Bar(42) is ambiguous but resolves to byte. An int64 is demoted silently and resolves to Bar(integer). It could at least produce a warning. My point was that I think it's possible to get rid of the ambiguity without breaking everything. IMO a little (compile time) breakage would be okay as long as there's a benefit.

Resolve to the overload that best match the parameter? function Bar(Foo: byte): byte; overload; function Bar(Foo: integer): integer; overload; ... begin var b: byte := 1; var i: integer := 2; Bar(b); // Use Bar(byte) Bar(i); // Use Bar(integer) Bar(byte(3)); // Use Bar(byte) Bar(word(3)); // Promote word to integer and use Bar(integer) Bar(42); // Should probably fail with ambiguity error even though 42 fits in a byte end;

@roynielsen2000@gmail.com I've reproduced the problem with your file. For now you can work around the problem by editing the TMX file and replacing all lang="nn" with lang="nn-NO".

Yes please. I'd like to first reproduce and then verify the solution with your actual data.

Found it. The Windows LCID for nn-NO is LANG_NORWEGIAN,SUBLANG_NORWEGIAN_NYNORSK and for nb-NO it's LANG_NORWEGIAN, SUBLANG_NORWEGIAN_BOKMAL so the LCID considers them two dialects of the same language. I guess I should stop using LCIDs as a the primary identifier for locales.

I think I've found the cause of this. This is actually a "funny" bug. Funny because I've done much of my testing with Norwegian, Bokmål which, it turns out, is one of the only locales that doesn't make the bug obvious. When identifying the languages I first search my locale database for the RFC 4646 language-region code. The RFC 4646 code for Nynorsk is nn-NO and for Bokmål it is nb-NO. If I fail to locate the locale based on the RFC 4646 code then I delete the last part of the RFC 4646 language-region which leaves me with the ISO639-1 language code. I then search for the ISO639-1 code. The ISO639-1 code for Nynorsk is nn and for Bokmål it is nb. There's also a code for the Norsk macro language: no... Since an ISO639-1 code can map to many different locales (e.g. en -> en-US, en-GB, en-AU) I then find the "primary" locale for the language and use that. What can possibly go wrong... Well, the bug is that instead of deleting the last part of the RFC 4646 I deleted the first part so nn-NO becomes NO and the primary locale for NO is nb-NO = Bokmål. I'll fix that but the question is why I failed to find nn-NO in the first place. Hmm. Maybe there's another bug I haven't spotted...

Can you mail me the TMX file (zipped)?

That's certainly one way to do it but since TMX files are meant for translation memory and what you really want to transfer is the actual translations it would be better to use the XLIFF format if you can make that work. Like everything else the OASIS organization has produced the XLIFF format is a bit fragile. The variant I have implemented support for is the one produced by Delphi's ETM export. In Sisulizer export a language to XLIFF. As far as I know it can only export the translations for a single language at a time. In BTM make sure the language being imported is among the target languages. Edit: It seems the importer takes care of this automatically. Import the XLIFF file. Because the XLIFF importer is tailored to handle the XLIFF files produced by ETM it has some some restrictions which may cause it to barf on other sources. For example it requires text strings to be quoted and it doesn't handle text with attributes (encoded in the XLIFF as sub XML-nodes). If it can't handle the XLIFF produced by Sisulizer then you can either try TMX or you can mail me one of the XLIFF files and I can see if I can tweak the importer to handle them. If you do go the TMX way I suggest you start each import with an empty translation memory (just delete/move the TranslationMemory.dat).

You can't - at least not without writing some code to open the icon and select from the images within. Here are some links: https://stackoverflow.com/a/4286601/2249664 https://stackoverflow.com/questions/8112953/how-do-i-load-icons-from-a-resource-without-suffering-from-aliasing An icon is actually a container format which contains several sub-icons, in different sizes and color depths. If you for example load an icon into a TImage then one of the sub-images within will be selected based on a static rule. I believe it will select one of the 32x32 variants and I think it's Windows doing the selection.

tcp/ip works on pretty much everything.

Here you go. Version 1.3.8185.25123: https://bitbucket.org/anders_melander/better-translation-manager/downloads/

my kbd just died so im typing w the on-screen kbd :-( I'll get on it when that's resolved

Yes, that was a bug. I've just pushed a fix. Do you need me to upload a new build or can make one yourself? P.S. Say hi to Arne for me.

Umm... You mean to say you haven't profiled it?