Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
My printer ran out of black toner and I didn’t have a spare, so I thought it’d be a good idea to “print” documents to .XPS files for now, then print them when the new toner arrives.
So, now I have my toner but I can’t work out how to print the files. I found this great post on Tim Barcz’s blog which seems to indicate I’m not alone.
I can open them and view them in IE, but if I try to print them it either ignores the command altogether or crashes.
I downloaded the XPS Essentials Pack from the Microsoft website and tried to install it, but it refuses to install and keeps crashing with a ten-page error message. Ironically, I would normally print this message out to deal with it.
My “solution” is to open the .XPS files in IE, then screenshot them and paste them into Paint Shop Pro so I can print them as graphics.
As Tim Barcz says in his post that I linked to:
That’s it…simple. What I don’t get is why people are so afraid to embrace new technology?
I have had no problems printing XPS docs from IE. The first thing that comes to mind is what OS are you running, what version of IE, are all service packs installed, etc?
Another option would be to copy the XPS files to a thumb drive (or send over the network) and print from another computer that does not have any issues.
Edit:
Follow up questions...Can you print non-XPS docs? Have you restarted the printer? Is your print spooler messed up?
I have had many instances where I could not print due to a bad print job clogging the spooler. Restart the spooler or restarting your PC usually takes care of this issue.
IE has an issue with printing XPS files to a network printer, is this a network printer?
The short answer to printing XPS is to use the "Microsoft XPS Document Writer".
This 'printer' gets installed when you install Essentials Pack/XPS Viewer on your system. IMHO, it is better to install the former. Note that MS has upgraded the EP from RC to 1.0 sometime back. So, probably, the problem you have is one of using the older EP. Now, downloading and installing the newer EP (i.e. EP 1.0) doesn't work always. The safest bet in this case is to manually uninstall the EP RC Pack, and then install EP 1.0.
Also, remember that you'd probably have to uninstall/upgrade the installed .NET runtime (or reinstall it). Oh, and then there is MS Core XML Services 6.0 that is required for MS XPSDW (the printer I mentioned earlier, remember?) to work. However, a quick look back at MS's site (http://www.microsoft.com/downloads/details.aspx?familyid=993C0BCF-3BCF-4009-BE21-27E85E1857B1&displaylang=en#Requirements) tells us this is supported for upto XP SP2. Check with MS to know if SP3 is supported as well.
In case you manage to get around all this somehow, you'd want to view the output of the prints you fire. I have the IE-tab extension on my browser and I open all XPS files using this one. Recently, however, I've heard that Pagemark has come up with a ff plug-in for viewing XPS files. You might want to check it out (http://www.pagemarktechnology.com/home/xps-test.html).
And of course, check out Wikipedia (http://en.wikipedia.org/wiki/XML_Paper_Specification)!
If you don't want to print to XPS, select another printer as the default one as indicated by previous comments. Also the XPS printer seems to have problems with margins or page size (some information are outside the A4 or too close to border to be printed).
Otherwise, when opening XPS files in IE9, the "File>Print" menu option is disabled. But you can use the keyboard shortcut: Ctrl+P
There are XPS to JPG/JPEG converters all over the web, pick one ;/
I had big problems with the XPS essentials pack, too.
After a lot of research and debugging I found the installation of XPS to be damaged somehow, and just scrapped and reinstalled the whole computer.
Afterwards everything XPS did work like charm.
So my guess would be: your XPS installation is faulty. Fix: reinstall. Workaround: print from some other computer.
With all due respect to the other answers, I believe you're overlooking the most likely cause and the easiest solution. The most likely cause is that the person's default browser is not Internet Explorer. The solution in that case is to open IE and type in the address of the xps file (e.g., C:\Users\Public\Documents\EVIDENCE\groupon.xps
Windows XP SP3, IE6, all up to date AFAIK.
I use Firefox mostly, so haven't updated IE for ages. Maybe IE7 would be more successful.
The point was that XPS is meant to be some kind of PDF-killer, but the difference is that PDF just works, while XPS has been a disaster. I don't mind errors, but I want it to tell me what is wrong, not just say it didn't work, as I can see that from the lack of pages coming out of the printer.
My answer: anytime you need to resort to 'steps' to resolve an issue that normally 'just works' in any other format, you have by definition gone beyond 'just works' to that place where you need to do work to make something 'just work'.
Related
Not a programming problem per se, but rather a programming environment problem that I have been unable to find a solution to.
The problem relates to Adobe's Extendscript Toolkit (both 3.5 and 4), but so far I haven't been able to solve the problem, so here I am...
The error I get has appeared more or less over night. I didn't experience this problem yesterday, nor this morning. But exactly WHAT has happened is beyond me. I have removed preferences, I have uninstalled, reinstalled, created a new user, restored old preferences from Time Machine and I'm now pretty much lost for options.
Basically, nothing works in ESTK anymore. Just opening ESTK and entering alert('Hello') won't work. Neither will $.writeln(). Everything running from within ESTK seems to give the same error;
Cannot execute script in target engine 'main'
With details:
Cannot execute script in target engine 'main'!
(#1116) Can't start debug session.
Below is a screenshot taken from the new user I created to test, same problem.
The "funny" thing is that all the scripts (InDesign CS5, still hanging on to it for reasons) still work perfectly in the applications' script panels. So there is nothing wrong with the scripts (heck, they haven't changed one bit, and still refuses to run in ESTK).
As mentioned, I've tried installing the ESTK CC (version 4) as well, but the very same problem occurs there. Which leads me to think the problem lies somewhere else, but I do not know where, and why.
So, if anyone can shed any light on this issue, at all, I would be very happy. Debugging is basically the only thing ESTK is good for in my book, but now that even that functionality is gone, I don't know how to efficiently debug the scripts which is kind of hampering the workflow.
For reference, I'm running InDesign CS5 (from the old Creative Suite) on a 2008 Mac Pro with 10.11.6 (El Capitan) installed. Well aware that it's pretty out of date, but that is beside the point here.
In the above mentioned forum, Adobe has published a stable workaround!You just have to correct a setting inside the estk application:
Open the file(Mac): “/Applications/Adobe ExtendScript Toolkit CC/ExtendScript Toolkit.app/Contents/SharedSupport/Required/cdic/11BTBackend.jsx”
Search for the value: 604800000 (line reads bt.timeout = 604800000)
Replace that value with 604800 and save
Quit ExtendScript Toolkit and relaunch.
I can confirm that it works.
From the adobe Forum :
"we have found a first workaround: just change your date to any date before 20-nov-2018"
https://forums.adobe.com/message/10761440#10761440
Seems like a date issue :(
I just published a quick update about this on the Adobe Tech Blog.
For the time being, if you dismiss the dialog, you can still run your script via ESTK and step through code as usual.
Alternatively, if you really want to avoid the dialogs, and you don’t mind setting your clock back, you can sidestep the issue by setting your system clock back to November 19, 2018 or before. On most systems, changing the system time can have unintended side effects, so this isn’t recommended unless you’re really certain about it.
A Visual FoxPro 9 program I support is not working on ONE SPECIFIC copy of Windows 10. Other users are working in Windows 10 without issue, but for this one user, all of the form labels are not displaying. Text boxes still work fine.
The program uses some ActiveX controls that are built in Delphi 6, and those are exhibiting similar behavior. Both pieces of the program are also sometimes crashing with divide by zero errors (again, only on this one specific install -- all other users from WinXP to Win10 are running fine).
I've tried compatibility mode and admin mode. I've validated that the install is complete and that the files are not corrupt. Any idea about what might cause this type of issue?
Wondering if you have checked that one user's display settings against the others. I ran into a situation where some text wasn't showing properly and I had to play with those settings.
Just got a notification from StackOverflow that this question has been viewed 1000 times, and I realized that the more complicated answer was never posted.
While Hank's suggestion was helpful for a few people, other people continued to crash even after playing with display settings, scales, zooms, and other things. While doing a screen share with one of the people who were crashing, I started comparing the screens that had text with those that did not. The fonts that were showing up were ARIAL, while the missing text was in VERDANA.
Windows 10 did in fact have Verdana installed, but FoxPro and Delphi couldn't display anything in Verdana. Eventually after a bunch of poking around, I found that Windows 10 had a new (possibly 4k compatible font?) for Verdana and forcing a reinstall of the older font package fixed the problem. Not a great "long term" solution, but people aren't crashing anymore... and we're rewriting the entire system for the web.
I have a VB6 application that I provide support for. This application works on both Windows XP and Windows 7. Some users were migrated from Windows XP to Windows 7 using the User State Migration tool. These users now receive a generic "Application has crashed" Windows error message when they open certain screens (forms) in the application. My assumption is that there is a missing dll/ocx reference, but I'm having trouble tracking it down.
I've tried many/varied troubleshooting techniques:
Full uninstall and reinstall of my application
Manually re-registering all dll's and ocx's that I know are used
Running Process Monitor on a broken computer and a working computer to compare what dll's and ocx's are accessed. The answer might be here but even after filtering out most of the background noise the amount of data is overwhelming. At a minimum I reviewed all of the calls right before it crashes and all of the calls that were not successful. All of the non-successful calls match between working and non-working.
Installed the Windows Debugger Tools and captured a crash dump. Analyzed the crash dump with DebugDiag. DebugDiag says the exception is in msvbvm60.dll. I tried building a PDB file for my exe and loading it in DebugDiag to get more detail about where the exception is occuring but DebugDiag doesn't want to accept the PDB (might be doing something wrong here, but it just seems to ignore it. This same PDB file works fine when I do remote debugging, however.)
I recompiled my VB6 program without any optimizations in PCode. I've read online that sometimes building in PCode, while bad for performance, will tell you the real exception.
Used the above created PDB file to remote debug the VB6 application. The debugger says that the application crashes after the new window has been created, on a line that sets MousePointer = vbHourGlass... To me it seems unlikely that this is the real cause of the error. There are at least 20 other locations in the program where this same line is called and all work fine.
(Forgot about this one)
Used Dependency Walker and profiled the application on both a working and non-working computer. All errors found by dependency walker were the same between the two computers. There were no additional dependencies found on a working computer, and all missing dependencies on the non-working computer were also missing on the working one.
None of these actions changed my error message or showed me what the error is (unless it really is the mouse cursor issue)... There are no entries in the Windows Event Log related to the app crash.
The non-working and working computers all have the same base Windows 7 image, the only difference is whatever is being changed by USMT, which further convinces me that this is some kind of quirky configuration change or a missing dll/ocx or perhaps an unregistered dll/ocx.
Any ideas or thoughts on how I can track down the root cause of the issue would be greatly appreciated.
Update 1 - Response to questions
#MarkHall I have tried running it as admin, though not with UAC off. The application runs fine on a Windows 7 box as a non-admin with full UAC. Windows XP was 32-bit, Windows 7 is 64-bit, but again it works just fine on a like for like box where the user was not migrated from Windows XP.
#Beaner It's possible that it stores settings somewhere that have been corrupted, but the remote debugging leads me to think that it's more likely something else since it seems to die on a step related to the UI, which then makes me think it's probably a missing dll/ocx reference.
#Bob77 The application is installed into Program Files (x86). While many of the libraries do reside in the same folder, they are all registered.
Peter, often I've noticed that the debugger will indicate a line of code that is actually incorrect, depending on WHERE in the actual assembly language the fault occurs. You should look REAL close around your statement that sets the cursor to vbHourGlass. Your exception is PROBABLY happening BEFORE that line of code, but that line is what the debugger thinks is the actual faulted line of code.
Since you said it happens when a window OPENS, I'd look real close at any ocx's you may have referenced on the form, but perhaps NOT actually being used, or called. You might have one there that you don't intend to be there, that could be causing security issues, or something on Win7? Edit the .frm file by hand if you have to, and look at all the GUIDs the form references.
It is possible that one machine is using PER-USER registration, and the other is using PER-SYSTEM registration?? I don't know...
I would take a much closer look at the form that you are trying to open, and be VERY cautious of everything you are doing in the form load events, and so on. This sounds like it could be something as stupid as Windows Aero being enabled on one system, and not another, or some other sort of "Theme" setting that is throwing the VB Form Rendering routine into a hissyfit... Perhaps even something as stupid as a transparent color index in the icon you selected for that from?
If you are still developing this app, (or at least maintaining it), create an entirely NEW form, and re-create all the controls, etc, on the form (resist the temptation to copy/paste them from the old one...), and then see if THAT does the trick. Then, copy all the event code to the new form one event at a time, with at LEAST enough event code to make the form function, even if it's just a "dead form", that loads no data, or whatever the form is supposed to do. Check and debug after each change, and you WILL find it eventually. Of course, make sure you isolate one of the defunct systems to have a platform that you can duplicate the issue on, or then it's just guessing. I find that using something like Acronis w/ Universal Restore is a great option to then take the image file into a good HV, like VirtualBox, and then restore that image as a VM, so you can debug without interfering with your actual users. This sounds like a lot of work, but then again, so is re-writing an application that already exists, right? :)
Failing THAT... /* and */ are your friends!! (Well, we're dealing with VB, so ' would be your best friend! heh... But I'd start commenting out all the code on the form until that sucker opens. Then once it opens, start putting one line back at a time, and re-running it... That's called "VooDoo Debugging", but sometimes, you gotta do what you gotta do...
THANKS A LOT PETER! :) Now you got ME so involved in this, I feel like I'M the one debugging this sucker! Like if it was MY code I was trying to fix! :)
Let me know if any of this helps... I am actually quite interested in what you discover.
Setup:
Several computers running FileMaker Pro 9 on Windows 7 Professional x64
FileMaker Server Advanced 11 on OSX 10.6
Office printers set up over TCP/IP
Seemingly at random, FileMaker will decide not to print. Regardless of whether the print job is called from a script or from clicking File -> Print, and regardless of which printer is selected, on occasion an error message will appear that reads something like
FileMaker cannot print, because this printer is not connected to a port.
Which is ridiculous. I can print from any other application when this happens, and a restart of FileMaker seems to clear up the issue. There are no issues with any of the printers in any other applications, and this only happens once in awhile... but it usually decides to happen while I'm out of the office and a customer is waiting on an invoice.
Trying to print from any printer results in the same error message showing up.
I am having trouble reproducing this error, too... which makes it even more difficult to diagnose. It has happened on several computers now, too (all of which have almost identical hardware and are set up similarly).
Any suggestions?
It sounds very odd that File->Print does not work, however if you're using printer settings stored in scripts you need to make sure that the saved printer is named the same on all workstations.
For anyone else looking into this, there is a partial solution of sometimes setting Filemaker to run in Compatibility Mode. But I've bumped into this issue frequently with FM and it is one of the most annoying issues with this platform.
I'd recommend looking into a printer plug-in. FileMaker has always had problems with printing and I think you'll find that you have much better control and consistency with a plug-in.
I've used a few different ones and haven't found that any one is more stable than another but I feel that Dracoventions plug-in is the best for the money.
I have been looking into the possibility of creating a soft copy(image/EMF file) of everything printed from Windows - for archival purposes. Does anyone know if it is possible to create a hooking DLL that can grab the printed data in such a general way?
A low tech way of solving it might be to install pdf printer driver as the default printer and remove all others and set it up to automatically write all the files to certain directory on the network and then write a tiny app on another computer to monitor that folder for changes and if any new pdfs appear just print them out to a real printer.
Edit: Otherwise there's apparently something called the Print Monitor API. Here's an article that describes using that from VC++ 6 and seems to be pretty much what you want (assuming it's still supported by the OS you use).
Having looked at this problem in more detail the best solution seems to handle it through Spooler notifications in the Win32.