Anders Melander

Some of the code I'm currently maintaining ironically has widespread use of dynamic arrays of very large records. Ironically because it was done to avoid the overhead of lists of objects in order to improve performance. Instead it now struggles with the overhead of dynamic array reallocation and records being copied back and forth. I'm slowly refactoring it to use lists and objects but meanwhile I'm using the approach you're suggesting (minus the copy/paste bug 🙂), so this: type THumongousRec = record Foo: integer; ... end; THugeArray = array of THumongousRec; TMyClass = class private FData: THugeArray; protected function GetData(Index: integer): THumongousRec; procedure SetData(Index: integer; const Value: THumongousRec); public property Data[Index: integer]: THumongousRec read GetData write SetData; end; function TMyClass.GetData(Index: integer): THumongousRec; begin Result := FData[Index]; end; procedure TMyClassSetData(Index: integer; const Value: THumongousRec); begin FData[Index] := Value; end; begin var Data := MyClass.Data[0]; Data.Foo := 1; MyClass.Data[0] := Data; end; becomes this: type THumongousRec = record Foo: integer; ... end; PHumongousRec = ^THumongousRec; THugeArray = array of THumongousRec; TMyClass = class private ...same as before... protected ...same as before... function GetPData(Index: integer): PHumongousRec; public ...same as before... property PData[Index: integer]: PHumongousRec read GetPData; end; function TMyClass.GetPData(Index: integer): PHumongousRec; begin Result := @FData[Index]; end; begin MyClass.PData[0].Foo := 1; end; Of course this only works when the property setter doesn't have side effects.

True, if you have to implement an interface declared by someone else - but since you don't have to actually declare the property in your implementation there's zero difference from your perspective between an interface with and one without property declarations. Anyway, to each their own, free world and all. IMO both approaches are just fine.

Nope: type IFoo = interface function GetBar: IBar; procedure SetBar(const Value: IBar); property Bar: IBar read GetBar write SetBar; end; TFoo = class(..., IFoo) private function GetBar: IBar; procedure SetBar(const Value: IBar); // Look ma, No property! end; begin var Foo: IFoo := TFoo.Create; var Bar := Foo.Bar; end; Sure, but I don't see the problem; Don't use them if you don't like them. You will still need the getters and setters so there's not much saved by omitting the property declaration and you lose the meta information that the property communicates. I too would wish the the getters and setters could be hidden from the public API of the interface (like I wish that the private part could be hidden from class declarations) but I guess that we have their history (as COM interfaces) to thank for that. Since I need both COM and non-COM interfaces and a new breed of interfaces would just be a mess I can live with the annoyances the versatility brings with it.

Sure - And the quality of soft- and hardware from behind the Iron Curtain reflected that fact. Let's say, for the sake of argument, that you represented a professional western software company. Would you accept a dependency on a library such as DevExpress (which is far from cheap), knowing that it was produced using pirated tools on a pirated OS, by developers which may or may not have your best interests in mind? I would not. Apart from the moral and business aspects there's also one of security. I know a few Russian developers which I fully trust because I know them both professionally and socially but from what I've heard from them I can't assume that all modern, educated Russians are like that. Some of their former colleagues would be happy to see the west go up in flames.

Since Russia no longer has (legal) access to moderne computer technology I wouldn't expect much - for the next decade or so.

So use a function instead but I can't see how that would improve anything for you. A property better expresses the intent. For interfaces properties are purely syntactic sugar so you really don't have to use them if you prefer not to. You can just call the getters or setters directly. How is that a pain?

Bold statement, given the fact that they were one of the language features, if not the feature, that made Delphi possible in the first place. If you need to pass them as var or out parameters then I would say that there's something wrong with your design but without a concrete example it's hard to say what. Code completion: Ditto. If you need to modify a property, which isn't writable, then there's something wrong with your design or with the class design. Many other languages doesn't have objects, interfaces, exception handling, etc. Pretty irrelevant.

Nice. I believe you can just use the FindDragTarget VCL function to find the control under the cursor. The current algorithm looks for an exact match on the control name and then iterates backward (i.e. negative row index increment) from the least property until it finds a visible property. It does not consider the Status of the property since it doesn't know what you're doing or why you want to select the item. I'd like to keep it that way. If you filter the Status column to exclude "Don't translate" then these properties will not be selected and it will behave like you want. Since you're not interested in the "Don't translate" items anyway there's no point in displaying them.

@KHJ Fixed and new version uploaded. Thanks for the patience.

Ah... That was the missing piece. Reproduced!

I'm stumped. I don't believe the EXE-file is the problem because I can't reproduce with the one you sent me. Which version of Windows are you on? I know which change probably caused this. Previously, after the resource scan, I discarded modules (i.e. forms) that had no translatable items (i.e. components/properties). Now I keep them. However that doesn't explain why the modules aren't being discarded during the resource scan since they are not DFM resources. The first thing I do when I examine a RCDATA resource item is to check if the resource starts with "TPF0" which is the binary DFM signature. If the signature isn't present then the module type is set to "other" and the module is discarded. If I load your project, containing the BB modules, and then do an update the BB modules are immediately marked as missing since BTM considers these modules as not being present in the EXE (which is correct).

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