Printjob to Epson TM-T88V swallowed with VPEP6.1.1. SR1

[DDTech]

Hi

I'm having a problem with the current VPE-Version (OCX, 32bit. Version 6.1.1.7041) that I use to print receipts on an Epson TM-T Printer if I don't show them in a preview first.
With an open Printer-console I can see the job arriving and being dealt with as if everything were fine but the printer never starts to print. Happens on Win7 64bit

when I unregster the ocx, replace ocx and dll with the previous version (V. 6.1.0.6508) and re register those, it works immediately.

So there must be either a change between those versions that requires me as a developer to change something in code or something with the newer version is weird.
I have no idea where to start in order to get that fixed.

The .dep-File seems to be the same for both versions, but I can't see why this should be a problem.

Thanks in advance

[IDEAL Software Support]

If you create a VPE document file from your document, open it in VPEView.exe and print it, does it happen also?

[DDTech]

This happens on a live cash register that I only have access via remote and during the daytime. I sent out my last TM-T for that particular installation, so I'm currently unable to properly check and analyse the cause.

This is the second installation I had this issue with. Last time (some two months ago) after hours of trying, I ended up installing a previous version, that I then brought to the current one via updates (which do not have the activeX controls unless there are changes). I did not relate the problem to the vpe components, especially as the difference is "only" a service-release.
At that time I thought the problem results from the printer port. Since about a year and a half, the USB-Port needs to be activated manually in order to work properly. The factory default is an autodetect setting that works well only randomly. I spoke to Epson technicians who confirmed that there is a good amount of potential for improvement

Funny thing is that it seems to work, when I preview first. I can "reprint last receipt" which does not work. Alternatively I can go into a "receit history", select an invoice, optionally preview and print or print directly. Preview and print works, print directly not.

[IDEAL Software Support]

Our own tests last year with the TM 88-IV did not show any problems. Check the configuration of your machine, of your drivers and your settings of page dimensions in Windows (in the driver, i.e. any pre-defined page formats?) - as well as in VPE.

Do NOT use the properties DevPaperFormat, DevPaperHeight or DevPaperWidth.

Do only use the properties PageFormat, PageWidth and PageHeight.

Funny thing is that it seems to work, when I preview first.

From VPE's code and program logic, there is no reason why previewing should affect printing. Not a single one. This is, as if you said that full moon makes printing work.

I am sorry, but you need to provide a fully reproducible case. This implies that (1) any side effects from your code are eliminated (hence my suggestion to print the document file using VPEView.exe), and (2) if it can be reproduced using VPEView, to send us the VPE document file for analysis. Please note that we charge our working time for support, if the problem should not be caused by VPE. This includes defective printer-drivers as well.

[DDTech]

there is no reason why previewing should affect printing. Not a single one. This is, as if you said that full moon makes printing work.

That's what I said, also from my point of view there is basicly no difference... must be the moonlight

I am sorry, but you need to provide a fully reproducible case.

Yes, I know. does not make much sense with all the code at hand. So for You it must be almost impossible to find a diagnose if not there is something You changed between both versions.

Do NOT use the properties DevPaperFormat, DevPaperHeight or DevPaperWidth.
Do only use the properties PageFormat, PageWidth and PageHeight.

Actually there is some DevPaper... stuff in it, because it used to be necessary in former versions/situations. I just checked. However the devPaper... stuff only is executed if a pageHeight >0 is selected in my configuration files. which currently is not the case - So none of these lines should be executed in the current configuration. - But good to know I should not use those.

I just had a chance to remotely log onto the computer and they were not very busy. So play a bit. I unregistered the 6.1.0 moved it away and replaced it with 6.1.1 again this time without the deb.file .... Seems to work now. Maybe the moonlight... I'll have an eye on that and will keep You informed if I learn somethin more about this issue.

.... One thing... I Also have a very old version 3 that I install with the setup, because there is one single report that still uses it. Has never been a problem so far, but maybe the new version does not like to be installed with the other one in that specific order ...

Anyway, thanks so far

[IDEAL Software Support]

Since v3.0 (back in 1998), all versions of VPE can be installed and used safely in parallel.

Service Releases replace older releases of the same version.

[DDTech]

Thanks,

unfortunately, the client called on friday afternoon claiming that several reports do not get printed .
So I had to switch back to v. 6.10 which solved it immediately.

I'll see if I can build a version that allows me to create VPE-Files for debugging reasons.
But as I am only changing the ocx. and the dll, there must be something in the process of sending to the printer that has been changed between 6.10 and 6.11 and I would be grateful if You had an idea what that could be.

Concerning the devPaper.... settings I'll have to re-check that it's not being used anywhere. But why should I not?
I remember that I had a good amount of struggle with the slip paper formats a few years ago and only managed to solve that using the devPaper-stuff.
I'm afraid of touching this code - especially with no printer at hand.

Thanks

Frank Dietrich

[IDEAL Software Support]

