|
|
Rank: Member
Groups: Member
Joined: 6/2/2011
Posts: 12
|
I have the following bare-bone test html that I convert to pdf using your library <html> <BODY> <TABLE style="WIDTH: 100%; HEIGHT: 246px"> <TBODY> <TR> <td><INPUT type=checkbox CHECKED>First checkbox</td> </TR> <tr> <td><INPUT type=checkbox>Second checkbox</td> </tr> </BODY> </html> EO.Pdf.HtmlToPdfResult res=EO.Pdf.HtmlToPdf.ConvertUrl("G:/1.html", "g:/1.pdf"); In a standalone application conversion works just fine.  If I run the same code in a Windows service (same machine) checkboxes are converted to dropdowns  What could be the problem?
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,194
|
Hi,
We tested it and it worked fine here. In fact we can't think of anything that would be different as to whether the converter runs inside a service or not. Can you try to isolate the problem into a test project (including the service part) and then send it to us? We will be happy to take a look as soon as we have that.
Thanks!
|
|
Rank: Member
Groups: Member
Joined: 6/2/2011
Posts: 12
|
Thank you for your quick reply.
Very odd indeed. Our service runs an embedded web server that among other tasks processes html forms uploaded to it converting them to pdf documents. Currently we delegate html-pdf conversion to an external application that runs outside our service and uses pdf printer. The service runs under Local System account with no interaction with Desktop.
It is my understanding that your library doesn't have external dependencies except on generic Windows GDI or similar libraries. Also your library doesn't use Microsoft.mshtml assembly to process html DOM. Am I correct?
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,194
|
Hi,
That is correct. We do not have external dependencies and do not use MS mshtml assembly. We rely on GDI and GDI+, but none of those would be different whether running inside a service or not. So I do not believe this has anything to do with being inside a service. We do not need a desktop to function.
Both the checkbox and drop downs are painted with Windows Marlett font. So you might want to check whether your code has done something sophisticated with Windows font. In any case, try to isolate the problem into a test project should help you to locate the root of the problem.
Thanks!
|
|
Rank: Member
Groups: Member
Joined: 6/2/2011
Posts: 12
|
We do not need a desktop to function. Apparently your library uses a Windows API that fails if there is no desktop or Windows messages. Once I enable "Allow service to interact with desktop" in service properties pdf was rendered correctly showing checkboxs. According to Microsoft GDI+ is not supported for use in Windows Service. Here an excerpt from http://msdn.microsoft.com/en-us/library/ms533798%28v=vs.85%29.aspxGDI+ functions and classes are not supported for use within a Windows service. Attempting to use these functions and classes from a Windows service may produce unexpected problems, such as diminished service performance and run-time exceptions or errors.
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,194
|
Interesting discovery. Thanks for the update.
|
|
Rank: Member
Groups: Member
Joined: 6/2/2011
Posts: 12
|
The trouble is: Windows Server 2008, Vista, and W7 don't allow to configure interactive services even though the check box is available on the property sheet. When you start such a service you get SCM error 7030 in event log. Interactive services are only allowed on Windows XP and Windows Server 2003 which I used for testing.
The good news is that when I tested the code on Windows Server 2008 , and Windows 7 32 the results show correct checkbox rendering. So currently XP and w2003 has issues.
I believe that there is one API call that fails on Windows XP
Your thoughts?
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,194
|
Hi,
We do not know yet. I was under the impression that we do not need interactive service since we do not directly interact with users. However based on your testing it's obviously that option somehow affect something. Further more, we ran some test on Windows 2003 and it worked fine for us. I can not think any of the API would just fail for the checkbox because it's really just a different font. We will investigate further and see what we can find.
Thanks
|
|
Rank: Member
Groups: Member
Joined: 6/2/2011
Posts: 12
|
It looks like only Windows XP (all variations) has this problem. I tested it on Windows 7, Windows Vista, Server 2008, Server 2003. Will test on Server 2011. Also need to check 64-bit variations as well.
Hopefully we can temporary fix the problem by setting our service as interactive during the installation if OS is Windows XP. On existing XP installations we will need to set interactive flag manually. Also I need to check whether this approach works on XP without interactive user logged in.
My concern is whether we can run into similar issues down the road when we use your library from within Windows service.
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,194
|
Hi, That most likely looks a bug in XP that has been fixed. When a service is set to "interactive", it actually only means the service progress is associated to the "interactive desktop" instead of a separate internal desktop object. See here for more details: http://support.microsoft.com/kb/171890Theoretically it shouldn't really make any difference to a process as to which desktop object it is associated to, except for the different permission set to the account that created the desktop. For instance if you don't have network permission, then you certainly won't be able to use the Html to Pdf converter to pull a remote Url. The problem appears that Windows XP has problem with Marlett font (or somehow it uses a different version of that font) inside a "non-interactive" service. We still do not know how that happens. Will update as soon as we find anything on this. Thanks!
|
|