Silver Bullet Ranger – To suspend or not to suspend?

Link: http://www.sbullet.com

Here is another quick article about the Ranger product. There is a function in the Ranger control for suspending an item. This basically puts the item on hold. It was a quandary to me if I should use this and I found that some transports want it (even need it like the Unisys CAPI transport), and others will not tolerate it (like desktop scanners that need a decision on the item and will not wait regardless of whether you call suspend or not).

The bottom line is to use suspend unless you are running a transport that requires it be not used. It makes life a bit easier as you can go about other processes and pick up the item processing task later (i.e. you don’t have to run everything you are doing from a Ranger event before pocketing the item).

Again I will post more on this if someone picks up this thread and wishes for more info.

Loading Silver Bullet Ranger ActiveX control in VS.Net

Link: http://www.sbullet.com

OK, first of all, if you are new to check processing, this is a link you really want to check out because it will (likely) help you get started running that scanner that your project manager just put on your desktop. Tell them you need to use this tool, because it will save lots of time when you need to implement a new scanner.

If your scanner does not have a Ranger implementation, you may want to consider switching to one that does.

OK, specifically in the blog I wanted to share a little tidbit I have found when working with Ranger in .Net.

When you drag the Ranger ActiveX control onto a .Net form, it will interop just fine, and that’s all great, but for some reason, Visual Studio does not always like to reload the object the next time you bring up the solution.

I have noticed this with COM objects in general, and don’t know for certain that it’s still an issue with VS 2008, but it certainly is for VS 2005. So here is what I have found.

First a workaround. Don’t leave the form designer up when you shut down the solution. If you do this, it seems much more likely that it will lose that COM object the next time with an “error loading” or somesuch. If you close the designer, it is more likely to be able to load the COM object and not produce this error.

However, you can completely eliminate the issue (especially with this COM object since it has no visual interface) by simply loading it at run time.

To do this you need to:
0. Before you take the Ranger ActiveX control out of your project, go to the generated form code and copy out the section where it loads the Ranger control.

1. Run TLBIMP.exe (type lib importer) to create a .Net interop wrapper around the COM object. This happens automatically when you drag it onto the form, but you are not doing that, so you need to create them yourself.

2. Load these imported wrapper assemblies into your form project.

3. Now you have the wrappers ready to talk to the COM object, and only need to instance those assemblies dynamically. In your form load, paste in the section of code you saved. This will load the Ranger ActiveX control and from there on out, you can reference it as if it were put in the designer. No more load error in the form designer!

I am putting this out into the ‘net, but have not spent the time of pasting code. If someone hits this and can use the code, let me know and I will paste it up here.