The Dev-function had been introduced in a very early version of VPE. In a later version, VPE was capable to define the page dimensions and orientation per page - instead of specifying them for the whole print job. This newer functionality overrides the Dev-functions.

Regarding your question, what has been changed between v6.10 and v6.10 R1: I checked our source code control system. The code for printing has not been changed. It *might* be possible that something else has been changed, which might cause a side-effect, but there is no change on the printing code.

I would say, without a printer for testing, it will be very difficult to locate the problem or to adjust your code. You can also open a support case and we can check your documents on our TM-88IV.

[DDTech]

The Dev-function had been introduced in a very early version of VPE. In a later version, VPE was capable to define the page dimensions and orientation per page

OK, fine. I ran over the code and there should currently be no use of those functions. however there are sections that are in if clauses and I would have to double-check the client's configuration.

I'll give that stuff an overhaul, but first will need a new printer. Also might try a newer driver on the client side. With these POS printers I normally stick to a version that I know, runs well.
Still weird, seems to be working in some cases and not in other although

Regarding your question, what has been changed between v6.10 and v6.10 R1: I checked our source code control system. The code for printing has not been changed. It *might* be possible that something else has been changed, which might cause a side-effect, but there is no change on the printing code.

thanks.

I would say, without a printer for testing, it will be very difficult to locate the problem or to adjust your code. You can also open a support case and we can check your documents on our TM-88IV.

It's working fine with v6.10 and currently Windows 8 is no factor (at least not for this customer). So I have some time to wait for a new printer and try to fix it with the TM-88V at hand. It's behaving different than the 88IV, a lot faster and the new interface with the autoswitch another challenge. Now that I know the cause, I can put the "old" version in the setup and should be fine.

I'll let You know when I find out something new or get stuck with a reproducable szenario.

Regards

Frank Dietrich

[IDEAL Software Support]

The POS printer drivers are really full of bugs. We bought the TM-88IV several years ago, because a customer had reported problems with automatic page dimensions (page length, to be specific). We implemented a workaround especially for this buggy driver - but this was at least 5 years ago, so it does not impact the current version.

Printer driver developers seem to test their drivers against standard applications - like Word or so - and they think they are done. But their code is not stable against the whole API that a printer driver must support. In case of the TM-88IV I remember that it did not accept changes to page dimensions as printer drivers normally do. I do not remember the details, but we had to use several tricks to make it work. There is now one code path using the normal way, and if the code detects that the driver does not accept the changes, we are using a second method.

[DDTech]

I actually never found a solution to this problem.
The system always worked fine with VPE Version 6.1.0, but I knew sooner or later I'd have to deal with it, as this was the only thing preventing Windows 8+ compatibilty.
Silently hoping the probem would disappear with a newer version I now gave it another shot trying Version 7 R2.

On my mashine everything worked as expected (as it always did with 6.1.1). So I installed my software on a plain new Win7 64 bit system. At first, everything was fine there too. But after a reboot or change to another user, things started to get spooky again. Similar experience as the one I had with 6.1.1, except that this time the printout did not simply disappear. Now it came out fine (maybe due to TM-T88IV vs. TMT88V or a newer driver), but with the printout the cash drawer opened - everytime, even multiple times on multipage documents.

So I added debug and stop messages to all the points that trigger the cash drawer, but all those functions (using either control character, ESC-sequence or api-call) were either not being called or behaved as expected. - Hmm...
I created a version using 6.1.0. and again this one again worked perfectly fine.

Next I created a very basic printout (actually a modified version of my multipage sample in the other thread) and built a smal exe from that. ... This ran fine on the test computer. Every time and even side by side with the the cash register. So something in my code must be the culprit.

More debugging, comparing all settings with the ones on my computer. One Flag was different on my machine. Looked like an old abandoned one, but setting it to the same value on my mashine caused problems on my machine too - progress! Setting it to "my" value on the test machine caused the test machine to work fine - progress!
Now with the setting trouble ON my debugger showed a message "Kick drawer" and an unfamiliar method it got called from. So I searched up the inheritance tree and there it was:
in 2009 I was playing with the DevSendData() event trying to send an escape sequence to the printer in order to open the cash drawer. As this probably did not do anything, I must have left and forgot that piece of code where it was (luckily with the debug message in it). A flag decided whether the code was being executed or not - being NO on my machine but defaulting to YES when not being set.
Looking through the release notes I found that there had been a bug in DevSendData() that was fixed in Version 6.1.1 - bingo. There was the explanation for the funny behavior.
It's always a few minor issues coming together causing the worst headache.

After cleaning this up, the cash register now runs flawless with VPE V.7 under Win7-64 as well as Win 8.1-64 and - although I have not yet tested with TM-T88V - I hope we can call this problem solved forever.

Regards

Frank Dietrich

[IDEAL Software Support]

Thank you for your feedback. I am glad to hear that things are working now as they should. And it is quite interesting to learn that fixing bugs can cause problems.