Printing from IE browser picking up wrong printing defaults

The way exists but you would need to hack FoxPro...

Easier solution is to change Windows default printer and restart the app before each printing (or start a new app derived to printing only).

These links will show how to do it: http://www.berezniker.com/content/pages/visual-foxpro/changing-windows-default-printer
http://www.news2news.com/vfp/?function=940

Another option could be to create a PDF file and print the PDF if the software respects the printer settings...

BTW, China hackers are still working on Visual FoxPro patches after Microsoft resignation... (http://www.baiyujia.com/vfpcompiler/en/default.asp)

Thanks.
I did try the PDF thing, and it works, but for our users, that was an "extra step" that takes up "too much time."
That means restarting the application isn't going to happen either.

Is there a way to assure that the selected printer sends its settings with the job regardless of what printer is selected as default?

Yes, assuming that your ERP system 'ticket printer' is the VFP Application - just temporarily change the Workstation's Default Printer.

Here is how one of my applications temporarily changes the workstation's default printer and then changes it back using Windows Scripting.

NOTE - I substituted "Zebra2844" for your label printer name in the following code.  Modify it as necessary.

* --- Determine Existing Workstation Default Printer ---
lcDefaultPrinter =  SET("PRINTER",2)

* --- Use APRINTERS() To Determine What Printers Are Available to Workstation ---
=APRINTERS(gaPrinters)

* --- Determine if Zebra 2844 Print Driver Is Installed ---
nLoc = ASCAN(APRINTERS,"Zebra2844")

IF nLoc > 0
   * --- Yes, It Is Installed ---
   * --- Use Windows Scripting To Temporarily Set Workstation Default Printer To Zebra 2844 ---
   lcNewPrinter = "Zebra2844"
   ONET = CREATEOBJECT("WScript.Network")
   ONET.SetDefaultPrinter(lcNewPrinter)

   SET PRINTER TO NAME (lcNewPrinter)
   
   * --- < Do whatever printing routines desired > ---

   * --- When Done Printing - Use Windows Scripting To Restore Original Default Printer ---
   ONET.SetDefaultPrinter(lcDefaultPrinter)
   RELEASE ONET

   SET PRINTER TO NAME (lcDefaultPrinter)
ELSE
   * --- No, Zebra 2844 Print Driver is NOT Installed ---
   * --- Do whatever ---
ENDIF

Select allOpen in new window

Good Luck

Thank you.
I'm not a programmer, so I need a little more guidance as to what you suggest.
If this is Fox Pro, I haven't access to the source code and would need to request a mod to do this globally. If this is not Fox Pro, then I would need explanations as to how I would integrate this script into the environment.

I don't pretend to be what I'm not nor claim knowledge where I haven't any. I only say this to ward off the "Holy Sh*t! You don't know scripting?"
No, I don't.
So, is it worth 500 points to provide a little education here?

OK, lets start at the "foundation" of things...

You mention a "Foxpro db" being involved - it "generates the print queues for the labels".  
How is this accomplished?
Is the Foxpro 'db' (actually "Application") the ERP system itself?

Or is the Foxpro application doing some other task(s) resulting in the generation of label information which is then utilized by yet another application (the ERP system)?

Good Luck

The entire ERP is written in Fox Pro. The formatting of the label is generated inside the application calling up the label (.lbx) file. This file sets the size, aspect, and form fields that appear on the label as well as what data is poured into the label.

On the 2844 side, the printing defaults are set to receive what the application delivers.
Attachment provided for more clarity. This one just happens to be for a 4 x 6 label, but the same topology applies.

Of interest, I do not have this problem with the 4 x 6 labels. That tells me something in the way the 4 x 2.5 is programmed is different than the 4 x 6. The vendor says they are the same. I have a shipping workstation that has the 2844 label printer, UPS 2844 label printer, local Brother laser and a network Brother laser with the local laser printer as the default. Never an issue moving from printer to printer.

That's the long and the short of it.
2844.jpg

jrbbldr just showed how to implement the code from www.berezniker.com... This code must be incorporated into your ERP application. If you are not FoxPro programmer then you have to find one.

BUT if two (or more) applications print incorrectly then it points to the Printer driver bug and your success is not ensured... Of course, you should try.

Pavel - how to implement the code from www.berezniker.com..

I've never heard of that site, but it is now bookmarked in my Browser for future reference.

AFrend - The core of what Pavel has suggested above is -- If you are not FoxPro programmer then you have to find one.

I might add to that - before you go out to hire a Foxpro programmer, determine if you have the source code  (PRG, SCX, etc. files).  Without those the programmer will not be able to work on introducing modifications.

In the absence of the source code files, you might contact the ERP vendor (if it was created out-of-house) and see if they will make the modifications for you.

Lastly if the ERP vendor no longer exists and/or the in-house developer is no longer around and there are no source code files, an application like ReFox ( http://www.refox.net/ ) can un-compile an EXE into its component parts with reasonable success.   That should give a programmer something to work on.

Of interest, I do not have this problem with the 4 x 6 labels. That tells me something in the way the 4 x 2.5 is programmed is different than the 4 x 6.

Unfortunately, not knowing how the application was put together, we can only make 'educated' (???) guesses.   A Foxpro programmer should be able to "dig in deep" and determine what is going on and why.

Good Luck

In general a foxpro application is able to print to any printer it sets previous to a report output. Foxpro reports can contain layout information, eg paper size/orientation, but it's a good idea to keep them out of reports (frx files) or labels (lbx files) to be able to print to different printers with their default settings.

A typical solution to your problem is to set up printers in windows with the appropriate settings, don't use the zebra as default, because the more common printing should be documents, not labels. But you can setup a printer more than once and let a printer name represent a certain setting used by printing to that printer name, even if it's physically the same printer.

VFP can then simply set the printer to the name you specify in printer setup in Windows while adding it, so all it's settings are encapsulated in Windows printer settings.

All the developer of the ERP solution would then need to do before printing is to SET PRINTER NAME (...) with the names you choose, that doesn't have to be the default printer, that even doesn't need to be temporarily made the default printer.

So in short, a task for the company maintaining the ERP system would be:
1. remove printer info from FRX/LBX involved.
2. enable a user to choose from the list of printers (in foxpro code that choice is simply a call to GETPRINTER(), networked situations are more complex, though) or make that choice automatically depending on the report type to print.
3. SET PRINTER TO NAME ... before printing.

That should be possible and shouldn't cost a fortune, depending on traveling costs, testing etc, of course.

Just from the outside you can't do much, if the application just prints to the default printer. You may use any language or script you or workmates are able to program to change the default printer whenever needed, of course, but that would need to run previously to printing in the one or other application.

Bye, Olaf.

PS: Of course there are layout size etc remaining part of the Foxpro Reports or Labels, which you don't remove in step 1 above.

And indeed you may even do the opposite and embed the printer settings into the foxpro labels to let them print to the Zebra printer automatically and only print to the zebra printer, no matter what is set as the default printer.

So I am basically at the mercy of the programmers of the application.
We just installed this application in November of last year.
The source code is not available to us as active customers.

I guess I will scare up a cheap Win 7 machine and see if the problem is still resident there. I suspect if the problem originates from the source code in the Fox Pro db, then it should replicate itself regardless of operating system.

Thanks to all...I'll assign points a little later.

I'll run that by the ERP company.

When I say that the Printer Environment (saved into the Expr Memo field of the label's first record in the LBX file), should NOT be Saved at all, that is because if the label's defined printer does Not exist on the user's workstation precisely named the same, then un-expected results will occur during a Print.

Or if it Does exist, but it is not the intended printer, then the printout will "appear" where not expected - also "un-expected"

However if No Printer Environment is Saved, the Print will go to the Windows Default printer.

Good Luck