erratic behavior--Help!

[Stuart McLachlan]

"win2K 16bit". 32 or 64 but not 16

Probably 32bit so you can still use 16bit software. (similar to how you can run 32bit software on 64bit Windows)

So the Company Pres or IT guy thinks that installing 20 year old, unsupported, workstation software on your primary server is a good way to "prevent any hacking"?

And you are responsibe for developing their software? I'd be looking for a new job somewhere else

[Ellen Reddick]

I begin this post with an apology. I don't know all I should know! Company pres insisted on doing whatever scheme necessary to prevent any hacking. So, IT guy has set up new server on new computer running win2K 16bit, if that is possible and if I understand him correctly. New win10 computers log in to the virtual server where the programs and data reside. All seems to work swimmingly, with one small exception (so far--not all of the new computers are installed, just the order input people and office). I have it set up so any of the myriad of reports and labels for an order can optionally be viewed onscreen. That is what they do if circumstances call for a replacement zebra label. That way they don't need to reprint 75 labels just to get one. Only one of these input computers can now select the page view with the to-be-reprinted label, select the zebra attached to that computer through the Windows installed printer dropdown and print it. When the others try it, it does nothing. I assume Calvin will eventually be able to work that out--guessing it has something to do with the print servers attached to the individual computers. At least it isn't a program problem. At the moment, everyone is running on PBCC4 version since PBCC6 seemed to be more problematic. I finally have the code for the two compilers interchangeable, so I am not trying to maintain two versions. Today, they tried printing to zebra out of the PBCC6 version, and it still stopped halfway through (29 out of 40 printed) with no error indicated--just stopped. I was so sure after the new computers/drivers were in that all would work. Obviously PBCC6 sends out something different to the zebra.

[Bud Durland]

When you consider to port your software to W10 PC's, keep in mind that the LPRINT ATTACH command generates a Device Unavailable (#68) error.

That has not been my experience. We do a lot of printing where the connection is done through LPRINT ATTACH. 99% of it nowadays is LPRINT ATTACH \\server\printerqueue, or to an LPT port that has been created using a NET USE command. Very few modern PCs have real hardware LPT ports anymore.

[Joost Kant]

When you consider to port your software to W10 PC's, keep in mind that the LPRINT ATTACH command generates a Device Unavailable (#68) error. I solved it by using XPRINT to an Generic Text Print driver. But got lots of misprints then. Solution to that problem was to use en empty line at the beginning, and all Field data (text or barcodes) on separate lines e.q. XPRINT commands. I now can say goodby to the 17 year old XP PC's. Our printers are networked and shared.

[Bud Durland]

XP virtual machine[/B] on their Win7 computers from which both the old (PBCC4) and the new (PBCC6) are running accessing the data from a server.

Were I on-site, this is where I'd begin by taking the VM out of the mix. Using other apps (Matlab, some ladder logic stuff) in an XP VM on Win10, we've seen some goofy behaviour with the virtualization of COM and LPT ports. (yes, 'goofy' is the correct technical term), but not so much with network connected devices -- thought virtual networking and nat-ing can bring on it's own headaches. I still haven't heard how the printers are connected to the PCs. With respect to the HP lasers, are you using XPRINT?

(sorry for the delay, I was on vacation last week, and purposefully off the grid as much as possible)

[Walt Decker]

look in PBCC60\WINAPI for pbcc6 headers and PBCC40\WINAPI for pbcc4 headers.

One thing you might try for comparison is changing the .inc path in pbcc6 to point to the pbcc4 headers.

To do that go to the Window menu item, click on options, then click the little square next to the inc file edit box.

[Ellen Reddick]

Customer has gone ahead installing all new computers and using PBCC4 code. They are double-entering (Win 10 and Win 7) just to be sure all works as it should. Zebras are now set up as network printers and are printing happily. The goal is still to transition to PBCC6 code, so I will have to solve the printer problems there. Michael, how do I find the Windows Header files? Please pardon the naive questions--it has been a few years since I was immersed in this stuff and the world moved on without me! Have to admit I am somewhat enjoying getting back into it--brain needed the exercise!

