TppReport.DeviceType is incorrect

Comments

• rbuser

  January 2002 edited January 2002

  Use something like:
  if (rptInvConsig.Publisher.Devices[0].InheritsFrom(TExtraDevice) and
  (rptInvConsig.Publisher.Devices[0].DeviceName = 'ExcelFile') and
  (rptInvConsig.Publisher.Devices[0].DeviceName = 'TextFile')) then
  
  You must include TXtraDev, TXComp in the uses clause, and in that order.
  bye
  
  
  
• rbuser

  January 2002 edited January 2002

  Thank you Guillermo. I never noticed the Publisher property, and it wouldn't
  have helped me much if I had because its properties and methods aren't
  documented in the help file. Thanks to your tip, I looked in the source code
  and found a workaround for my problem.
  
  So RB can print to multiple devices simultaneously! I didn't know that. It
  seems to make the report's DeviceType property obsolete and misleading (at
  least it misled me).
  
  Are people using this multiple-output capability? The default preview dialog
  seems to allow me to select only a single output device in its Print dialog,
  even with Waler's ExtraDevices installed. If anyone is finding it useful to
  print to multiple devices/files simultaneously, maybe the Devices list
  should be surfaced in the report's property editor.
  
  Richard
  
  
• digitalmetaphors

  January 2002 edited January 2002

  You can also check the print dialog's devicetype that was entered, in the
  Report.OnPrintDialogClose event:
  
  ppReport1.PrintDialog.DeviceType = dtFile;
  
  
  Cheers,
  
  Jim Bennett
  Digital Metaphors
  
  
  "Richard Biffl" wrote
  

  Digital Metaphors Corporation
  http://www.digital-metaphors.com
  info@digital-metaphors.com
• rbuser

  January 2002 edited January 2002

  Wow, thanks. That TppCustomPrintDialog is another undocumented class. I have
  to say, I'm learning a lot about RB from working on this problem.
  
  I noticed that the report's OnPrintDialogClose event fires whether the user
  closes the dialog by clicking OK or Cancel. Is there any way to tell which
  action the user took, or an event that fires only when the OK button is
  clicked?
  
  I've discovered another complication. My report has a memo field that I fill
  in the DetailBand.BeforePrint event with text from the report's dbpipeline,
  and several dbtext fields that should not be visible unless the report is
  printed to a text file. If I turn on the Visible property of my dbtext
  fields before the report prints to a file, then the textfile is generated
  correctly, but if I then continue viewing pages in the previewer, the dbtext
  fields are visible on top of the generated memo field, making a mess.
  
  My question: Is there some way to set the Visible property of the dbtext
  fields as the page is generated for EACH output device, according to the
  output device that is being used, so that the report will have the dbtext
  fields visible if it is going to a text file but not visible if it is going
  to the screen or printer? From what I can understand of the source code, it
  appears that the page is generated for ALL devices, then sent to each one,
  with no event that would give me an opportunity to modify the visibility of
  fields on a per-device basis. But maybe I'm missing something, because I
  don't really understand how the preview screen's report settings (e.g.
  ppdbtext1.visible = false) can change after the report has already started
  to be generated.
  
  My workaround is to make the dbtext fields visible in the report's
  BeforePrint event if Report.Publisher.Devices[0].DeviceName = dtTextFile, as
  Guillermo suggested, and make the fields not visible in the report's
  AfterPrint event.
  
  Thanks for the help.
  
  Richard
  
  
• digitalmetaphors

  January 2002 edited January 2002

  In the OnPrintDialogClose event, you can reference the print dialog
  directly, and check the ModalResult:
  
  uses
  ppPDlg;
  
  procedure TForm1.ppReport1PrintDialogClose(Sender: TObject);
  var
  lPrintDialog: TppPrintDialog;
  begin
  
  lPrintDialog := TppPrintDialog(ppReport1.PrintDialog);
  
  if (lPrintDialog.ModalResult = mrCancel) then
  ShowMessage('You cancelled the print!');
  
  end;
  
  In the AfterPrint event you can reference the FileDevice property directly
  and determine the type of device which was used.
  
  uses
  ppFilDev;
  
  procedure TForm1.ppReport1AfterPrint(Sender: TObject);
  begin
  
  if (ppReport1.FileDevice <> nil) then
  begin
  if (ppReport1.FileDevice is TppReportTextFileDevice) then
  ShowMessage('You printed a report emulation text file.')
  else if (ppReport1.FileDevice is TppTextFileDevice) then
  ShowMessage('You printed an ASCII data file.')
  else
  ShowMessage('You printed to an unknown file type.');
  end;
  
  end;
  
  When calling Print, only one device is created. Multiple devices only come
  into play when the developer chooses to manually create device objects and
  generate output to them via a call to Report.PrintToDevices;
  
  You can do this by placing the same code in the Report.BeforePrint event:
  
  procedure TForm1.ppReport1BeforePrint(Sender: TObject);
  begin
  
  if (ppReport1.FileDevice <> nil) then
  begin
  if (ppReport1.FileDevice is TppReportTextFileDevice) then
  ShowMessage('You are about to print to a report emulation text
  file.')
  else if (ppReport1.FileDevice is TppTextFileDevice) then
  ShowMessage('You are about to print to an ASCII data file.')
  else
  ShowMessage('You printed to an unknown file type.');
  end;
  
  end;
  
  Cheers,
  
  -
  --
  Tom Ollar
  Digital Metaphors Corporation
  

  Digital Metaphors Corporation
  http://www.digital-metaphors.com
  info@digital-metaphors.com
• rbuser

  January 2002 edited January 2002

  Thank you very much for the explanations and code, Tom.
  TppPrintDialog.ModalResult and TppReport.FileDevice are the properties I was
  looking for.
  
  I was relying on the help file for these issues, as I do in Delphi, when the
  hooks I needed were in the source code. RB has very good documentation of
  laying out reports in the report designer, but some additional documentation
  of its internals would be helpful for coding special features. Even now that
  I have working code, I'm a little uncertain of the various purposes of
  TppReport.DeviceType, TppReport.Publisher.Devices, and
  TppReport.FileDevice -- but that's okay, because I don't really want to know
  more than I need to know (but I want to know all that I need to know).
  
  It seems that the first property, TppReport.DeviceType, is in effect a
  write-only property. I guess that's why it's the one that's documented,
  because it specifies the initial device. Would it be feasible to change that
  property's value as the report is processed, so that it can be read to
  determine the currently active devicetype? That's what I initially assumed
  was happening. Or maybe, if you want for some reason to preserve the
  original DeviceType setting as a report is processed, you could have another
  property or method that would return the current devicetype?
  
  Richard