Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Current printer?
Message
 
 
General information
Forum:
Visual FoxPro
Category:
Other
Miscellaneous
Thread ID:
00144671
Message ID:
00145995
Views:
38
In my application we have a printer setup where they specify which printer to use for which print jobs. Reports to one printer, Labels to another, etc..., and we store the printer names in a table. Depending on what kind of print job is being executed I issue SET PRINT TO NAME (appropriate name) then REPORT FORM...PROMPT. It will prompt with that printer regardless of the Windows default printer. Granted, this will not bring up the last printer chosen if they decide to use a different printer, but for the most part it makes for limited printer changing. One big drawback is that each computer must set up their printers with the exact same name or have a table specific to each machine on the network. That's my two bits on the subject. I agree, Printer is way too %&^*&&^&** hard to deal with!

Marcus.



>>>>Well, there you have it then. Create your own dialog that returns .T. or .F. to indicate whether Ok, or Cancel was pressed. Provide access to the printer settings in a button on the form via sys(1037). You could then have something along these lines:
>>>>
do form frmPrintDialog to llOkToPrint
>>>>if llOkToPrint
>>>>	report form .... to print
>>>>else
>>>>	=messagebox('Print cancelled')
>>>>endif
>>>>
>>>
>>>I'd be more than happy to do it that way, IF I could just show the current printer on the dialog. Like I said, M$ always leaves one piece of the puzzle issing...

>>
>>If by 'current printer' you mean the last one that was selected by the user in your app, you can save this info somewhere (registry, table, mem file). You could then have the info appear in your dialog form. Am I missing something?
>
>Maybe. What I'm looking to do is keep track of the "current to the app" printer. This is very different from the "windows default" printer. Apps that go changing the "windows default" are very bad apps, especially when you can do "multi-tasking" things. (Image if your VFP APP changed the windows default to a receipt printer and then you tried to print something from Word! Your users would be, oh say, less than happy.) The REPORT...PROMPT command does NOT save the setting that was selected for it beyond the current printing! It does not effect the "windows default" (yeah, good), but it also does not stay the current printer for the application. You must reselect it again the next time you issue a REPORT ... PROMPT command (bad, very bad). This is different then the action provided by SYS(1037). SYS(1037) doesn't modify the "windows default" but it does remain the "current to the app" printer, so all future "REPORT ... TO PRINT" commands go there. That is what I want, but I
>also need to be able to tell that the "selecting a printer" was cancelled and NOT PRINT. If you have:
>SYS(1037)
>REPORT ... TO PRINT
>
>you get a report no matter what button was pressed in SYS(1037).
>
>If you have:
>REPORT ... PROMPT
>
>you get a report if OK is selected, but you do NOT get a report if CANCEL is selected. This is what I want, but I need the printer that was selected to stay current.
>
>Like I said before, the SYS(1037) is almost there (persistant selection) but you have no idea whether to print or not. You can use Christof's CREATE REPORT...FROM and get the printer selected.
>
>REPORT...PROMPT is almost there (print/not print) but no persistant selection. You can not use the CREATE REPORT...FROM, it gives you the "windows default", not which printer was selected.
>
>I've looked at the Common Dialog Active-X and it has it's own quirks, the major ones being the "windows default" printer is always selected, regardless of the app's current printer, and you have no way of telling if OK or CANCEL was selected there, either.
>
>So, what I need is a way to determine the APPs current printer. GETPRINTER returns the current app printer, but I need to do it without their useless dialog. Why is this so f***ing hard!?!?
>
>Sorry for letting off steam...
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform