FPiette

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.

@Darian Miller I your blog post, you said: That is something I repeated so many times to so many people with one more advice: if source is not available, don't by that component. And I often add this advice: never use prebuilt packages or dcu from 3rd party component, always rebuild everything, at least once to be sure you have everything required and know how to rebuild. When you have several 3rd party component, create a project group with all projects required to rebuild all components, including your own component. Then when a new Delphi version comes, you can easily rebuild and reinstall everything within minutes. As you mentioned in your blog post:

Maybe a direct question would be better in front of your message. Maybe everybody have no time to read such a long text 😉

Those are components, not add-ons.

I would not say "any" but "most" 😉 Which add-ons are you using?