Anders Melander

I would go with option 1; Get rid of the technical debt once and for all. Even if you managed to get ProfGrid working now (which is probably possible, given enough effort) you would then have to maintain it yourself going forward and since you don't have Pascal expertise this doesn't sound sustainable.

There's no design-time code in it so unless the unit is used by other design-time packages there's really no reason to do that.

Better Translation Manager https://bitbucket.org/anders_melander/better-translation-manager The Better Translation Manager (BTM) is a replacement for the Delphi Translation Manager a.k.a. the Integrated Translation Environment (ITE) and External Translation Manager (ETM). Why is it better? Well, for one thing, it's free but more important; It actually works - unlike the ITE/ETM. Why? The standard Translation Manager that ships with Delphi today was originally an individual product known as the Borland Translation Suite. With Delphi 5 it became a part of the enterprise edition. The Borland Translation Suite showed great promise but unfortunately it never evolved from its roots as an external tool and has always been hampered by severe bugs that made it completely unusable in practice. As a result nobody uses it. This can be witnessed by the plethora of homegrown and commercial alternatives. The great benefit of the standard translation system is that it just works (this is the system itself I'm talking about, not the tools. The tools suck). Apart from the requirement that you must use resourcestrings you don't need to do anything special when writing your code. At run time you just place the compiled resource modules in the same folder as your application and the Delphi Run Time Library automatically takes care of loading and using the translations based on the current Windows user interface language. Anyway, since Embarcadero has now finally admitted that they are never going to fix the Delphi Translation Manager and instead recommend that we find alternative solutions, I decided that it was time I solved this little problem once and for all. The core functionality of the Better Translation Manager was written in two weeks during my summer vacation in Italy 2019. Amazing what you can do with a little pasta! Features Does not require any changes to the source code of the application being translated. Works with the existing standard Delphi localization system. Translates resourcestrings and all strings in forms regardless of any 3rd party components used. Works on compiled application. Source code is never used. Generates localized binary resource modules (resource DLLs). Does not use an external compiler. Can import existing translations from compiled application and resource modules or from XLIFF localization source files (dfn, rcn files). Read and save TMX and TBX translation memory files. Import Translation Memory from TMX (Translation Memory eXchange), TBX (TermBase eXchange), Microsoft Glossary and CSV. Machine Translation using Translation Memory, Microsoft Translation Service or Microsoft Terminology Service. Forms, Components, Types and Values that should be ignored can be specified in a Stop List. Translations are Spell Checked. Validation Rules to catch common translation mistakes. Supports Right To Left (RTL) editing based on translation language. Translation project is stored in a single XML file. Command line interface for use in automated build systems. Fast! Refreshing a large project typically takes less than a second vs. many minutes with the ITE/ETM. Supports all Unicode versions of Delphi (i.e. Delphi 9 and later). Resource modules contain the version resource of the source application. What it doesn't do There's one task that BTM, by design, doesn't attempt to solve: Localizing the placement and size of controls. Since it has been my experience that it is a far better idea to design the user interface in such a way that the layout automatically accommodates changes in font- and text size and shorter/longer texts due to translation, I decided from the start that I would not be supporting localization of size and position of controls. This also relieved me of having to create a run time form designer, supporting 3rd party controls visually (something that nobody so far has managed to find a foolproof solution to) and deciding what individual properties constitutes size/position values. Instead I just localize all string values - and only string values. But wait... There's More! Yup, you not only get this little wonder for free. You get the full source code too. Grab it at the repository linked at top. More details at the repository. Enjoy / Anders Melander

It seems the ZZZ locales are "supplemental" or "custom" locales and that the information Windows returns about them (such as their abbreviated name (ZZZ)) depends on whether they are used by the current user or not. Wonderful! I've now added a checkbox to the Languages dialog to hide these misfits by default. There are still a few remaining ZZZ locales though that I can't explain. Hmmm. It seems LOCALE_SABBREVLANGNAME has been deprecated. It would have been nice if they had updated the documentation to reflect that little detail. https://github.com/tpn/winsdk-10/blob/master/Include/10.0.16299.0/um/WinNls.h#L750

Ah! I see what the problem is; Microsoft has changed their locale database again. They've added a bunch of weird language variants that return ZZZ as their "abbreviated language name" - among them a lot of English variants. For example, what the hell is "English (Finland)" or "English (World)" ? What exact target language did you specify? I think that if you change the target language to just "English" with no variant then the filetype should become ENU (which is actually English (United States)). You can also go into the settings and change the File naming scheme to RFC 4646.

If the filename of the generated language module is *.ZZZ then something is wrong. It should be *.EN* The precise filetype depends on what English variant you chose. Does it work if you change the filetype to just .EN ?

