Leaderboard

The Community Edition is a Delphi 12.1 Athens version. This said some GetIt servers have technical problems. Embarcadero teams know that and are working on it.

Special Summer Offer from Almediadev and DelphiStyles! You can order our products with good discount now! https://www.almdev.com https://www.delphistyles.com Regards, Almediadev

I agree entirely with @Michaell However there actually are often good reasons to switch, common ones are any of: a) you want to write 64bit applications b) you want to use any of the modern C++ features (for example the use of "auto" is often really useful (aka essential) for templates) c) you want to use any modern C++ library (most up to date versions of libraries fail to compile on "Classic") d) you employ a young C++ programmer who finds it frustrating to work with "Classic", having got used to working with modern C++ constructs available. For any project with a long term future there is likely to come a time where you will want to change to Clang. The compilation time is a real pain! But you learn to structure your code such that a full build of all files is not required so often. (There is also the "module" approach coming to C++ bit by bit which is claimed to speed up compilation, but that is very definitely another topic!). I have moved most of my main projects across to Clang. I have one more commercial project to migrate and am just waiting for the right moment (which is related more to commercial and administrative considerations rather than technical ones).

Just an update on this. It turns out it's not an OLE Automation compatibility issue between Delphi and LibreOffice as I was starting to fear. Apparently the inner array that you pass to the initialize method of SequenceInputStream must be a "strongly typed uno value", so you have to massage the input a little bit. For the benefit of anyone stumbling upon this thread in future, here is how you load a LibreOffice document from a memory buffer: function LoadLibreOfficeDocumentFromMemory(const ADocumentFileData: TBytes): Variant; var LServiceManager, LStrictlyTypedUnoValue, LInputStream, LDesktop: Variant; LArgumentsArray, LPropertyArray: TArray<Variant>; begin LServiceManager := CreateOleObject('com.sun.star.ServiceManager'); {A SequenceInputStream is used to load the document from memory. In order to get the bytes into the SequenceInputStream the initialize method is called. This method takes an array of arguments, in which it expects to find a single entry which must be a strictly typed uno value - a byte array.} {Create the argument array for SequenceInputStream.initialize} LStrictlyTypedUnoValue := LServiceManager.Bridge_GetValueObject; LStrictlyTypedUnoValue.Set('[]byte', Variant(ADocumentFileData)); SetLength(LArgumentsArray, 1); LArgumentsArray[0] := LStrictlyTypedUnoValue; {Create and initialize the SequenceInputStream} LInputStream := LServiceManager.createInstance('com.sun.star.io.SequenceInputStream'); LInputStream.initialize(Variant(LArgumentsArray)); {Specify the stream to load from in the property array for loadComponentFromURL.} SetLength(LPropertyArray, 1); LPropertyArray[0] := LServiceManager.Bridge_GetStruct('com.sun.star.beans.PropertyValue'); LPropertyArray[0].Name := 'InputStream'; LPropertyArray[0].Value := LInputStream; {Load and display the document} LDesktop := LServiceManager.createInstance('com.sun.star.frame.Desktop'); Result := LDesktop.loadComponentFromURL('private:stream', '_blank', 0, Variant(LPropertyArray)); end;

The getit server is down (or is not working) since Saturday.

Why don't you show us the fix? 🙂

Actually, a patch was already created for FreePascal to add this very same conditional operator (FPC already had an IfThen() intrinsic); https://forum.lazarus.freepascal.org/index.php/topic,71398.msg556926.html#msg556926

FWIW I reported the bad inlining due to the way these methods are implemented in TInterlocked and proposed the improvements in https://embt.atlassian.net/servicedesk/customer/portal/1/RSS-3862

Hello all, suppose I have a generic class that's going to be inherited. I want to give the base class a method that creates a new instance of the same object type (a class factory so to speak). How can I do that? I need to somehow tell the compiler which constructor to call. Type tSomeclass<T:iInterface>=CLass (tInterfacedObject, iSomeInterface<T>) //many methods here Procedure SomeMethod(intf: T); Function SomeFunction:T; Constructor Create(someparameters); Function CreateNewInstance:iSomeInterface<T>; end; ... Function tSomeclass<T>.CreateNewInstance:iSomeInterface<T> begin result:=Self.Classtype.Create(fSomeParameters); //Does not compile end;

The reason I'm trying to achieve this is the following. I have made a generic tStreamableInterfaceList<T:iInterface> which is basically a managed Tlist<T> that implements iInterfacelist<T>. The elements are interfaces. This list object knows several special tricks such as saving its contents to XML and BSON. It can also load those elements back from such data files, which necessitates a virtual ClassFactory() method to create the correct objects "on the fly" based on the class names found in the data. So far, this all works very nicely. I wanted to enhance this list with a few LinQ-like methods such as: Function .Where(aCondition:tPredicate<T>):iInterfacelist<T>; Function .OrderBy(aCompare:tComparison<T>):iInterfacelist<T>; ... but in order to achieve that, the base class must be able to dynamically instantiate derived classes or else the resulting objects would have the base nonfunctional Classfactory() method. The "ugly" solution would be to put an abstract virtual Clone() method in the base class, but I'd very much like to avoid that.