[Michael Mattias]

The very same code compiled in PBCC4.04 and PBCC 6 on the same computer do different things re printing.

The compiled code will not be the same.

But assuming the same main source code...
Do they use the same Windows Header files? Using different headers can result in different performance.. and if you don't do good error handling you probably won't find the problem easily.

[Nick Luick]

Ellen post #1.

Have you tried running an older version of your compiled code on your Windows 10. From description your newly compiled code is failing, also when used on customers computer (Windows 7) XP mode. When did your Windows 10 last update.

Looking at specs for Zebra 140xiIII Plus its a 32 bit Risc processor and comes with parallel, serial, and USB ports, its XP unicode compliant.

https://midcomdata.com/zebra-140xiii...i-refurbished/

I'm thinking of corrupt disk area, virus, or WIndow's update. Do you have another computer to install PBCC4 on.

[Ellen Reddick]

Bud, thanks for your willingness to help. I will do my best to describe the setup. Easiest to describe is the secretary who prints the invoices. For 15 years she has been printing to local printer which is currently an HP Laser with I assume the proper driver for her current Win 7 computer. All employees were set up with an XP virtual machine on their Win7 computers from which both the old (PBCC4) and the new (PBCC6) are running accessing the data from a server. Old works, new has problems printing the whole job (same job, both programs running from the same virtual xp to the same zebra). Since printing to the HP has similar problems to those encountered printing to Zebra, it makes me think the problems are related although I cannot imagine there is any difference in the data stream to the printer for any given job. I live in another city and do most of my work remotely so I am at a disadvantage knowing all of the connectors. The fact that the computers and server are no longer supported by Microsoft is the reason for replacing all of the computers, server, etc. as well as my decision to move to a more modern compiler. Hence PBCC6 (baby steps! Besides they prefer the down and dirty data input environment). The idea was to have all of the new computers in place by Monday and run parallel for a couple of weeks to be sure all the kinks are out. Without the PBCC6 being able to print properly, they will have to rely on the old version. To answer your question about zebra connections: the one all the experiments were run on was on lptport (I think). Zebra guy and Calvin (IT) spent 5 hours trying various drivers and never got new version to print more than 15 in a job before it stopped. The old version had no problems. Keep in mind that the zebras are so old that Zebra hardly acknowledges them (140iIIIplus), but have never been a problem before this.

[Bud Durland]

I'll help where I can, but need some more information first. I want to make sure I'm clear on the environment. When you say "new system", is that the program compiled with PBCC6 on Windows 10 machine, vs. the "old system" which is the program compiled with PBCC4 on windows XP? Does the PBCC6 executable show these symptoms on the XP hardware, and/or does the PBCC4 executable behave well on Windows 10? In both cases, it would help to know exactly how the printers are connected.

All the programs we have at work are PB/Win 10. I talk to the label printers directly over serial (only occasionally using XPRINT), often in batches of 100 or mre. Laser chores I complete with a 3rd party library called Virtual Print Engine (VPE), which I highly recommend. I've not experienced the phenomena you are describing.

[Ellen Reddick]

Don't know where to go from here. The very same code compiled in PBCC4.04 and PBCC 6 on the same computer do different things re printing. The PBCC4 prints all files correctly on both Zebra and HP. The PBCC6 cannot finish a long print job to Zebra or to HP Laser printer. They may run off 75 or so invoices on the HP Laser in a day, requiring printing 200 or so sheets of paper. On the new system, they can get through 30 or so sheets before it stops and they have to turn the printer off, back on, clean the buffer or ? and then it continues where it stopped, only to go through the same things another time or two to finish the print job. Running the older version, it finishes the job with nary a hiccup. I've been blaming the Zebra driver, but somehow begin to question if there can be something different in the files output by the two compilers or something I have yet to imagine. Any ideas greatly appreciated!

[Bud Durland]

At the suggestion of the Zebra guy I removed the "${ }$" brackets and had the one Win10 computer still in service try to print to the zebra. Printed just fine without the brackets, although it stopped after 27 of the 60 labels in the job.

