Hi Carl,

I think your idea is sound and I'm actually heading in the same direction: I'm also thinking of creating a class that will handle the actual printing and then add that class to another class that will have the interface used from the rest of the system (something like a 2-tier architecture).

So far I don't have any code with the exception of what I tinkered with to get the printer to print what will be in the actual invoices (it's a dummy prg that just outputs text and codes to the printer).

I also finally got a password to get into epson's "expert" web site and am quite disappointed because I seem to have more information on this particular printer than they do! I'll be sending them an email about this.

Dean, thanks so much for the warning re. printer overflow. That's one that was likely to bite me when the POS was in place and there'd be 20 people in line waiting to pay for their purchases!!!! A real gem!

Have fun you both!

Alex

>Hi Alex,
>
>Thanks for this wealth of info. It seems like the more I learn, the more I discover how much I have to learn.
>
>For now, I'm going to keep the receipt ultra simple - text only. I'm working on a vertical with the release date creeping up quickly. I also need to come up with a scheme to support as meny printers as possible because many prospective customers already have a POS system and won't want to reinvest in hardware.
>
>I'm thinking of creating an abstract custom class for POS printers in general, subclassed to vendor-specific subclasses and subclassed further to model-specific subclasses so that I can chip away at different models as I need to. How did you structure your code - custom objects, PRGs ? Do you think my idea is a practical approach ?
>
>Thanks.
>
>