• (cs) in reply to Addison
    Addison:
    In the developer's world there is only one question with a relevant answer- does it do what it's supposed to? If it does than ANY extra time spent is a waste of time.
    That's an incompetent's reply. There is a whole WORLD more to being a professional engineer - just "making it work" is only the beginning. Amateurs and cowboys often master this first foothill and make the mistake of thinking they have conquered the mountain; it is merely the case that their gaze is cast too low to see the peaks ahead of them.

    You, sir, are the reason why maintainance programmers are simultaneously well-paid, never in danger of being hard up for work - and yet also suicidally depressed.

    Addison:
    Let me be the first to say that the developer did a decent job with the message box thing.
    And let you be the last as well.
  • A Gould (unregistered) in reply to Tony Toews
    Tony Toews:
    3) "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.

    That's easy - they're not migrating in the "convert the database" sense - they're migrating in the "let's have someone do stupendous amounts of data entry" sense.

  • (cs) in reply to Jay
    Jay:
    Just a couple of weeks ago I complained to my boss that the users probably wouldn't get the requirements paper finished until 4:00 on the day I was supposed to have the coding finished. It turned out I was wrong. They didn't get it to us until the middle of the following week.
    When that happens, you are entitled to go out to the local print shop, buy a red inkpad and a HUUUUUGE big rubber stamp with "REJECTED" on it, and stamp it all over their document and send it back to them in the internal mail, you know.

    Although possibly instead you should stamp it on your boss's forehead, since he's TRWTF in this situation, for agreeing to create a schedule before having a spec, for telling you to start working rather than slip the project and wait for the spec, for failing to kick up a fuss in inter-departmental meetings, failing to fight your corner, trying to please everyone and ending up overpromising instead of having the balls and spine to do his damn job and make a decision, and for generally being about as much use as tits on a bicycle.

  • (cs) in reply to John Reese
    John Reese:
    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

    I'm sorry, but did you actually read the quote of your text that was quoted? That's what I responded to. I'm not sure what it is you think I said, but it wasn't:

    I found this code that will tell you the printer is working!!!

    If you bothered to actually read the code at the page I linked it gives you the code to see how many print jobs are left in the queue.

    For the sake of hilarity, I'll requote the statement you made that I was replying to:

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

    The code I linked would give you the number of jobs left in the queue, which in turn would tell you exactly what you needed to know.

    The reason people are bagging on you is not because of what you did 6 years ago, but because of how you still to this day claim the problem lied with the print drivers, or gremlins, or the position of the stars and there was nothing you could do about it. If there is one thing I've learned is there is ALWAYS another way.

  • DWalker (unregistered) in reply to Buddy
    Buddy:
    DWalker:
    Yes, depending on the OS that's running the print queues, when the printer is first set up, there's generally a choice to print everything FIFO or smallest first, or some weighted variation.

    Smallest first is a useful choice sometimes, but can have unintended consequences if people don't realize the choice is there.

    We didn't tell the regular staff about the choices. Only development knew that you could set print jobs to higher priority to get pushed ahead of the queue. It gave me a bit of satisfaction to see dozens of huge jobs pending, and have my little listing job right behind the one actively printing.

    While some might call me some choice words for not disclosing this feature, from experience we knew it would be abused with the eventual outcome that everyone would set their jobs to 99 priority as a default.

    Usually the printer can be set up ON THE PRINT SERVER to print everything FIFO and not let anyone set the priority for a print job. That's what I was trying to say, not too well.

  • Stiggy (unregistered) in reply to DaveK
    DaveK:
    Tony Toews:
    pink_fairy:
    Look if it starts with Access, it's doomed. It's not doomed because Access is bad, or even because Access is naughty. It's not even doomed because Access programmers are inherently bad, and naughty, and moronic people.

    Absolute rubbish. Access is an excellent tool for creating applications. It has it's limitations of course.

    Right. That's like saying "VSS is an excellent tool for revision management. It corrupts your data of course."

    Or to put it another way, claiming that "VSS is an excellent tool for revision management. It has it's limitations of course." would be just the same as saying "Access is an excellent tool for creating applications. It corrupts your data, of course."

    Access is a great database for one user on a non-networked workstation, just like VSS is a great SCM for one user on a non-networked workstation. It is when you introduce multiple users and a network full of servers that their "limitations" begin to seem like crippling defects that render them fundamentally unfit for purpose. Most people would consider simultaneous multi-user access to be of the essence of a DB or SCM, not a nice-to-have extra.

    Anyway, I don't see why we should take advice from someone who can't even balance his opening and closing quote tags!

    Access... VSS...

    Thanks, dude. Now the PTSD's back.

  • John Reese (unregistered) in reply to Lacutis
    Lacutis:
    The code I linked would give you the number of jobs left in the queue, which in turn would tell you exactly what you needed to know.

    I'm sorry if I haven't made myself clear. The whole problem hinged around the fact that there was not a one-to-one correlation between what the print queue was telling me and what was coming out of the printer. Something was happening between those two points that was confusing the issue considerably. For that reason, the contents of the print queue would NOT tell me what was happening at the printer. I'm not a network/hardware expert, so I couldn't tell you exactly what was going on here, even if I remembered all the details.

    It's possible that the code you provided would have worked perfectly. I don't know, since I can't recall all the issues involved. All I can remember is that I tried a lot of different things that should have worked, but for one reason or another did not, and I needed to find a workable solution so I could get back to a not-insubstantial backlog of projects.

  • Shea (unregistered)

    This is default behavior for printers under windows and can be modified. Turn off "Print Spooled Documents First" and turn on "Print directly to the printer" to correct the issue of printing out of order. While it will turn off certain printer optimization features (i.e. it may wait on one job when another is ready to go, so it is considered sub-optimal), that is what was desired anyway, and the printer should still be limited by its own PPM in most cases.

  • (cs)

    ... and then someone posted it on TDWTF Error'd.

  • John Reese (unregistered) in reply to Shea
    Shea:
    This is default behavior for printers under windows and can be modified. Turn off "Print Spooled Documents First" and turn on "Print directly to the printer" to correct the issue of printing out of order. While it will turn off certain printer optimization features (i.e. it may wait on one job when another is ready to go, so it is considered sub-optimal), that is what was desired anyway, and the printer should still be limited by its own PPM in most cases.

    Tried it. Didn't work.

  • Random832 (unregistered) in reply to John Reese
    John Reese:
    Shea:
    This is default behavior for printers under windows and can be modified. Turn off "Print Spooled Documents First" and turn on "Print directly to the printer" to correct the issue of printing out of order. While it will turn off certain printer optimization features (i.e. it may wait on one job when another is ready to go, so it is considered sub-optimal), that is what was desired anyway, and the printer should still be limited by its own PPM in most cases.

    Tried it. Didn't work.

    Was the computer running the application directly connected to the printer, or was it on the network?

    Did you turn on the setting on the print server too?

  • LrdDimwit (unregistered)

    I hereby dub these sorts of coding practices "RubeG". It isn't a language, it isn't a coding style ... It's a way of life.

  • sw (unregistered)

    ...'macros to VBA .... agonizingly slow JET database engine'

    Access macros were already in vba. Horrible vba generated by the application , but vba nonetheless. Also, Jet wasn't slow.

  • dan the man (unregistered) in reply to John Reese

    I don't see any need for you to defend yourself, John. I think your solution is completely optimal - and so did management.

    A programmer's instinct is to fix everything with code, but sometimes the user knows best.

    Of course it would have been nice to fix the print queue, and there is a solution someone suggested, which if it works, might have been the right thing to do.... but chances are that when they upgrade/reinstall the printer, the problem would reappear, and noone would remember the solution.

    Perhaps there is a better solution, but I haven't read one yet. sleep(), as you point out, isn't it.

  • N0G (unregistered) in reply to DaveK
    DaveK:
    ...and for generally being about as much use as tits on a bicycle.
    Lies! I can think of at least one use for tits on a bicycle. Mmm, wobbly.
  • (cs) in reply to N0G
    N0G:
    DaveK:
    ...and for generally being about as much use as tits on a bicycle.
    Lies! I can think of at least one use for tits on a bicycle. Mmm, wobbly.
    Yeah, but every time you squeeze them they squirt light machine oil in your face. And you don't want to suck on the grease nipple neither.
  • Ford (unregistered)

    This comment was actually first.

    Must be a network problem.

Leave a comment on “Cutting in Line”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article