|
|
Rank: Member
Groups: Member
Joined: 5/4/2016
Posts: 19
|
I've noticed that in an ASP.NET WebForm project that the EO.Pdf.HtmlToPdf.Options seem to have a global (not per page) scope. IE, if I set them on one page, they are still set for other pages. For example, if I set the zoom below, it will be used on other pages that use the ASPXToPDF control if I don't explicitly overwrite on said page. Example...
EO.Pdf.HtmlToPdf.Options.ZoomLevel = 1f; //all future calls to ASPXToPDF in application use this zoom unless overwritten.
EO.Pdf.HtmlToPdf.Options.NoScript = true;
ASPXToPDF1.RenderAsPDF(this.Title + ".pdf");
So, I can anticipate unanticipated results if different options are needed for different pages. For example, simultaneous requests from different users (on different pages) may change the global settings during a render process on another page. So my questions are...
* What is the scope of EO.Pdf.HtmlToPdf.Options in a Webforms project? Is it per IIS application instance? Per user session?
* Why is there no option to use a "new" HtmlToPdf.Options object with the ASPXToPDF like there is with the other HTMLtoPDF functions? Seems like this would prevent any issues.
I am very new to EO.PDf so I apologize if I am missing something. Thanks for your help!
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,229
|
Hi,
The scope is per thread. So setting it directly before RenderAsPDF is the correct way of doing it. Exposing an Options property on the ASPXToPDF class is an interesting idea that we might look into it. The downside is then these settings will be serialized into view state and get posted backs during round trips, which is often unnecessary since the conversion options are often rather constant instead of varies based on page data.
Thanks!
|
|
Rank: Member
Groups: Member
Joined: 5/4/2016
Posts: 19
|
Thanks for the explanation. Since the render process can take several seconds, I can certainly foresee the options being changed mid-render on a multi-user web application from another user. The results probably won't be good. :( Looks like I'll have to figure out a way to get the HTMLtoPDF functions working with our custom authentication scheme so I can avoid this limitation in the ASPXtoPDF control (which is very handy because it runs in the same context as the authenticated user).
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,229
|
Hi,
No. It won't be changed by other user mid-render. The options is maintained per thread upon it enters our call. When your code enters our calls we make a copy of the current option of the current calling thread and then use that option through out that conversion. User can change the option for that thread after that point and it will affect the next conversion in that thread, but it won't affect the previous conversion that's already on its way. So all you need to do is to set the property option before you call RenderAsPDF and you do not need to worry about it being changed by other users.
Thanks!
|
|
Rank: Member
Groups: Member
Joined: 5/4/2016
Posts: 19
|
Thanks for the clarification! Guess I was anticipating problems before they occurred. Sounds like as long as I remember to reset all the options (that I have changed in other pages) before each render, I should be good.
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,229
|
Yes. That's correct. Please feel free to let us know if you still have any other questions.
|
|