I am using my antique Borland Builder 5 with Windows 7 64-bit.
fptr=fopen("\prn","wb") fails. "prn", "prn:" also fail.
fptr=fopen("HP8 lj4","wb") succeeds. But doesn't print anything. The "HP8 lj4" is the name of a printer; in control panel, or via "net view hp8gig".
The console command { print /D:"HP8 lj4" shopping.ln } says "shopping.ln is currently being printed" -- but doesn't print anything either.
Of course I print things on that printer all the time. My beautiful ASCII TSE editor can do it.
Anybody know how to print from a console program in Windows 7?
//Monday, September 12, 2011 5:29 pm. Later I realized my "HP8 lj4" was printing to a file with that name. And I tried to comment here, but apparently failed....
Tue 9/13/2011 4:05 pm. The way to print from a console "prn"-oriented program in Windows 7 et al is "net use lpt1: \hp8gig\UrPrinter /PERSISTENT:YES". "UrPrinter" must be "shared". And that's all it takes; my wretched little console program prints fine now. One reason I got confused, aside from natural talent, was that the desired printer was local. It was attached to the computer -- but via USB. After doing this, a command-line like "copy file /b prn" prints.
I knew this before apparently -- I found it in a "printnet.bat" file I wrote, to access a network printer from another computer -- but obviously I forgot.
So the code from the web site I mentioned before was broken -- a few typos -- and even when it worked, didn't. Which is to say, I still don't know how to programmatically do the "net use" thing.
Mon 9/12/2011 5:49 pm. OK the general problem is how to redirect the revered &
antique "PRN" device on a windows 7 machine to something useful. I don't know
how to do that. A fellow at
http://comsci.liu.edu/~murali/win32/NetworkPrint.htm has some code which looks
like it might make PRN print again, but his plan also suggested trying the
network name of my desired printer in my silly program -- and that works.
I.e., I stuck in code like
if (stricmp(name,"prn")==0) {
name =
#if W7
"\\\\hp8gig\\HP8 lj4"
#endif
}
I can make something more sophisticated with an environment variable, or
perhaps I'll figure-out the fellow's PRN thing....
Related
I have a printer, an HP DeskJet 712C, shared via a Windows XP workstation. I am able to print to this printer from various applications, but I am unable to print to it (from the workstation the printer is attached to or any other) via the PRINT shell command. I have a Perl script, currently hosted on a Windows 7 workstation, that generates text files. I would like those text files printed to the aforementioned printer, but as I am unable to use the PRINT shell command, I don't know how. How can I print these text files to that printer in Perl?
I don't know much about windows programming, but there are a couple of options I can think of.
Printer - There is a module on CPAN called Printer that claims to handle windows printing. I haven't used it. YMMV, but it looks like exactly what you want.
Wx - The Wx GUI toolkit has nice, windows compatible printing capabilities. It, sadly, is also a huge, complex dependency to add just for a simple command line script. I have used this and it works very nicely.
Win32::API - Here's where my Windows ignorance really shows. The Win32::API module lets you call into windows DLLs. If you know the appropriate functions/DLLs to use, you could access them to get a print job started.
Update
You might want to check out this thread on ActiveState's Perl-Win32 users' list.
Apparently you can just do:
open my $prn, '>', '//mycomputer/PrinterShare' or die "Oh noes $!";
print $prn "Here's some text to print.";
This is untested, untried, and maybe untrue, but give it a shot. What could possibly go wrong? Printers are cheap these days. ;)
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've asked the very same question here :
Why does my program say "folder does not exist" when run on Windows 2008?
but none of the answers were satisfying and my problem still exists , so I decide to ask it in another way with more detail cause this problem really irritate me and we need to solve this , otherwise we have to write the similar application in another language which means waste of our time.
program written in delphi 7(32 bit)
environment running this program is : windows 2008 r2 64-bit
the task program try to do : creating 3 folders then copy an sound file and compress it using lame commmand line (lame.exe) and save changes into database
error I get : "THE 'folder' does not exist . the file might have been moved or deleted , Do you want to create it?" and it cause the program become halted
things I have done :
1- try to run the program as an administrator
2- check eventlog but no clue
3- triple check the required folder and all of them was correct
4- read this KB: http://support.microsoft.com/kb/927387
BUT still I am seeing this bloody error.
I have uploaded the picture of the error here as you see it clearly :
http://i28.tinypic.com/9to6qr.jpg
The folder name is C:\Upload_ABC\\2010\07\27\:
please notice I haven't written that unwanted dialog-box inside my program I believe windows 2008 attach it or bring it on my application.
please please please give me some idea or let me know what should I do ?
best regards.
C:\Upload_ABC\\2010\07\27\
You have two backslashes in your path. Use debugger to see why.
Have you checked the access rights for that folder structure with regard to the account the Delphi program is running from? Windows Server systems tend to be more restrictive in what a user is allowed to do than Windows on workstations are.
In addition I suggest to strip down a copy of the program to the relevant functionality to show the error. With this you get at least a chance that anyone around may test it on another system.
Furthermore you can try to compile it with D2010 and see wether the error persists. If it does, you might have a chance to find the problem running the D2010 debugger. If you don't have D2010 at hand, you might install the trial just for this purpose.
What is between the two consecutive backslashes in your path? Is there really nothing between them or have some characters been removed because they are Unicode and D7 doesn't support Unicode?
As there is nothing in between the two consecutive backslashes...
It does sound like Windows is getting its grubby little fingers in between your program and your access of the files. Either the folders have not been created, or you are being denied access once they have. And as the changes you are trying to store in your database involve compressed files, virtualization seems to be the culprit as explained by the link you yourself provided.
A couple of avenues to try:
Remove any compatibility settings on your exe (right click|properties|Compatibility tab) that could trigger Windows to butt in. Also don't forget this can be triggered by things like "setup" or "update" as part of the executable name.
"Save your application's data in a folder under your user profile."
Such as c:\users\\documents or some such (better not hardcode it in actual production code, but ok for debugging). That after all is exactly the advice the linked msdn article is giving for scenario 2 "you cannot find the files or folders you just created"
If you can't debug on the machine where it is running, go back to old school debugging: add trace messages to your code to show where in the code you are (and have been) and show them in a memo on a separate form or some such.
Make sure you don't "eat" any exceptions that could give you extra information about what is going on.
Can someone explain the difference between calling a perl script via file association versus calling the same script explicitly via perl.exe?
Apparently I/O redirection doesn't work very well when the script is called via file association, and I would really like to know why.
E.g. take a look at the Activestate FAQ for Perl on Windows. The cat file example works perfectly as long as the script doesn't receive its input via redirection. So
cat file.txt
works as expected, but
whoami | cat.pl
does not. Not only is the .pl extension needed, but apparently the output of whoami isn't piped into the script. The script is run (which can be verified by modifying the example cat.pl script), but for some reason it doesn't receive the output of whoami as input.
However, if I call the script like this:
whoami | perl cat.pl
everything works as expected.
So apparently there is an important difference between running the script via file association and explicitly calling perl.exe with the script.
The FAQ mentions the problem and points out that using pl2bat to generate a bat file cover for the script fixes the problem, but I don't understand why this is necessary.
Please enlighten me.
It looks like it was a known bug in Windows 2000: STDIN/STDOUT Redirection May Not Work If Started from a File Association.
I get the same behaviour you describe with Strawberry Perl on WinXP, however once I created the registry entry described in the above article (even though the reg entry is targetted at Win2K), stdin works as expected.
For completeness, in case the link above goes away, the reg entry it suggests creating is:
Start Registry Editor.
Locate and then click the following key in the registry:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer
On the Edit menu, click Add Value, and then add the following registry value:
Value name: InheritConsoleHandles
Data type: REG_DWORD
Radix: Decimal
Value data: 1
Quit Registry Editor.
Edit: I ought to add that even though the KB article claims it was fixed in XP SP1, I've got XP SP3 installed. So whether MS have broken this, or never fixed it completely, I can't say!
I know this is an old thread, but it's important to note that Microsoft appears to have reversed the polarity of this setting in Windows 10. No idea why they would do that, but this had me pulling my hair out for a day. See my other posted question (Perl Scripts on Windows 10 run from Explorer but not Command Prompt), and especially the linked MSDN post there.
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.