Howdy, Stranger!
Categories
- All Categories
- 73 General
- 73 Announcements
- 66.6K Microsoft Dynamics NAV
- 18.6K NAV Three Tier
- 38.4K NAV/Navision Classic Client
- 3.6K Navision Attain
- 2.4K Navision Financials
- 115 Navision DOS
- 854 Navision e-Commerce
- 1K NAV Tips & Tricks
- 772 NAV Dutch speaking only
- 615 NAV Courses, Exams & Certification
- 2K Microsoft Dynamics-Other
- 1.5K Dynamics AX
- 295 Dynamics CRM
- 109 Dynamics GP
- 10 Dynamics SL
- 1.5K Other
- 993 SQL General
- 384 SQL Performance
- 34 SQL Tips & Tricks
- 34 Design Patterns (General & Best Practices)
- Architectural Patterns
- 10 Design Patterns
- 5 Implementation Patterns
- 53 3rd Party Products, Services & Events
- 1.7K General
- 1.1K General Chat
- 1.6K Website
- 79 Testing
- 1.2K Download section
- 23 How Tos section
- 259 Feedback
- 12 NAV TechDays 2013 Sessions
- 13 NAV TechDays 2012 Sessions
Print PDF from 2013 R2
OldNavDog
Member Posts: 88
Hello, Experts!
Referring to this thread:http://www.mibuso.com/forum/viewtopic.php?f=32&t=46507&hilit=process.start+print+file
I have tried for three DAYS now to get ANY PDF "Printer" to print an (already existing) PDF File from the 2013 R2 Windows Client (not from a WebService).
I have been 'round and 'round with this, trying various solutions with Adobe Reader, Foxit Reader, and another one I found, SumatraPDF. All purport to be able to print from a Command Line. All exhibit the same problem: According to MS' Process Explorer, they launch, the command line looks GREAT, but then, they just... HANG. No error, no NOTHING (and of course, no Printing).
I have tried both calling the PDF App from Systems.Diagnostics.Process 'Directly' (like in the Thread above), and creating a Batch File, then using Systems.Diagnostics.Process to "run" the batch. No go. But when I did create the batch file, I can run THAT from outside NAV, and it works just like Mama said. So I think my command-line syntax is fine (it also looks fine when I view it in Process Explorer).
I feel like there is a Dialog waiting for some response in another Universe; but I'm a noob with DotNet, so I really don't know where to even start.
Again, I get no "error", and the process just HANGS. Of course, there is also no output.
The Environment is NAV 2013 R2, running under MS Server 2012.
I will post code if you like, but at this point, it is pretty much exactly the "PrintPDF" and "StartProcess" functions (minus the "Default Printer" stuff in 'PrintPDF')
I am using the same DotNet "assemblies" that are called out in the above thread.
Any ideas? HELP! QQ ](*,)
Referring to this thread:http://www.mibuso.com/forum/viewtopic.php?f=32&t=46507&hilit=process.start+print+file
I have tried for three DAYS now to get ANY PDF "Printer" to print an (already existing) PDF File from the 2013 R2 Windows Client (not from a WebService).
I have been 'round and 'round with this, trying various solutions with Adobe Reader, Foxit Reader, and another one I found, SumatraPDF. All purport to be able to print from a Command Line. All exhibit the same problem: According to MS' Process Explorer, they launch, the command line looks GREAT, but then, they just... HANG. No error, no NOTHING (and of course, no Printing).
I have tried both calling the PDF App from Systems.Diagnostics.Process 'Directly' (like in the Thread above), and creating a Batch File, then using Systems.Diagnostics.Process to "run" the batch. No go. But when I did create the batch file, I can run THAT from outside NAV, and it works just like Mama said. So I think my command-line syntax is fine (it also looks fine when I view it in Process Explorer).
I feel like there is a Dialog waiting for some response in another Universe; but I'm a noob with DotNet, so I really don't know where to even start.
Again, I get no "error", and the process just HANGS. Of course, there is also no output.
The Environment is NAV 2013 R2, running under MS Server 2012.
I will post code if you like, but at this point, it is pretty much exactly the "PrintPDF" and "StartProcess" functions (minus the "Default Printer" stuff in 'PrintPDF')
I am using the same DotNet "assemblies" that are called out in the above thread.
Any ideas? HELP! QQ ](*,)
Experience is what you get, when you don't get what you want. --Anon.
0
Comments
It sounds like this could be the issue.
It was. Moments after I posted this, I ran across another thread that tangentially mentioned the "RunOnClient" Property for the DotNet Variables.
Changed that to "Yes", and VOILA!!!
It DOES verify that it was waiting for an "Ok" from another Universe, though. Because that RIDICULOUS "Do you want to allow...?" Dialog popped up when I ran the code "on the client". I think it was doing the same on the Server; but it had no intrinsic UI to display the dialog (???)
So, thanks to everyone who checked this out, and hopefully this thread will help somebody, since it DOES have a "Solution"
But it is always best to run it on the service tier, if possible.
Then you will avoid security popup and such.
You can use IF ISSERVICETIER to check if you are running on the server or not.
Don't use GUI prompt if your on the service tier.
Well, this is 2013 R2, so I'm not exactly sure when the "IFSERVICETIER" would EVER Return a FALSE
...and I was specifically trying to target a "No GUI" method, that ran on the Server (Service Tier). And when I actually DO run these on the Client, there is NO GUI (except for the stupid Security popup). But when attempting to run these DotNet "assemblies" (is that the proper term?) on the SERVER (Property "RunOnClient" = FALSE), then I get the HANG (which I am SURE is not really a "Hang", but some sort of "Callback" that will never come).