FPiette

Inheritance is maybe the most fundamental concept making a record different from an object. Record, managed or not, are definitely not classes. I never found any memory management issues with classes.

@pyscripter I'm surprised, that you call CreateDCRenderTarget, you get a ID2D1DCRenderTarget while you need a ID2D1DeviceContext to call Direct2D 1.1 or later specific functions. Maybe I missed something? Looking at https://docs.microsoft.com/en-us/archive/msdn-magazine/2013/may/windows-with-c-introducing-direct2d-1-1 I saw this sentence: So I'm using CreateDeviceContext instead CreateHwndRenderTarget. And all other steps required as explained in the above mentioned article. When using a single Direct2D window, the speed difference is not really visible. But as you saw in my application, I can have 50 or even 100 small Direct2D windows. And with as much windows, the speed difference is highly visible. The screen shot in the first message of this thread has 49 small windows and takes 10 seconds to build with Direct2D 1.1 and less than one second with Direct2D 1.0. Then if I open a single image to see it in big, there is no noticeable speed difference (Zoom, pan, flip and rotate) because the time scale is to short. Everything is done in a fraction of a second. I could replace the small windows by a single one showing a single bitmap constructed from all thumbnails. But this would require a lot of works and is much much less convenient. Not to much visible on the screen dump, but the is a checkbox and also frames and various display effect which are really easy to do with the small windows and would be much more work with a single window.

There are now "managed records" which are not classes. See the documentation: http://docwiki.embarcadero.com/RADStudio/Sydney/en/Custom_Managed_Records

In the context of this subject, an interposer class is a bad solution. An inherited class is the correct way. In general, I avoid as much as possible interposer class. I think this make code more obscure. But not everyone share my opinion and that's OK.

I used GDI+ before Direct2D. Direct2D (V1.0 at least) is faster than GDI+ for my purpose. That's why I switched.

Look a nice product. But it is expensive (€269,-), at least for my budget 😞

@Kas Ob. I will have a look at Nexus Quality Suite. Thanks. I am talking about Direct2D. The speed of Direct2D V1.0 implmented by Embarcadero in TDirect2DCanvas is excellent. The exact same program with a modified TDirect2DCanvas using Direct2D V1.1 or later is much slower. No GDI involved, not change if image format (The bitmap displayed are Direct2D bitmaps in format DXGI_FORMAT_B8G8R8A8_UNORM so yes there is an alpha channel).

Please elaborate.

That looks easy at first. You've found yourself there are limitations. But you forgot one important: using a TStringList load the full file into memory. This is probably not desirable if you want to support arbitrary large files. As previous answers mentioned, there are other possibilities. The best solution depends on what you intent to do. Sometimes it is easy to use memory mapped file.

Have a look at OverbyteIcsSslMailSnd demo.

I understand that you confirm my analysis: it is a compiler bug.

I always use the Exit method.

Before writing a report at Embarcadero Quality Portal, I suggest that you debug the code by yourself. You probably know it much than me. Since you don't have D10.4.1, I can arrange a TeamViewer session for you on my computer so that you debug it. Let me know if you are interested.

