OCR (C#) : IRIS (iDRS 14.0) Part 1 - Getting Started

I was unable to find ANY examples on the internet on how to use the iDRS libraries supplied by IRIS, which probably means that they've got some kind of weird copyright law prohibiting anyone to blog about it, making them the sole means of support on the net (or alternatively its a crap product, which I dont believe it is).

But why would a company willingly shoot itself in the foot? Basically it means that you're not allowed to advertise their product, since showing people how to use it is also a form of advertising.

So these posts will remain active until IRIS asks me to remove it.

Assuming you've downloaded the SDK and bought the product (else click on this link), follow the following steps.

Setting up the licenses

Step 1

Install sentinel Licence Manager located under redist/software_protection folder; used to validate licences against their servers.

Step 2

Retrieve computer specific id by running the idrs_sentinel_computer_id.exe located in your bin folder.

Step 3

Retrieve your generated keys by passing the serial numbers IRIS supplied you in combination with the computer id generated in step 2 via the the idrs_sentinel_software_key command like seen below:


Which will return you some funky code which you need to use in your license class, you will need to repeat this step for every module you've got licenses for.

Adding references

I found it a bit cumbersome adding the needed references to my solution, since basically your executable needs to reside in the same folder as the assemblies making out the OCR engine. (the millions of assemblies you'll find under the bin folder of the SDK)

The way they did it in their sample files is to simply compile the application to the bin folder of the SDK, not very portable don't you think?

So what I did instead was to create a folder in my solution named Assemblies and copied all the needed assemblies to that folder and set a prebuild script to copy the assemblies to my application folder like seen in the following image.



Right click solution >
Select Properties >
Click on Build Events Tab >
Edit Pre-build Command Line with the following text.
Copy $(ProjectDir)Assemblies\*.* $(TargetDir)

As for the .net assembly (idrskrn_net14.dll bit of a poorly named assembly according to .net standards), you simply add like you'd add any other .net assembly.

Chances are good that you'll get the following BadImageFormatException (bad image format, bad boy, down boy) as soon as you attempt to run your application.



You'll need to set your executable platform target to x86 like seen in the following image.



Right click solution >
Select Properties >
Click on Build Tab >
Select x86 on Platform target dropdown

In the next part of this post we're going to have a look at how to retrieve text from an image using the iDRS SDK.




 

ASP.NET Validators : CustomValidator Control

This week I had the following wonderful little exception reported by one of our customers (definitely not ideal):

Now generally I am always careful to put validators on my fields etc and in fact I did put a validator on this particular field - a CompareValidator set to check data types like seen below.



The application expected an Int32 and instead the customer supplied a value that would put any Int64 value to shame, and the validator won't know any better since its validating anything that looks or smells like an integer. (I foolishly assumed it was going to validate Integer(VB)/int(C#)/Int32(CLR) values). 

This all makes the CompareValidator a bit mediocre if you're trying to validate actual strongly typed integer based types, e.g. Int32/Int64 etc

In this post I am going to demonstrate how to use the CustomValidator control to validate Int32 values (values between -2147483648 and 2147483647) and at the end of the post we're going to look at how to validate Int64 values.

We're required to provide server and/or client side methods/functions for the CustomValidator control (if you're planning to omit one, rather omit the client side method than the server side - we've got control of our servers, but not necessarily of the browser connecting to the server).


The client side function will look something like this:


While the server side method will look something like this:


Hooray this will prevent the customer to assign non Int32 values, but what if we need the ability to assign Int64 values? Well, this is where it gets a bit trickier...

The server side method is easy to amend, which will look something like this:


The tricky part comes in when writing the client side validation function,
to quote David Flanagan's JavaScript: The Definitive Guide

The JavaScript number format allows you to exactly represent all integers between -9007199254740992 (-2^53) and 9007199254740992 (2^53), inclusive. If you use integer values larger than this, you may lose precision in the trailing digits.

Int64 values are way above this limitation, e.g between 9223372036854775807 and -9223372036854775808, to demonstrate what David is saying, observe the following snippet:


In the snippet above x represents a valid Int64 value while y is just too big to be considered an Int64 value, but yet when we compare the two values, javascript seems to think they're equal and we get a message popping up saying "Not cool".

What happend here is the losing of precision mentioned in David's book, infact both values are converted to 9223372036854776000 therefore they are equal.

Luckily the value sent to the javascript callback isn't an integer value, but a string value, which gives us the ability to do a few "tricks", observe the following snippet:


Basically we remove leading zeroes (that might exist) and we split the string into javascript manageable integers which we compare to the first 15 digits of our Int64 MaxValue/MinValue and the last remaining digits (if needed).




 
First 1 2 3 4 5 6 7 8 9 10 Last / 62 Pages (124 Entries)