Cristian Peța

This procedure takes 76% of time in my case
2694    procedure TfrxPDFExport.ExportViaVector(const Memo: TfrxCustomMemoView);

and was called because GapY was -1

  if (Memo.ReducedAngle <> 0) or (Min(Memo.GapX, Memo.GapY) < 0) then
    ExportViaVector(Memo)

With Gap=0 for some of memo components ExportViaVector() takes 44% of time and the report looks the same but the PDF is generated in 6 seconds vs. 13 seconds

Edit: Better take a profiler and don't lose the time guessing.

Just tried 200 pages of something like this. 13 seconds.

The best would be to profile frxExportPDF unit

Only for testing. Why not? It's not Windows 10?

Have you tried with Microsoft driver?
 

frxReport9.PrintOptions.PrnOutFileName := 'name.pdf';
frxReport9.PrintOptions.Copies := 1;
frxReport9.PrintOptions.ShowDialog := False;
frxReport9.PrintOptions.Printer := 'Microsoft Print to PDF';
frxReport9.SelectPrinter;
frxReport9.Print;

At Export() that 5000 records doesn't count because the report is prepared.

How many pages are? How many items per page? There are also vector images like charts or EMF, WMF?

I tested for example 40 pages (200 records with one image and 30 text items per record) with booth FR Export and printing to "Microsoft print to PDF". The speed is about 3 seconds for both on a i7-8700K CPU. This is only Export because I do this at preview where the report is already prepared.

P.S. You are too scarce with details and want a suggestion.....

3 hours ago, dkprojektai said:

low speed for building PDF

Building PDF is PrepareReport() or Export() ?

From the call stack it looks like Validate is called a little to late to modify the value. Documentation says also "To reject the current value of the field from the OnValidate event handler, raise an exception."

I would use Abort like this:

procedure TfrmClose.tbCloseAmtValidate(Sender: TField);
begin
  if Sender = nil then
    exit
  if (Sender.DataSet.FieldByName('Long Short').AsString = 'Long') then
  begin
    if (Sender.AsFloat < 0) then
    begin
      ShowMessage('Close value should be positive or zero');
      Abort;
    end;
  end
  else if (Sender.DataSet.FieldByName('Long Short').AsString = 'Short') then
  begin
    if (Sender.AsFloat > 0) then
    begin
      ShowMessage('Close value should be negative or zero');
      Abort;
    end;
  end;
end;

Take a profiler and save you time guessing what is slow.

I use Nexus Quality Suite and I like it but there are also some free alternatives. Actually first time I used it I found the bottleneck with the trial version of NQS. I like very much line profiler. If you try it for these 4 lines it is very probably the first line and not the last that is the bottleneck. Then you goo deeper.

P.S. If the time is big enough you can see also in debugging if the first or last line is slower. If the last line is slow then not the dataset is bottleneck but maybe some very big picture.

6 hours ago, PeterPanettone said:

However, your employer has to pay for the time you need to write overloaded code. (Though I assume you're a fast writer). 

Depends. I added only 15K LOC last year to my project. A lot of time I spend thinking how to add features asked by customers to actual app logic. This doesn't have to do with old code but to old app logic and not to break old behavior. An to leave space for feature improvements because this is a 20 years old project.

For this case will work with Variant.

procedure DoSomething(const AParam: Variant);
begin
  ShowMessage(AParam);
end;

If you are using TMetaFile in your report you can try to set AllowVectorExport to False for that component (in report editor). This way PDF export will work like version 5 generation an image.

Probably some test escaped in the wild...

On 6/6/2020 at 12:00 AM, Cristian Peța said:

Not usable for me yet. 

[TClientDataSet] Exception when a ftWideMemo is set to an empty string with LogChanges=True

https://quality.embarcadero.com/browse/RSP-29431

Fixed (see report).

Not usable for me yet.

[TClientDataSet] Exception when a ftWideMemo is set to an empty string with LogChanges=True

https://quality.embarcadero.com/browse/RSP-29431

P.S. Just updated the report with an other issue very probable related.

Here is @David Heffernan's response:

https://stackoverflow.com/questions/25536216/delphi-prevent-application-shutdown

22 minutes ago, Ian Branch said:

My issue/point is that I am NOT getting the message.

I must repeat: this is documented and is working "as designed"

If you want an other behavior and don't want to do what documentation says the you need to find an other OS.

Documentation says: "If your application must block or postpone system shutdown, use the ShutdownBlockReasonCreate function."

Then when you are finished use ShutdownBlockReasonDestroy.

4 hours ago, Ian Branch said:

if MessageDlg('Windows is shutting down! First save data changes?', mtConfirmation, [mbYes, mbNo], 0) = mrYes then begin

This is not just a message. You are waiting for the user to press You or No. And in this time you are not returning to the OS. Then the OS will simply kill you app.

4 hours ago, Ian Branch said:

I never see the MessageDlg prompt.

This is documented here (read Remarks): https://docs.microsoft.com/en-us/windows/win32/shutdown/wm-queryendsession

If you really need to stop the shutdown: "Each application should return TRUE or FALSE immediately upon receiving this message"

So you must return immediately, not showing a message and wait...

But... "Applications should respect the user's intentions and return TRUE"

If possible it's better to save data in other place and next time you app is running again ask the user if he want to keep this data. Or even better, if you can, restore the app state exactly how it was at shutdown and you don't need to ask anything. The user will see your app exactly how it was at shutdown. That's how mobile app are supposed to work but it's nice also for desktop.

You are right, I didn't noticed. I made this procedure in a hurry from my code and there I need to save to a stream.

On 5/15/2020 at 12:04 AM, Tntman said:

I know but win api is too difficult for me

Then probably what I proposed (to adapt the component from FMX to VCL) is also too difficult for you.

On 5/15/2020 at 12:04 AM, Tntman said:

BTW, do you know why we have such a difference in size when SS is saved? 

uses
  Vcl.Imaging.pngimage;

procedure SaveBitmapToPNG(ABitmap: TBitmap; const AFileName: String; ACompresionLevel: Integer = 7);
var
  img: TPngImage;
  strm: TFileStream;
begin
  img := nil;
  strm := TFileStream.Create(AFileName, fmCreate);
  try
    img := TPngImage.Create;
    img.CompressionLevel := ACompresionLevel;
    img.Assign(ABitmap);
    img.SaveToStream(strm);
  finally
    strm.Free;
    img.Free;
  end;
end;

Here TBitmap is a Vcl.Graphics.TBitmap
 

TCameraComponent  is using FMX.Graphics.TCanvas and you should replace with Vcl.Graphics.TCanvas and so on.

Look what TCameraComponent is doing and do the same using Vcl units.

Some things are not the same but with some work I think it should be doable.

Accessing camera has nothing to do with VCL or FMX. It should be feasible to copy what FMX.Media.TCameraComponent is basically doing (trimming all the FMX part) and make you own simple component for VCL.

At least that's what I would do.

I would like to have List.High or List.HighIndex or List.LastIndex or whatever.

Why to write every time -1 when you want the last index?

I don't understand. Have you reproduced this on your machine? Then you can debug and see the call stack.

If not, then as @Lars Fosdal said: get MadExcept or EurekaLog and don't waste your time.

I dot't know how EurekaLog is but with MadExcept you need only to install it and check the checkbox that you want it in your app. That's all. Then you will have a full call stack to see where this happens in your code.