0

I'm trying to capture the data that is sent to an OPOS printer driver, and control whether or not it should proceed.

My first thought was to develop a virtual OPOS printer driver, but before going deep into the code, i would like to probe if you know of any other better way to achieve this.

Is there any way of listening at the entrance of a specific OPOS driver, and then control whether the data proceeds or not to the printer OPOS driver ?

UPDATE I'm speaking of MS Windows XP and above.

MrWater
  • 1,797
  • 4
  • 20
  • 47
  • It would really help if you specify the operating system. There's a huge difference in writing drivers between Windows, Linux, Mac or embedded systems. – JvO Jan 20 '13 at 20:40
  • Hi, thank you. I've updated ... It is for windows, as as far as I know OPOS is only used on MS Windows systems (correct if i am wrong). JavaPOS on the other hand is cross-platform i believe, but haven't had to deal with it still. Both derive from UnifiedPOS standard – MrWater Jan 21 '13 at 16:50

1 Answers1

0

You can write a thin Service Object wedge that you register with OPOS as the printer SO, and inside it pass all the calls over to the real SO. Then you have a point where you can make your business decisions on whether or not to print.

John Deters
  • 4,295
  • 25
  • 41
  • Thank you John..Do you have any tips on where i might find information on how to write that Service Object? – MrWater Feb 02 '13 at 23:18
  • (and how to register it with OPOS) – MrWater Feb 02 '13 at 23:27
  • I created the IDL to mirror the calls to the SO, then just wrote pass-thru functions for each method. My job was easier because I was only implementing a scanner wedge, and there were only like 5 total methods. It takes COM and ATL experience. Look at the source of the OPOS Common Controls for an example. – John Deters Feb 03 '13 at 02:43
  • To register it, follow how the existing printer is registered. What I did was to use the wedge's SO registry as a place to store the name of the real SO, so I could read it and then my wedge knew what to instantiate. – John Deters Feb 03 '13 at 02:49
  • @JohnDeters i am trying the same for a printer, i built an OPOS driver based on the POS for .NET library and its working fine(i take the data then pass it to the physical printer), but for systems that only see old OPOS drivers it doesn't work and i am trying to make a com based driver based on the CCO interfaces, however i keep getting the error "POSControlException ErrorCode(305) ExtendedErrorCode(0) occurred: Method Open threw an exception. The service object does not support one or more of the methods required by its release." – Mahmoud Darwish Mar 31 '13 at 12:07
  • although i implemented every method and property in these interfaces, i am using C# for this and i extend the interface IOPOSPOSPrinter from the dll POS.Devices.OPOSPOSPrinter.dll, can you please provide insight on what is causing the error, and what are the correct steps to do this, for example which dlls should i use. – Mahmoud Darwish Mar 31 '13 at 12:08
  • I'm sorry, I'm not a C# guy and haven't ever done COM through C#. What I do know is that the OPOS_OR_BADIF (305) error is caused by the service object not supporting all the methods on the version of interface it is claiming to be. It counts the methods using the GetIDsOfNames() method on the IDispatch interface. If you get the CCO source, you can see this in zPOSPrinter\POSPrinterImpl.cpp and searching for "OPOS_OR_BADIF". – John Deters Apr 01 '13 at 20:11
  • @JohnDeters thanks for the help, well i found out that there are 7 methods that need to be implemented which are missing from the interfaces exposed by the interop assemblies, these methods are 1. COFreezeEvents 2. GetPropertyNumber 3. SetPropertyNumber 4. GetPropertyString 5. SetPropertyString 6. OpenService 7. CloseService after implementing these - the Get\Set Property methods are tricky - all worked fine, i don't understand why these methods aren't exposed by the interfaces. – Mahmoud Darwish Apr 02 '13 at 06:23
  • Those methods are exposed by the SO interfaces, not the CCO interfaces. The CCO is a de facto standardizing layer on top of the SOs that really serves as "insulation" to keep the SOs and applications truly isolated. It's one of the best things to happen to retail programming in 'ever'. – John Deters Apr 02 '13 at 15:14
  • I know that, and i agree with it being the best thing to happen to retail programming :), however it is used also as a helper for SO builders as per the CCO website, no complains here, only stating what happened so others can benefit :) – Mahmoud Darwish Apr 03 '13 at 13:54