1. Marco Meoni
  2. SnapObjects
  3. Wednesday, 5 June 2019 20:46 PM UTC

Hello,

as from the title:

since the C# Model Generator builds the POCO but also stores the .srd file (i.e. the entire DW layout) would it be possible to enhance the C# datastore API and add PDF generation (even in memory) ?

Something like the NativePDF in regular PB dw.SaveAs().

That would allow to generate the PDF server side, and return it to the client (Base64 encoded?).

Any advise?

Best,

.m

 

Chris Pollach @Appeon Accepted Answer Pending Moderation
  1. Sunday, 23 June 2019 14:56 PM UTC
  2. SnapObjects
  3. # 1

Hi Marco;

   Armeen is correct as there is no GUI layer of the DWO that can be processed in the current  C# projects in order to produce a PDF. So Appeon would need to reconstitute the SRD in C# in order to supply the PDF rendering. Not a trivial task.

  However, what about PDF generation like I do in the older Web Services where I call an external PB application EXE to produce the PDF. The rendered PDF is placed on a web server's "landing pad" where the client app can grab it. You could also drop the rendered PDF into a table blob instead so that any app can grab it from there.

FYI: http://chrispollach.blogspot.com/2017/10/pdf.html

HTH

Regards ... Chris

Comment
  1. Chris Pollach @Appeon
  2. Monday, 24 June 2019 13:55 PM UTC
Hi Marco;

I am interested to see how you can build PDF files without DW GUI controls like: Picture, Line, Oval, Rectangle, border, font, style colouring, etc. PDF's really need visual objects in order to render anything useful IMHO.

Over the weekend, I was able to build a simple C# Web API that called PB batch app EXE's using the following test code ....

System.Diagnostics.Process lo_process= new System.Diagnostics.Process();

lo_process.StartInfo.FileName = @"C:\Dev\PB2017\PDF\PBPDF.exe";

lo_process.StartInfo.Arguments = "C:\Inetpub\PDF\TEST.pdf"; //argument

lo_process.StartInfo.UseShellExecute = false;

lo_process.StartInfo.RedirectStandardOutput = true;

lo_process.StartInfo.WindowStyle = System.Diagnostics.ProcessWindowStyle.Hidden;

lo_process.StartInfo.CreateNoWindow = true; //not diplay a windows

lo_process.Start();

string output = lo_process.StandardOutput.ReadToEnd(); //The output result

lo_process.WaitForExit();

I was able to simulate up to 50 concurrent threads. The response time was about 1-3 seconds. The batch PB App EXE was written using my framework, so I was able to bind each new thread to a specific CPU using the framework's "CPU Affinity" feature. Not 100% perfect but this does allow for some multi-threading from the O/S side.

As far as the Web Server landing platform or using a DB Table ... I use this approach when standard daily, weekly, monthly, quarterly, etc reports are produced by a system. Instead of generating these for every client call, I save them and just resend them to each client from the "pool" of PDF's already built. Then the Web Service turn-around then is in milliseconds.

Any way, just a food for thought of how one *could* build SnapDevelop C# Web API web services PDF generation today ... while we wait for Armeen to code the SRD support. ;-)

HTH ... Food for thought

Regards ... Chris
  1. Helpful
  1. Marco Meoni
  2. Tuesday, 25 June 2019 09:22 AM UTC
Hi Chris,

very appreciated your WebAPI2EXE test case and benchmark. That is certainly a workaround that deserves to be proposed to impatient customers instead of parking promising C# REST projects waiting for a builtin feature. Thank you!



W.r.t to rendering graphical controls in the PDF, I mean the .srd file already contains the geometry of these controls. Years ago I used to create my own PDFs from PB using Java and iText: you open a FileOutputStream, create an empty document and then start scripting what objects your're gonna display: paragraphs, images, ovals... play with absolute or relative coordinates on the page, etc ...this is how PDF is actually created and how graphical controls are assembled together.

Best,

