Leaderboard

@Lars Fosdal Serializing Objects with TJson and Serializing Generic Object Lists with TJson

If you want your beta testers to find bugs, don't you want lots of testers?

You can try to do: FDUpdateSQL1.Commands[arInsert].CommandKind := skSelect;

Just select @SysUserId as YourAutoIncFieldName

The shown approach has some drawbacks, one being that it only works with aliases of TObjectList<T>, not for derived classes. While this was no problem in the my case, it bugged me a bit as I see classes derived from TObjectList<T> probably as a not so uncommon use case. Unfortunately the current implementation is a bit resistent against extensions, f.i. because methods are not virtual or instances are created directly instead of using some factory approach. Thus the possible solutions are a bit limited and not as developer friendly as expected. On the other hand, this may change in the future and if we can get an TObjectList<T> approach working now, it probably can be made more friendly in the future.

Thanks everyone, I'll add IDN support to TWSocket.DnsLookup and TWSocket.ReverseDnsLookup which fortunately have string arguments. I'll set-up a sub-domain with accents for testing. Then think about email. If anyone has any real IDN URLs they would be useful for testing. Angus

You can dispute it then.

I even found a simpler solution and am going to publish a blog post about that soon.

AppMethod ? Possible, according to Jeroen's list it existed until Delphi 10, so it might have used ProjectVersion 17.3. But I found that JEDI uses that version in the packages for all Delphi versions >XE8, so even if I assume AppMethod, it would still be wrong. (Background: See my blog post on dzBdsLauncher)

@Georgge Bakh Traditions...

I hope there will be something that justifies such a secrecy.

google found this on the first place: https://templates.machinezoo.com/ansi378-2004 first 26+ bytes are "ANSI INCITS 378-2004 template", don't ask me what is it, but this lead to this site: https://www.nist.gov/itl/iad/image-group/resources/incits-standardized-biometric-data and this dl link "INCITS 378 index finger minutiae templates - 233K. Last updated Oct 3 13:24" where are .frmpiv files in it, which contain 0000000050: 00 00 00 00 00 00 00 00 │ 46 4D 52 00 20 32 30 00 FMR 20 0000000060: 04 40 FF FF FF FF 80 01 │ 01 D0 02 20 00 C5 00 C5 @ÿÿÿÿ€Ð Å Å there is your header magic, 46 4D 52 = FMR

But again belated. Start of beta in april for a product being addressed for release "early 2020"

Not sure if this works for you, but at least it works for me with 10.3.3. Let's start with a TJSONInterceptor descendant for a generic TObjectList<T>. Note that <T> represents the type of a list item, not the type of the list itself. type TObjectListInterceptor<T: class> = class(TJSONInterceptor) public procedure AfterConstruction; override; function TypeObjectsConverter(Data: TObject): TListOfObjects; override; function TypeObjectsReverter(Data: TListOfObjects): TObject; override; end; procedure TObjectListInterceptor<T>.AfterConstruction; begin inherited; ObjectType := T; end; function TObjectListInterceptor<T>.TypeObjectsConverter(Data: TObject): TListOfObjects; var list: TObjectList<T>; I: Integer; begin list := TObjectList<T>(Data); SetLength(Result, list.Count); for I := 0 to list.Count - 1 do Result[I] := list[I]; end; function TObjectListInterceptor<T>.TypeObjectsReverter(Data: TListOfObjects): TObject; var list: TObjectList<T>; obj: TObject; begin list := TObjectList<T>.Create; for obj in Data do list.Add(T(obj)); Result := list; end; Now lets assume you have a list of TMyObject classes. So you need to declare these two aliases: type TMyObjectList = TObjectList<TMyObject>; { this one is actually not needed, just for readability } TMyObjectListInterceptor = TObjectListInterceptor<TMyObject>; Now we can declare a container class with a field of type TMyObjectList: type TMyClass = class private [JsonReflect(ctTypeObjects, rtTypeObjects, TMyObjectListInterceptor)] FContent: TMyObjectList; { this could as well be TObjectList<TMyObject> } FCount: Integer; FPage: Integer; FPageCount: Integer; public constructor Create; destructor Destroy; override; end; constructor TMyClass.Create; begin inherited Create; FContent := TMyObjectList.Create(); end; destructor TMyClass.Destroy; begin FContent.Free; inherited Destroy; end;

Note that even if every update subscriber gets access to the beta, they are still under NDA and may not discuss testing 10.4 Denali in public.

Or the one in Indy (TIdFTPServer). Not in FTP, no. That is simply not how the FTP protocol works. The client has to login up front at the beginning of the FTP session, and cannot re-login again afterwards without disconnecting first. Like Angus said, you will basically have to create your own FTP server that you have complete control over. A pre-existing server, like IIS, is not really going to help you with this kind of task. Statically defined virtual folders, yes. But dynamically defined virtual folders, no. Server components like the ones in ICS and Indy give you direct access to the client's commands, and virtual folders is really not that difficult to implement when you have direct access to the paths the client is trying to access. I once wrote a virtual folder manager for Indy (I don't have it any more, though), it is just a matter of splitting a requested path into its individual parts and then walking the parts resolving each one to a physical folder as needed until you end up with a final physical path. So, in your case, when the user starts the transaction, you create the virtual folder in your DB/whatever and make sure that folder is resolvable to a physical folder and is included in directory listings as needed. When the transaction is done, delete the virtual folder from your DB/whatever. If the client requests a path that includes a virtual folder that is no longer resolvable, a standard FTP 55x error response, like 550 or 553, will suffice to let the client know the path is no longer valid.

As to your suggested bugfix: It seems to work fine in my tests, but I am not sure whether it will fix the original problem reported in bug #79, but I'll just assume the best and wait for new bug reports. 😉

Hi Thomas, as I'm not sure if comments on SourceForge bugs getting you attention, so I post here too: I have added some comments on issue #79: https://sourceforge.net/p/gexperts/bugs/79/ It would be fine if you could check the proposed change (and most probably complete my missed parts) In short, the expanded template seems to be added fine but deletion of template code fails as it considers the position as character based while the expansion calculated it byte based. Thank you!