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.

Sentinel RMS License Manager

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:

 
idrs_sentinel_software_key.exe 0000000000000000000000000000000000 iDRS14_STD2_Desktop 1 IDRS14_STD2_DRS *RetrievedComputerId
 

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.

Set pre-build event command line

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.

BadImageFormatException

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

Cpu Type

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.




Post/View comments
 

ASP.NET Validators : CustomValidator Control



This week I had the following wonderful little exception reported by one of our customers (definitely not ideal):
Value was either too large or too small for an Int32
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.

CompareValidator DataType Options
 
<asp:TextBox runat="server" ID="txtTest"></asp:TextBox>
<asp:CompareValidator ID="validateTest" runat="server" ControlToValidate="txtTest"
    Operator="DataTypeCheck" Type="Integer" ErrorMessage="*"></asp:CompareValidator>                        
 

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).

 
<asp:TextBox runat="server" ID="txtTest"></asp:TextBox>
<asp:CustomValidator runat="server" ID="valTest" ControlToValidate="txtTest" ErrorMessage="*"
    ValidateEmptyText="true" OnServerValidate="valTest_ServerValidate" ClientValidationFunction="valTest_ClientValidate"></asp:CustomValidator>                        
 

The client side function will look something like this:

 
<script type="text/javascript">
    function valTest_ClientValidate(sender, e) {
        e.IsValid = ((!isNaN(parseFloat(e.Value)) && isFinite(e.Value)
                    && ((e.Value % 1) == 0)))
                    && ((e.Value <= 2147483647) && (e.Value >= -2147483648));
    }
</script>
 

While the server side method will look something like this:

 
protected void valTest_ServerValidate(object source, ServerValidateEventArgs args)
{
    Int32 result = 0;
    args.IsValid = Int32.TryParse(args.Value, out result);
}                        
 

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:

 
protected void valTest_ServerValidate(object source, ServerValidateEventArgs args)
{
    Int64 result = 0;
    args.IsValid = Int64.TryParse(args.Value, out result);
}
 

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:

 
var x = 9223372036854775807;
var y = 9223372036854775900;
 
if (x == y) {
	alert("Not cool");
}                            
 

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:

 
<script type="text/javascript">
    function isInt64(/*string*/value) {
        if (!isNaN(parseFloat(value)) && isFinite(value) && ((value % 1) == 0)) {
            value = value.replace(/^[0]+/g, ""); // get rid of possible leading zeroes
            var limit = 5807;
            if (value.charAt(0) == "-") {
                // Make the value positive
                value = value.substring(1);
                // Therefore the limit is bigger
                limit = 5808;
            }
            if (value.length > 19) // obviously bigger than Int64
                return false;
            else if (value.length == 19) {
                // Get manageable value
                var p = parseFloat(value.substring(0, 15));
                if ((p <= 922337203685477) && (value.substring(15) > limit)) {
                    return false;
                } else if (p > 922337203685477) {
                    return false;
                }
            }
            // Else definitely valid
            return true;
        }
        return false;
    }
 
    function valTest_ClientValidate(sender, e) {
        e.IsValid = isInt64(e.Value);
    }
</script>
 

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).




Post/View comments
 
First 1 2 3 4 5 6 7 8 9 10 Last / 65 Pages (130 Entries)

Latest Posts

MS SQL: Parameter Sniffing


2012-05-21 22:38:48

Be the best stalker you can be


2011-12-13 22:33:54

Top 5 posts

Moving items between listboxes in ASP.net/PHP example


Move items between two listboxes in ASP.net(C#, VB.NET) and PHP
2008-06-12 17:07:43

Simple WYSIWYG Editor


Creating a WYSIWYG textbox for your website is actually quite simple.
2007-02-01 12:00:00

C# YouTube : Google API


Post on how to integrate with YouTube using the Google Data API
2011-03-12 08:37:51

Populate a TreeView Control C#


Populate a TreeView control in a windows application.
2009-08-27 16:01:03

Cross Browser Issues: Firefox Word Wrapping


Firefox word wrapping issues
2008-06-09 09:51:21