The pass through codes come into play when your print stream is being processed by the printer driver. When you can connect via a serial or real parallel port, the ZPL code is going directly to the printer. This is in the fragments in my code that start with IF isLPTPort and IF isComPort. But, if you look at the block that uses XPrint, you'll see this:

 XPrint "${" & LabelData & "}$"

The code wraps those pass through codes ("${" and "}$") around the ZPL. With the pass thorough enabled in the driver's advanced settings, your ZPL stream is passed unmolested by the driver to the printer. Without those pass through codes, the printer driver intercepts the ZPL and tries to print it as text, which produces gibberish -- well, gibberish to most people, but those of us who've had to wrangle these printers over the years can almost read it

In an earlier post, I think you mentioned parallel converters. I've never had good luck with them. Most of our Zebra printers are connected either by serial cable (the most reliable), or we put a cheap print server on the parallel port of the printer, and set it up as an IP printer on the windows station. In the latter case, we install the ZDesigner drivers, enable the pass through and they work flawlessly. With the serial port connection (and parallel for that matter), no driver is required at all.

[Bud Durland]

Bud: Dumb question:
%MB_OKMODAL is an undefined equate. Where does it get its value? Won't compile.

What Dale said. In my library of code equates, I define %MB_OKMODAL as an or (or +) of %MB_OK and %MB_APPMODAL

I thought I had groomed out the non-standard stuff. Maybe I've been using that so long, I just forgot. Sorry for the confusion.

[Ellen Reddick]

So, how to combat over-running buffer memory? Sounds exactly like what is happening. Can long enough pauses (see my previous post) take care of this? I suspect they are using parallel converters.

[Dale Yarker]

Did you determine parallel, serial, USB or USB psuedo serial yet?

If Win 10 computers with USB to serial (or parallel) converters, they could be ignoring the hand shake line and over-running buffer memory in the printers.(new computers don't come with real ports anymore, just USB)

Cheers,

[Dale Yarker]

To convert Bud's code to PBCC replace the MSGBOXs with PRINTs and print the strings. Forget %MB_OKMODAL.

[Dale Yarker]

I cannot put in Bud's code until someone tells me about the %MB_OKMODAL,

Bud put PBWin code. And there is no such thing as %MB_OKMODAL in PBWin either.

[Ellen Reddick]

The Zebra printers are 140iIIIplus printers -- obviously been workhorses there for a long time and I can understand that drivers that marry Win10 to such old equipment isn't top on Zebra's list of things to do. The Zebra expert (sales rep) and Calvin tried all drivers they could find including a Seagull driver. My client company is having such trouble getting out orders that Pres has had them put the ancient Win7 computers back on the Customer service desks and they are now running the PBCC4 version in a virtual XP window in order to smooth out operations. They have always run in a virtual XP machine to be sure hackers could not access company data--at least I think that was the reason. At the suggestion of the Zebra guy I removed the "${ }$" brackets and had the one Win10 computer still in service try to print to the zebra. Printed just fine without the brackets, although it stopped after 27 of the 60 labels in the job. I cannot put in Bud's code until someone tells me about the %MB_OKMODAL, but logic tells me that it isn't the PBCC6 program at fault or it couldn't be printing anything correctly. Also, the point where it fails isn't consistent. I still don't understand why sending the screen print of the labels to the zebra works--what does that do that I cannot do from my code? Also, thinking a timing issue must be the cause, I tried doing a

' SLEEP 3000
' XPRINT CLOSE
' SLEEP 1000
' XPRINT ATTACH zPrinter

after every 15 labels and that made no difference. There just has to be a solution somewhere, as I cannot imagine this is the first time this printer has been used on a Win10 machine.

[Dale Yarker]

Bud: Dumb question:
%MB_OKMODAL is an undefined equate. Where does it get its value?

No where, or made up for that bit of code.

MSGBOX is PBWin not PBCC, so it will give you problem anyway.

Two of the styles for MSGBOX are %MB_OK and %MB_APPMODAL, they're either ORed and that code not included in sample code, or it is a big typo of the style names.

(not a dumb question)

Cheers,