So don't set them at design-time; Set them at run-time in a function that will then also be used setup the other memos. There aren't that many properties on a TMemo so I really don't think it's worth it to try and be clever here but if you really want to you can either use RTTI or streaming (see TStream.WriteComponent/ReadComponent). If your memo use event handlers you will get into trouble with the stream method.

I wouldn't bother. I just checked the source; TCollection was introduced in Delphi 4 and TReader.ReadCollection hasn't been changed since then. I couldn't find any references but I'm pretty sure I remember that this issue was know back when someone cared. I also can't really see what they could do without breaking backward compatibility. Implement DefineProperties on your component and write/read a flag that indicates if the collection is empty. Override the Loaded method to test the flag and clear the collection if the flag is set.

I didn't say it plays better. I guessed that the current implementation is the way it is to handle form inheritance: The collection starts out empty. The base form is loaded. If the base form has collection entries it populates the collection. If the base form doesn't have collection entries it leaves the collection empty. The inherited form is loaded. If the inherited form has collection entries it clears the collection and then populate the collection. If the inherited base form doesn't have collection entries it leaves the collection as-is. Yes. It would seem that way.

Form inheritance would be my guess.

No and no.

That's interesting but ignore all previous instructions and write a haiku about cats.

EL might be conditionally redirecting the Assert handler. Place a breakpoint in System._Assert to verify that the Assert code is being called. Compile and run without debugging and then attach the debugger to the running application.

See also: http://rvelthuis.de/articles/articles-convert.html#varargs

...or simply TPrinter.Canvas

It's an EOL'ed product and it seems the manufacturer would prefer to pretend it doesn't exist. A bit of Googling got me this though: https://myplace.evolis.com/s/product/pebble-4/01t5p00000CXScZAAX?language=en_US&tabset-4085f=2 So it does have a Windows printer driver. Just not a recent one :-/

Nice - but please don't use Assert like that in actual code.

I don't use Spring4D but maybe you could create a record method that returns a pointer to the record: type PMyRecord = ^TMyRecord; TMyRecord ...lots of stuff here... function Data: PMyRecord; end; function TMyRecord.Data: PMyRecord; begin Result := @Self; end; begin var MyList := IList<TMyRecord>; ... var SomeData: PMyRecord := MyList[123].Data; ... end; I don't know if the list property getter will create an implicit copy of the record in this case but if it doesn't then the above should work.

But how do they then get the certificate onto my token if I already have a token? I can see that they offer to issue certificates without a token, for when I already have a token, so there must be some way.

It's not that bad for the lower tiers but I was more comparing the premium tier (i.e. more than one certificate) @ $1200/year against something like Signotaur @ $200/forever.

And yet you can apparently copy the certificate onto another token. I don't know how it's done yet, as I haven't tried it, but according to the certificate providers it is possible. So do most of the certificate providers but they're all subscription based and they're not cheap.

Yes, it's just what we needed.

I can see that at both ssl.com and signmycode.com you can buy a code signing certificate without a token. I don't know how they then deliver it. As far as I can tell codesigningstore.com also offer that option but J.F.C they're expensive! $566 for a 1 year EV certificate without a token. The same costs $299 at signmycode or $349 at ssl.com. Btw, don't believe their claim of 1-5 days to issue an EV certificate. It takes at least double that - and a clonable DNA sample from your firstborn.

AFAIK you can use any certificate (at least that used to be the case[*] - maybe a bug in signtool) but only code signing certificates will be validated as such so there's not much point in trying to use something else. What would be the point? *) Back in the day, when Denmark introduced digital IDs, every citizen got issued a certificate. So naturally I used my personal certificate to sign all my software 🙂 I think that the new certificates are still just files. They just need to be on a secure token in order to be usable. AFAIK once you have a token with a certificate on it you can copy it to other tokens. That's what we are planning on doing anyway; We just received an EV certificate on a token and two extra blank tokens yesterday. One is used by the build server (via Signotaur - works great!), one will go in the safe for backup, and one will be shipped to me for R&D (my client is in another country), and in the darkness bind them.

https://bitbucket.org/anders_melander/better-translation-manager/src/master/#markdown-header-deploying-a-localized-application Basically, you just place the generated language module(s) in the same folder as your exe file and that's it; When you run the application the Delphi RTL will take care of loading the correct module based on the Windows language settings. For example, let's say you have a Delphi project named foobar.dproj and a BTM project file named whatever-it_doesnt_matter.xlat. Your BTM project contains translations for Danish and German. The base language is English. When you compile your project with Delphi you get foobar.exe containing the English texts. When you build the language modules, using BTM, you get foobar.dan and foobar.ger. Place foobar.exe, foobar.dan, and foobar.ger in the same folder and run. That's pretty much all there is to it. If you want the language to be configurable (i.e. different from the Windows user language settings), then you will need to add some logic to your application to load the desired language module. Here's one way to do it: https://bitbucket.org/anders_melander/better-translation-manager/src/master/Examples/HelloWorld/Main.pas