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.
Related
Recently installed AutoHotKey to remap some keys in order to play a video game. It seemed simple/attractive enough at first. Was not really sure of how it worked but found the .chm file in the download which states in the first line of Usage & Syntax/Using the program:
AutoHotkey doesn't do anything on its own; it needs a script to tell it what to do.
Sounds 'secure' enough to me. Seems like mature software. Maybe overkill (now I know it certainly was overkill) but let's just see how it works.
My remapping was simple enough: change the AWSD keys for the LEFT-UP-DOWN-RIGHT keys. Script syntax is simple enough, just used an example that comes with the install files. Works essentially as expected. Got an annoying pop up after playing the game for a bit from AutoHotKey saying "you've pressed mapped keys 600 times" or something like that. Which was only a little annoying, so I ignored it the first few times. The game I play is real time so getting a even a 5 second interruption while in a match would mean certain loss, so I decided to just disable the script and uninstall.
Lo and behold: when I stop the script, the keys continue to be remapped. Was there some background process running? Maybe. I rebooted only to find that on my Windows login screen my keys continue to be remapped. Huh? Did AHK mess with some registry bindings or something?
I do not know that much about how Windows works, but my vague recollection is that registry bindings is something is active once the OS is active. I search on the web for say 1 hour before I give up for the time being and I end up activating the script again in order to write normally. This works as expected and I literally forget about it until any time I have to reboot.
Honestly a minor annoyance, but due to the world changing very quickly I lately have very few precious minutes that I can actually sit down on my desktop, whereas I used to be able to spend hours on this type of computer issue in order to get to the bottom of it. In other words, my current solution felt good enough. But not anymore. I think something more serious and possibly nefarious may have occurred. I don't want to seem dramatic but I just discovered something else a few minutes ago.
I have a Linux installation on another drive and I just happened to want to load it up after my last Windows blue screen (have gotten a couple of those lately, literally 2 in the space of 2 days and this had maybe only ever happened once before, like 2 years ago, so I am a already concerned about a possible deeper issue). My firmware/bios has a password and guess what I found when I tried inputting it: the keys were still remapped.
At this point I am at a complete loss. I didn't even think this sort of thing was possible. Some OS level software caused a change that was able to be reflected on the bios? Did it affect the keyboard driver? A driver that both windows and the motherboard bios use?
What else have I tried or looked at:
Device Manager claims my Keyboard has 3 instances of "HID Keyboard device". Not entirely sure why it shows 3. Properties show it has 2 driver files: kbdclass.sys and kbdhid.sys, which I suppose are some standard drivers. Not sure how to proceed.
My keyboard is inland (cheapest i could find at microcenter) i am not sure why I cannot find the website for that company. Found some drivers on reddit but they are on some sysadmin's google drive. I will download that exe when i am desperate...
UPDATE
I 'solved' the issue bye getting another keyboard (an old IBM KB-0225) and everything is now in order. I tried disconnecting the Inland keyboard and reconnecting, but after reconnecting I was still experiencing the same issue.
I don't know if I should close this question as there is no longer an issue, but I would like to see if anyone has any other additional theory as to why some software/driver changed occurred inside a keyboard device. As far as I knew, these devices have not internal memory other than possibly some logic gates.
There must be a background process running.
to check that:
note : For windows 10
On your taskbar, click on the ^ button (skip this step if there is no such button)
right-click on the sign.
click on "exit"
If the above steps do not work, try keeping a watch all the time, to see if you notice something uncommon.
I have a program that extracts text from PDFs. It runs as a scheduled task on Windows Server 2008.
The library I use is ByteScout's PDF Extractor SDK, which is based on Tesseract under the covers.
Since it went live last November, the program has successfully extracted text from over 50,000 PDFs from many different sources.
It recently hung on a single PDF and subsequently on a second one, from the same source in the same visual format.
I am able to recreate the problem using a trivial 12 line program. I sent this program to the vendor but running that program in their environment works (it does not hang).
So I did some experimentation and this is where it gets strange.
The program works on my PC (Windows 7) if I RDP to it, but not if I am directly logged in. This behavior is repeated on other Windows 7 PCs in our environment.
It works on Server 2008 if I am RDPed, but not as a scheduled task.
It works on Windows 10, whether I am RDPed or logged in directly.
If I watch the program in Process Monitor when it is stuck, I can see that it is opening and reading C:\Windows\Fonts\times.ttf over and over again.
If it was only working using RDP, I'd wonder if the cause had anything to do with failing use of graphics acceleration or some such, but given that it doesn't work as a scheduled task where none would be present either, I think that's a blind alley.
Does anyone have any suggestions where to look next?
So ByteScout have fixed the problem. To quote Eugene on the cause ...
The problem is in System.Drawing and GDI+. Sometimes it crashes on text drawing operations that are normal in PDF but causing some internal exceptions in System.Drawing. Moreover, it's behavior varies depending on display device capabilities. That is why it works in RDP session and crashes on a desktop.
We are trying various workarounds on these crashes, attempting to fall back to alternate text drawing ways. The hanging is related to these fallbacks.
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 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.
Windows XP Embedded is missing the NULL or "NUL" device. For one thing, Visual Studio seems to require it and trying to build a project aborts with a PRJ0015 error.
Anyone know how to configure an XPe image to include support for the NUL device?
"Null Device Driver" is available in the XPe Target Designer, but it's normally hidden. Apparently each component has a visibility level, and if it's lower than that set in the Target Designer options (Tools->Options), it's hidden. Null Device Driver is at level 200, so I set the level to 100 and could see it and install it.
There's another important situation where you're going to want the NUL device: if you're installing some or all of the Cygwin UNIX solutions for Windows. In particular, if you're doing something like, oh, I don't know, to pick a completely random example, trying to put an SSH server on the damned thing so you can, just on a lark, say, log in and maintain it.
That's right-- Cygwin actually maps its UNIX /dev/null device to the Windows NUL device. You know, for maximum compatibility. Just in case the platform-specific implementation of IMMEDIATELY THROWING DATA INTO THE TOILET AND OBLITERATING IT, NEVER TO BE SEEN AGAIN, UNTIL THE HEAT DEATH OF THE UNIVERSE, happened to be novel and innovative.
While cygwin will INSTALL without NUL available, it will not, in fact, actually enjoy a typical work day. This is most evident the first time you try to launch a bash shell, and notice a slew of error messages about /dev/null resulting in no such file or directory errors. One presumes the device is perhaps actually just an NTFS link, but who knows.
In any case, the fix is to add the "Null Device Driver" component, helpfully located under Software -> System -> Other, a surprisingly small category which also contains such useful components as Internet Checkers, the Schedule Service Command Line Utility, the 1394 Kernel Debugger Support Library, EBCDIC support for Microsoft Bob, some cheat codes for Zork, and the code pages to say "(A)bort, (R)etry, (I)gnore, (F)ail?" in Muppet Swedish ("(B)ork, b(o)rk, bo(r)k, bor(k)?")
Hope this helps,
Matt "Breakpoint" Heck
Running Visual Studio itself on XP Embedded doesn't seem like it'd be supported. You should build on a full OS and then just deploy your application to XP embedded.