constructor TPdfObjectStream.Create(aDoc: TPdfDocument); begin inherited Create(aDoc,false); Attributes.AddItem('Type','ObjStm'); fAddingStream := TPdfWrite.Create(ADoc,THeapMemoryStream.Create); end; fObjectCount gets his random value from the inherited Create call. And in the inherite Create, fObjectCount gets his random value from the call to TPdfWrite.Create: constructor TPdfStream.Create(ADoc: TPdfDocument; DontAddToFXref: boolean=false); var FXref: TPdfXRef; begin inherited Create; if DontAddToFXref then FXRef := nil else begin FXRef := ADoc.FXref; FXRef.AddObject(self); end; FAttributes := TPdfDictionary.Create(FXref); FAttributes.AddItem('Length', TPdfNumber.Create(0)); if ADoc.CompressionMethod=cmFlateDecode then FFilter := 'FlateDecode'; FWriter := TPdfWrite.Create(ADoc,THeapMemoryStream.Create); end; I single stepped TPdfWrite.Create to find out where fObjectCount in the caller class is corrupted. It is not corrupted before reaching the end! It is corrupted after return. I then single stepped in the assembly language. Evrything is OK up to the return point in TPdfStream.Create. The corrupting line is the assignation to FWriter SynPdf.pas.4146: FWriter := TPdfWrite.Create(ADoc,THeapMemoryStream.Create); 006D8B57 B201 mov dl,$01 006D8B59 A188B66900 mov eax,[$0069b688] 006D8B5E E8AD06D3FF call TObject.Create 006D8B63 50 push eax 006D8B64 8BCF mov ecx,edi 006D8B66 B201 mov dl,$01 006D8B68 A180D66C00 mov eax,[$006cd680] 006D8B6D E83A1B0000 call TPdfWrite.Create 006D8B72 89431D mov [ebx+$1d],eax <=== This instruction corrupt fObjectCount The address in [EBX+$1D] is the same as the address given by the debugger for FWriter ($AC7CFED) BUT the address of fObjectCount if only one byte away ($AC7CFEF). It should be 4 bytes since FWriter is apointer and I compiled to code in 32bits. IMO it is the compiler which generate bad code.

Using the test project attache to Git report, the AV occurs in the irst line of function TPdfWrite.Add. The value of Self is inaccessible. Call stack is SynPdf.TPdfWrite.Add(0) SynPdf.TPdfObjectStream.InternalWriteTo($ADF2DD8) SynPdf.TPdfObject.WriteValueTo($ADF2DD8) SynPdf.TPdfDocument.SaveToStreamDirectEnd MainForm.TFMainForm.testButtonClick(???) In the test project, it is the first call of TPdfObjectStream.InternalWriteTo, in the first iteration of the for-loop: procedure TPdfObjectStream.InternalWriteTo(W: TPdfWrite); var i: integer; begin Attributes.AddItem('N',fObjectCount); for i := 0 to fObjectCount-1 do with fObject[i] do Writer.Add(Number).Add(' ').Add(Position).Add(' '); Attributes.AddItem('First',Writer.Position); Writer.Add(fAddingStream.ToPDFString); inherited; end; When compiled with record alignment set to Byte, the FObject array has a random length, in the 3000+ range. All value are zero. When compiled with record alignment set to Word, the FObject array contains 6 elements which have good looking values.

You can use Google maps. There is an API at google to display tracks or symbols above their maps of satellite view. For that, within a Delphi program, you can embed a browser component and write a lot of JavaScript. There are commercial components already made. Among them is one from TMS Software: http://www.tmssoftware.biz/Download/Manuals/TMSFNCMapsDevGuide.pdf But there are alternative. You can also use OpenStreetMap which is an open source map project. Maps are available and as well as documentation to use it. It even exists Delphi source code to handle it. See one by @Fr0sT.Brutal here: https://github.com/Fr0sT-Brutal/Delphi_OSMMap

Are you building using run time packages and you didn't deployed it on Linux?

Yes, it is. It is show in one of the demos: OverbyteIcsMailHtml.dproj Note that you can also send RTF in a similar manner (No demo).

Of course. But unlikely.

IMO it is an issue of third party add-on. Contact the producer/author/seller.

I cannot reproduce the AV with those steps. As @Anders Melander suggested, remove any add-on and try again. An add-on may cause the issue.

Can you be a little bit more explicit? Could you load the project one at a time to find out which one cause the crash?

Agreed.

@bazzer747 In my head, an add-on is some software which add new features to the IDE. For example MMX Code Explorer is an add-on. Something that is code (binary or source) that is intended to be included in your application is a library. A special form of library that can be installed in the component palette is named a component. I think that what is in my head is present in many other heads 🙂

Rich text is an old feature of Microsoft email client. It is not supported by all email client. You should probably switch to HTML email.