.m

  1. Helpful
  1. Chris Pollach @Appeon
  2. Tuesday, 25 June 2019 17:20 PM UTC
Yes, I remember way back doing that manually as well ... but that was before we became civilized (spoiled) with the DW object & DW Painter .. LOL!
  1. Helpful
There are no comments made yet.
Gian Luca De Bonis Accepted Answer Pending Moderation
  1. Sunday, 23 June 2019 07:40 AM UTC
  2. SnapObjects
  3. # 2

Hi Armeen and Marco, I’ve seen this case several times too, in the context of PB Open. There are of course different ways to generate a PDF starting from a DataStore, but a SaveAs will of course make the conversion much easier.

I hope we will see this method in the near future :)

Thanks, GL

Comment
  1. Roland Smith
  2. Sunday, 23 June 2019 17:01 PM UTC
My server solution runs PowerBuilder code from PBD files (no .Net conversion) so it supports the SaveNativePDFToBlob method to generate a PDF in memory. PB 2019 clients will support gzip compressed returned data.
  1. Helpful
There are no comments made yet.
Armeen Mazda @Appeon Accepted Answer Pending Moderation
  1. Wednesday, 5 June 2019 21:47 PM UTC
  2. SnapObjects
  3. # 3

Hi Marco,

I can tell you from a product perspective that it is possible for us to make this a feature of the .NET DataStore since as you pointed out we do have the SRD file. 

We have not yet done this for two key reasons:  

  1. There is some substantial amount of work to add this feature in a way that is high performance and scalable in the context of server app that is called by multiple users.  So we need to see enough demand for this compared to current way that can simply sync the .NET DataStore with a PowerScript DataWindow and do the SaveAs PDF at the client side.

  2. We have searched and not found a really good PDF library for .NET Core.  But it should be only a matter of time before good solution is available, considering Microsoft is basically replacing .NET framework with .NET Core in the next version after .NET Core 3.0.

Regards,
Armeen

Comment
  1. Armeen Mazda @Appeon
  2. Thursday, 9 April 2020 15:33 PM UTC
Sorry, not yet. Please send email to product@appeon.com to express your interest in such feature enhancement. Thanks!
  1. Helpful
  1. Ricardo Jasso
  2. Thursday, 9 April 2020 20:49 PM UTC
It is not the intention of the new .NET DataStore to render any graphical representation of the data. In fact, to be consistent with its purpose, the SRD file has been stripped out in the last release of PowerBuilder 2019 R2. So, no graphical information is anymore stored as part of the model.



This is in par with Armeen's presentation at Elevate 2019 where he explained that one of the "drawbacks" of the past DataWindow.NET was that it was designer dependent and that it had no separation of concerns. So, the new .NET DataStore was designed to have a "Layered & Pluggable" architecture which might imply that (don't take my word for it) a PDF rendering layer could be developed as a plug in. This will require a graphic design tool in SnapDevelop, I think. But from what I understand the purpose of C# development with SnapDevelop is to build non visual business logic that can be deployed as Web APIs, so I guess it won't make any sense to invest time and effort to develop such a tool.



What could be really useful in SnapDevelop is a tool to build a model without having to code it directly, something like the Query Painter in PowerBuilder. Query Painter is rarely used alone in PowerBuilder because it is accessed from within the DataWindow Painter, but since concerns are now being separated in the new .NET DataStore a tool to graphically select tables and columns to build a model would help us a lot. Specially for project that we want to build from scratch.
  1. Helpful
  1. Armeen Mazda @Appeon
  2. Thursday, 9 April 2020 21:04 PM UTC
We do plan to develop such a tool as part of the roadmap for the .NET DataStore. In the interim, developers that don't want to hand-code the POCO model can use the DataWindow designer in the PowerBuilder IDE to create the DataWindow and then use the DataWindow Converter in SnapDevelop to automatically create the POCO model from that.
  1. Helpful
There are no comments made yet.
  • Page :
  • 1


There are no replies made for this question yet.
However, you are not allowed to reply to this question.