Sorry, not yet. Please send email to product@appeon.com to express your interest in such feature enhancement. Thanks!

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.

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.

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.

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

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

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!