• (cs)

    How does a pop-up prevent the print queue from letting jobs skip ahead? I mean if there are 100 jobs in the queue before the pop up appears, what's to prevent number 100 from printing before number 50? Or were more details omitted?

  • (cs)

    Can it really be called a print "queue" when items can suddenly appear anywhere but at the end?

    edit: snoofle, my interpretation is that there's a bug in the print queue system that places jobs at of order when the queue gets too full (> 100 jobs).

  • (cs)

    could he not have used a sleep() statement instead of a dialog box?

  • Anonyous Cow (unregistered)

    That's more of a print heap or like a print array, not a queue.

    If the printer's queue is full, it should just start blocking print calls.

  • (cs) in reply to vt_mruhlin

    I thought the same thing at first, but this is the real world where printers run out of toner and paper on a regular basis. The dialog box allows the end user to make sure everything is printing fine before continuing.

  • (cs) in reply to vt_mruhlin
    vt_mruhlin:
    could he not have used a sleep() statement instead of a dialog box?
    Yes he could/should have.

    Aside: Seems to me the developer myopically looked at his own code - saw no bugs - and declared the problem non-existent, and refused to delve deeper until forced to by (what in this case is sensible) management. The print queue is a wtf but this (developer) seems a bigger wtf!

  • (cs)

    This comment is first. It cut ahead in the queue.

    my god, sendkeys? what kind of halfwit uses that hack on a multitasking system?

  • (cs)

    So the WTF is that John is a hack with no development skills, who is incapable of solving the problem?

  • Leo (unregistered)

    in before "The real WTF is Microsoft Access."

  • EatenByAGrue (unregistered)

    He could use a sleep call. Win32 also appears to provide some APIs that can tell you whether the printer is ready to print, which could be used to decide whether to wait or not.

  • prof. memals (unregistered) in reply to snoofle
    snoofle:
    vt_mruhlin:
    could he not have used a sleep() statement instead of a dialog box?
    Yes he could/should have.
    so he should have allowed; 1 second per print ? 1 minute per 100 prints ? I love race conditions, "cold with threat of rain"
  • lo (unregistered)

    TRWTF is indeed the developer. Just because it works with sample/test data doesn't mean it won't break on a real system. Sounds a bit up himself tbh.

  • (cs) in reply to vt_mruhlin
    vt_mruhlin:
    could he not have used a sleep() statement instead of a dialog box?
    I think that's the point. He was annoyed at being blamed for this, so he put in a suboptimal solution. The WTF is that management loved the solution, and even kept it in when they had it upgraded.

    I will agree, he didn't do a good job testing. Sure, your code seems to be fine, but your code doesn't execute in a vacuum. Nor does it execute on 30 pieces of data. I've seen many times that a solution works fine for the first x many, then goes wonky after that. For example, I've seen a list that said its maximum was 255 items stop working correctly after 127. Gee, I wonder what the problem was.

  • Crazy Monkey (unregistered) in reply to Outlaw Programmer
    Outlaw Programmer:
    Can it really be called a print "queue" when items can suddenly appear anywhere but at the end?

    edit: snoofle, my interpretation is that there's a bug in the print queue system that places jobs at of order when the queue gets too full (> 100 jobs).

    So there was a bug in the print server? Were they maybe not using a windows server for the print queue and each pc was sending out jobs to the printer itself (basically each PC would have it's own print queue?)

  • (cs) in reply to snoofle
    snoofle:
    Aside: Seems to me the developer myopically looked at his own code - saw no bugs - and declared the problem non-existent, and refused to delve deeper until forced to by (what in this case is sensible) management.

    But it Works on My Machine™

  • Someone (unregistered)

    Should have built a basic machine to be the printer queue instead of using the printer's clearly buggy internal software.

    Or alternatively had your application print to a central application that actually does the printing, although that is too much work.

  • (cs)

    We have a similar WTF in our billing system. If we generate PDFs for lots of invoices in parallel some of them will become corrupted and display wrong text or some text might disappear altogether. If we set it to produce only one PDF at a time, then no more errors. We suspect the PDF generator might be using IE in the background and that that isn't thread-safe. Doing it one-by-one is obviously much slower than using all of the server's eight cores.

  • None of your business (unregistered)

    Replacing a WTF with WTF solution. WTF?!

    CAPTCHA: quis - how appropriate.

  • d.k. Allen (unregistered)

    It would seem that the application is sending the invoices as one print job per invoice. The entire set of invoices should be sent as one print job.

    Print queues are supposed to function as queues - first in, first out. However, this is always subject to job priorities and operator manipulation (and the ham-handedness of newbie OS and hardware developers) -- an application developer should never depend upon an external print queue to always print his jobs in order - Things Happen.

    I have seen printouts appear in all kinds of wacky orders, and we haven't even touched on having multiple print devices per queue (which any good admin should know how -- and when -- to use)... But /within/ a print job, one should always expect the output to be in order.

  • BentFranklin (unregistered) in reply to Erzengel
    Erzengel:
    I've seen many times that a solution works fine for the first x many, then goes wonky after that.

    Kind of like Diebold's voting system central tabulator. It works fine when only a few precincts are dialing their results in, but when there are lots of precincts in a county it tends to drop some results:

    http://voices.washingtonpost.com/the-trail/2008/08/21/ohio_voting_machines_contained.html

    Of course, it's just a coincidence that highly populated counties are heavily Democratic, right? Maybe, maybe not:

    http://query.nytimes.com/gst/fullpage.html?res=9804E3DC1339F93AA35752C1A9659C8B63

    If you want to know more about this stuff you can email me at Gmail.

  • Pine Scented (unregistered)

    I believe turning off 'Print spooled documents first' in the advanced printer properties would have prevented the documents from being printer out of order. Then again, who am I to judge? ;)

  • Buddy (unregistered)

    Oh yeah, been there, done that.

    The worst was the dreaded Excel hack for printing to file. The API was missing a parameter to specify the file name. Instead it would pop up a prompt to fill it out. Obviously an impediment to automation.

    You had to assume the application had focus, then send the keys, but not too fast, in case the machine was bogging down near the end of its run. Something like 2 seconds pause per key. However, the long pauses left the application vulnerable to losing keyboard focus during that time.

    So of course, no one could touch the machine while it was doing whatever huge report run with the application. Should keyboard focus be lost at any time, you'd end up with one or more missing reports, a mess to sort out the next day, and still have to set up for next run.

    The mouse could be unplugged, but we had to keep the keyboard plugged in, something about it not working when plugged in again. So we devised a set of nesting boxes like Marushka dolls for the keyboard, each box with increasingly dire warnings to keep away.

    After stacking the boxes, you'd pause a bit and watch the screen, like checking a baby if it's okay, take a deep breath, then turn off the light and go home.

  • Gary Niger (unregistered)

    The real WTF is indeed the developer.

    What's so wrong about taking the printer offline, letting all print jobs queue, and then taking the printer back online? I suppose the printer is dedicated for the invoice processing anyways. It would have the added benefit that users can decice when they want the printout to begin.

  • Anon (unregistered)

    I have to agree with several others on here that the "not my problem/fault" attitude of the developer was less than helpful.

  • (cs) in reply to Pine Scented
    Mark:
    Upon seeing this fix, management was elated. In fact, they were so impressed by this genius solution that when the invoicing application was rewritten in VB.NET years later, John learned that the message box still was there, just to make sure that the invoices didn't skip ahead in the printer queue.

    You know you could write a SendKeys macro to dismiss that MessageBox right? :-)

  • John Reese (unregistered) in reply to Erzengel

    IIRC, sleep() was the first thing I tried. The question is...how long do you sleep? Is a minute long enough? Five minutes? Thirty minutes?

    What I needed was some way to tell when the printer had finished spitting out invoices. There is no Windows API for that.

    So, I put the message box in place, and instructed the accounting clerks to hit "OK" as soon as the printer stopped printing.

    I agree that this is a suboptimal fix. Can you suggest an optimal fix, one implemented entirely in VBA code?

    As for testing...any of us would like to think that our testing of this process would, of course, naturally include going through each of the hundreds of invoices by hand, one by one, to make sure they are all in order.

    I mean, we are ALL that thorough in our testing, aren't we? And we would follow it through all the way to the end, JUST IN CASE the first 120 were fine, but the next fifteen were not? Even when we have no reason to believe the invoices will print out of order, since they had never done this before?

    SURE we would.

  • m0ffx (unregistered) in reply to prof. memals
    prof. memals:
    snoofle:
    vt_mruhlin:
    could he not have used a sleep() statement instead of a dialog box?
    Yes he could/should have.
    so he should have allowed; 1 second per print ? 1 minute per 100 prints ? I love race conditions, "cold with threat of rain"
    User configurable, called something like 'Printout duration', with the explanation in the manual 'Set this value to the length of time it takes your printer to print one invoice. This ensures printouts are produced in the correct order'.
  • John Reese (unregistered) in reply to Pine Scented
    Pine Scented:
    I believe turning off 'Print spooled documents first' in the advanced printer properties would have prevented the documents from being printer out of order. Then again, who am I to judge? ;)

    I don't remember exactly what I tried (this was years ago), but I distinctly remember trying all the different combinations of settings for that stupid printer. It made no difference.

  • (cs)

    What is the difference between a light bulb going off and a light bulb turning on?

  • C (unregistered) in reply to Gary Niger
    Gary Niger:
    What's so wrong about taking the printer offline, letting all print jobs queue, and then taking the printer back online?
    That would have been even worse! The problem was that when the queue got "full" (at 100 jobs), the next Print command would skip the queue and go directly to the printer output.
  • Pedantic (unregistered)
    by end cusotmer.

    HAHAHA. I found a typo in the article! Two transposed letters. Pedantic grammar and spelling luser wins!

  • JLT (unregistered)

    No where here have I seen the ABSOLUTE EASIEST METHOD of fixing this

    ... its called "PRINT DIRECT",

    which eliminates the queue altogether. Therefore bypassing this problem altogether. Sure you would have had an error when you ran out of paper or something, but you could have trapped that right off in the code.

  • (cs) in reply to YourNameHere
    YourNameHere:
    You know you could write a SendKeys macro to dismiss that MessageBox right? :-)
    Dueling SendKeys apps? I hear banjos...
  • Procedural (unregistered)

    Why isn't he sending all of the data for one customer as one print job ?

  • (cs) in reply to Erzengel
    Erzengel:
    For example, I've seen a list that said its maximum was 255 items stop working correctly after 127. Gee, I wonder what the problem was.
    Compiling without using "-Wchar-subscripts"?
  • (cs) in reply to Anonyous Cow
    Anonyous Cow:
    That's more of a print heap or like a print array, not a queue.

    If the printer's queue is full, it should just start blocking print calls.

    Heaps and arrays tend to allocate sequential entries as well as queues. This thing is more like a "print dictionary hash"!

  • (cs) in reply to kastein
    kastein:
    my god, sendkeys? what kind of halfwit uses that hack on a multitasking system?

    What kind of nitwit uses Access and VB in the first place? I mean, if you're going to start peeling the nitwit onion, you'll have to peel it all the way down to Redmond...

  • (cs) in reply to Andy Goth
    Andy Goth:
    What is the difference between a light bulb going off and a light bulb turning on?
    I guess you'll just have to remain in the dark on that one.

    But a flash bulb going off is exactly the same as a light bulb turning on, if that helps.

  • Amoa (unregistered)
    Armed with his test cases, John told management that there was no way this could be the application's fault - it had to be somewhere in the network.
    . As a network engineer, I'd like to express my hatred for you. It doesn't work? IT MUST BE THE NETWORK!!!
  • (cs) in reply to John Reese
    John Reese:
    IIRC, sleep() was the first thing I tried. The question is...how long do you sleep? Is a minute long enough? Five minutes? Thirty minutes?

    What I needed was some way to tell when the printer had finished spitting out invoices. There is no Windows API for that.

    5 minutes of googling: http://www.visualbasic.happycodings.com/Applications-VBA/code9.html

    Although the real answer is generating the invoices in such a way that they are one continuous print job.

  • Noob (unregistered) in reply to kastein
    kastein:
    This comment is first. It cut ahead in the queue.

    my god, sendkeys? what kind of halfwit uses that hack on a multitasking system?

    used hack^H^H^H^H send keys multiple times, I have.

  • (cs) in reply to m0ffx
    m0ffx:
    User configurable, called something like 'Printout duration', with the explanation in the manual 'Set this value to the length of time it takes your printer to print one invoice. This ensures printouts are produced in the correct order'.
    Mother of Spaghetti you've never worked in tech support, have you? You actually expect users to know things like how long the printer takes to print an invoice? Considering that an invoice can be of variable length what possible answer can this be?

    Get out of your ivory tower and actually talk to some end users. You'll learn very quickly to make things as simple, idiot-proof and seeded with big, brightly colored candy-like buttons as possible so that there's even a glimmer of hope that they'll get it right.

  • John Reese (unregistered) in reply to Lacutis
    Lacutis:
    John Reese:
    IIRC, sleep() was the first thing I tried. The question is...how long do you sleep? Is a minute long enough? Five minutes? Thirty minutes?

    What I needed was some way to tell when the printer had finished spitting out invoices. There is no Windows API for that.

    5 minutes of googling: http://www.visualbasic.happycodings.com/Applications-VBA/code9.html

    This would tell me the state of the local print queue, correct? The local print queue was behaving normally. It was some sort of abstraction layer between the operating system and the printer that was causing the problem.

    True, I never saw this mythical abstraction layer with my own eyes, but how else do you explain:

    1. Print jobs going out on the network in the correct order
    2. Print jobs coming out of the printer in the wrong order
    Although the real answer is generating the invoices in such a way that they are one continuous print job.
    As for sending them all in one print job...is there a way to print Access reports that way?
  • ollo (unregistered) in reply to m0ffx
    m0ffx:
    prof. memals:
    snoofle:
    vt_mruhlin:
    could he not have used a sleep() statement instead of a dialog box?
    Yes he could/should have.
    so he should have allowed; 1 second per print ? 1 minute per 100 prints ? I love race conditions, "cold with threat of rain"
    User configurable, called something like 'Printout duration', with the explanation in the manual 'Set this value to the length of time it takes your printer to print one invoice. This ensures printouts are produced in the correct order'.

    As i hadn't read the manual, i'd enter... 0? I want printing to be FAST!

  • m03 (unregistered) in reply to Buddy
    You had to assume the application had focus, then send the keys, but not too fast, in case the machine was bogging down near the end of its run. Something like 2 seconds pause per key. However, the long pauses left the application vulnerable to losing keyboard focus during that time.

    Was AppActivate not available in VBA like it was in VBScript? Assuming so, an AppActivate before every keystroke, combined with only sending one keystroke at a time would have solved that problem. I could be remembering VBAs features incorrectly though.

    It wasn't a pretty way to automate things, but it sort of worked (atleast in VBScript).

  • (cs) in reply to m03
    m03:
    You had to assume the application had focus, then send the keys, but not too fast, in case the machine was bogging down near the end of its run. Something like 2 seconds pause per key. However, the long pauses left the application vulnerable to losing keyboard focus during that time.

    Was AppActivate not available in VBA like it was in VBScript? Assuming so, an AppActivate before every keystroke, combined with only sending one keystroke at a time would have solved that problem.

    No it wouldn't. If the user happened to be part-way through typing ALT+TAB at the time, or happened to be just about to click their mouse in another window, there's nothing to stop that event being processed in between AppActivate and SendKey.
    m03:
    It wasn't a pretty way to automate things, but it sort of worked (atleast in VBScript).
    You've closed the window but not eliminated it. It's still a fundamentally flawed design.

    Incidentally, it gets worse. There are USB devices out there that automatically install software on connection by pretending to be a HID (keyboard) and sending a lot of keystrokes. Some do this in conjunction with also pretending to be a USB floppy, and sending the keystrokes '-startmenu-R-enter-A:\SETUP.EXE-enter-'. One that a colleague of mine once saw even fired up cmd.exe and ran debug.com to enter a small program, hex byte by hex byte!

    Hammer a few random keys in the middle of that and you've changed a BIOS 'int' call into something else... potentially trashing your MBR or something important like that. Brillant!

  • morry (unregistered)

    there's a truth here. Management will always choose the sub-optimal solution.

  • (cs) in reply to MrsPost
    MrsPost:
    Mother of Spaghetti [ . . . ]
    [ . . . ], full of grace, the Flying Spaghetti Monster is with thee?
  • (cs)

    1. There should have been one print job sent to the printer containing all the invoices sorted in proper sequence for stuffing in envelopes. That's exceedingly easy to do.

    2. "agonizingly slow JET database engine" is wrong. Jet's performance is quite good and in simple situations can outperform SQL Server. Yes, SQL Server is a better solution for complex applications or mission critical systems.

    I have apps with tables with over a million records working just fine.

    1. "SQL Server (where the data was slowly being migrated)" Slowly being migrated makes no sense. You upsize the entire database at one time. You don't upsize table by table.

    Tony Toews, Microsoft Access MVP

  • (cs) in reply to John Reese

    [quote] Although the real answer is generating the invoices in such a way that they are one continuous print job.[/quote] As for sending them all in one print job...is there a way to print Access reports that way? [/quote]

    Exceedingly easy. I'm quite puzzled as to why they didn't do that.

    Tony Toews, Microsoft Access MVP

Leave a comment on “Cutting in Line”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article