CoderPaws

Windows Live Writer & Code Snippet Plug-In

noreply@blogger.com (Unknown) — Sat, 11 Sep 2010 00:35:00 +0000

After writing such a long article (in my past post), I realized that I needed a better way to post, format, and show my code snippets. I’ve decided on Windows Live Writer as my blogging tool and WLW Code Snippet plug-in for displaying my code.

WLW Code Snippet plug-in: You can get the plug-in at Leo Vildosola's Blog or at CodePlex.
Here’s a sample of my code from my last post:

   1: using System;   2: using System.Collections.Generic;   3: using System.Linq;   4: using System.Text;   5: using System.Runtime.InteropServices;   6:     7: namespace ParameterPassing   8: {   9:     class Program  10:     {  11:         static void Main(string[] args)  12:         {  13:             Run();  14:         }  15:         public static void Run()  16:         {  17:             Book myBook = new Book();  18:    19:             GCHandle handle = GCHandle.Alloc(myBook,   20:                 GCHandleType.Pinned);  21:             IntPtr address = handle.AddrOfPinnedObject();  22:             handle.Free();  23:             Console.WriteLine("myBook address: {0}", address);  24:    25:             Change(ref myBook);  26:    27:             handle = GCHandle.Alloc(myBook,   28:                 GCHandleType.Pinned);  29:             address = handle.AddrOfPinnedObject();  30:             Console.WriteLine("myBook address: {0}", address);  31:             handle.Free();  32:             Console.ReadLine();  33:         }  34:    35:         public static void Change(ref Book bookObj)  36:         {  37:             GCHandle handle = GCHandle.Alloc(bookObj,   38:                 GCHandleType.Pinned);  39:             IntPtr address = handle.AddrOfPinnedObject();  40:             handle.Free();  41:             Console.WriteLine("bookObj address: {0}", address);  42:    43:             bookObj = new Book();  44:             handle = GCHandle.Alloc(bookObj,   45:                 GCHandleType.Pinned);  46:             address = handle.AddrOfPinnedObject();  47:             handle.Free();  48:             Console.WriteLine("bookObj address: {0}", address);  49:         }  50:     }  51: }

The advantages to using a tool like this are:
    1. Article is easier to read
    2. Code is easier to read
    3. Line numbers help us to talk about specifics in the code

What tools are you using that could help my blog be more interesting and interactive? I welcome your input.

I also have a couple of tips for working with WLW:
     1. Single space: The default when you hit “enter” is double space. To get single space, hit
         [Shift] and then [Enter].
     2. To help streamline the blog by shortening up all the blog posts on the Home page, use
         “jump break”. Problem is, WLW doesn’t have jump break built into (yet), i.e. the tool is
         grayed out. What I do is go the “Source” to view the HTML. Then place <!—more –>
         just after the parameter or sentence that I want on my Home page.

PASSING PARAMETERS BY VALUE & BY REFERENCE

noreply@blogger.com (Unknown) — Thu, 09 Sep 2010 22:27:00 +0000

I misunderstood passing a reference type to a method by reference and wrote it as ref param. I found this error in understanding when I asked a question about memory footprint of a reference type variable. The forum folks pointed out that I did not need to pass my object via ref and gave me some great links to help me wrap my brain around my misunderstanding.

I spent time researching and then testing code to make sure I got it. But what I realized after reading the articles referenced at the end of this article, although each is well-written, they were not targeted to the beginner. So this blog post takes a crack at explaining this concept in more basic, beginner terms.

1. PREFACE:

I need to lay out some code that we'll use as our example throughout the article. The links above use StringBuilder as the example reference type. I think I'll go a step further and use a class as my reference type, as newbies think in terms of classes at the beginning as that's how the books lay it out for us. I think I'll use a simple example of a Book as my reference type (my object):

   1: using System;   2: using System.Collections.Generic;   3: using System.Linq;   4: using System.Text;   5:     6: namespace ParameterPassing   7: {   8:     enum CoverType   9:     {  10:         Hardback,  11:         Softback  12:     }  13:    14:     enum ClassType  15:     {  16:         Spy,  17:         Drama,  18:         Romance,  19:         Historical  20:     }  21:    22:     class Book  23:     {  24:         public string Author { get; set; }  25:         public string Title { get; set; }  26:         public int NumberPages { get; set; }  27:         public CoverType Cover { get; set; }  28:         public ClassType Class { get; set; }  29:    30:         //...  31:    32:     }  33: }

1.1 Reference vs. Value Types:
There are two types: reference and value types.

1.1.1 Value Types:
Value types are simple types (boolean, integer, byte, float, long, decimal, char, etc.), struct, and enum. A value type holds its value in its variable and is stored on the stack memory.

So consider the following code. What would the value of copyNum be? How about num?

   1: int num = 10;   2: int copyNum = num;   3: num++

The result is num = 11 and copyNum = 10. Remember, each variable directly and separately hold their own value. Therefore, changing num after its been copied to copyNum does not increment copyNum.

1.1.2 Reference Types:
Reference types are known as objects. They include: class, arrays, interface, delegate, built-in reference types (e.g. object, string, and dynamic), and nullable types. Unlike a value type which holds its data in the variable, a reference type holds the heap's memory location of its corresponding object. So when you see referenced to or address of, it means the memory location in the heap.

Did I lose you? If so, let's step back one step. Recall that the variable holding the heap's memory location (or address or reference) is stored in the stack memory and that the actual object is stored in the heap memory. The variable simply holds the memory location and no data.

An example:
     Book myBook = new Book();

Here's what happens with the above line of code: First the compiler creates the variable myBook on the stack. Then the new keyword creates the object on the heap, which is where the data (its properties and methods) for object will reside. The heap's memory location (address) is then stored in the variable myBook.

Let's now move forward a couple of steps. What happens if we copy a reference type to another without using the new keyword?

     Book myBook = new Book();
     Book copyBook = myBook;

Any guesses? Think about it for a minute.

We didn't use the new keyword; that means an object is not created on the heap for copyBook. Right? So what does the variable copyBook have in it? It has a copy of the heap's memory location to the original myBook object.

2. PASSING PARAMETERS:
There are four types of parameters: value, reference, output, and parameter arrays, all of which can be used with both value and reference types. I'm only going to cover the first two.

2.1 Passing Value Parameters for Value Types:
This is the default of how parameters are passed. For example, in the following method, myBook.NumberPages is passed into the method by value because no other parameter keyword is specified (i.e. ref, out, or params).

   1: using System;   2: using System.Collections.Generic;   3: using System.Linq;   4: using System.Text;   5:     6: namespace ParameterPassing   7: {   8:     class Program   9:     {  10:         static void Main(string[] args)  11:         {  12:             Run();  13:         }  14:         public static void Run()  15:         {  16:             Book myBook = new Book();  17:             myBook.NumberPages = 250;  18:             Console.WriteLine("myBook.NumberPages: {0}", myBook.NumberPages);  19:    20:             Change(myBook.NumberPages);  21:    22:             Console.WriteLine("myBook.NumberPages: {0}", myBook.NumberPages);  23:             Console.ReadLine();  24:         }  25:    26:         public static void Change(int numPages)  27:         {  28:             numPages = 100;  29:             Console.WriteLine("numPages: {0}", numPages);  30:         }  31:     }  32: }

The Console reads out:

     myBook.NumberPages: 250
     numPages: 100
     myBook.NumberPages: 250

So what happens?

Change() is called and comes into scope. The parameter numPages is created on the stack as a separate integer (value type) and it contains a copy of the value in myBook.NumberPages. Both numPages and myBook.NumberPages are separate blocks of memory on the stack and each holds its own value. That means any changes to numPages will not change myBook.NumberPages. . Therefore, when numPages is changed to equal 100, myBook.NumberPages remains equal to 250.

2.2 Passing Reference Parameters for Value Types:
What if we want to be able to change the original variable with our passed parameter? For example, using the code above, we want Change() to update originalNumPages. To do this, place the ref keyword before originalNumPages and the method's parameter, as shown:

   1: using System;   2: using System.Collections.Generic;   3: using System.Linq;   4: using System.Text;   5:     6: namespace ParameterPassing   7: {   8:     class Program   9:     {  10:         static void Main(string[] args)  11:         {  12:             Run();  13:         }  14:         public static void Run()  15:         {  16:             Book myBook = new Book();  17:             myBook.NumberPages = 250;  18:             //Can't ref a property; therefore, we'll use an int  19:             int originalNumPages = myBook.NumberPages;  20:             Console.WriteLine("originalNumPages: {0}", originalNumPages);  21:    22:             Change(ref originalNumPages);  23:    24:             Console.WriteLine("originalNumPages: {0}", originalNumPages);  25:             Console.ReadLine();  26:         }  27:    28:         public static void Change(ref int numPages)  29:         {  30:             numPages = 100;  31:             Console.WriteLine("numPages: {0}", numPages);  32:         }  33:     }  34: }

The Console reads out:

     originalNumPages: 250
     numPages: 100
     originalNumPages: 100

The result would be that both numPages and originalNumPages are both changed to a value of 100.

-------------------------------------------------------------------------------------------------

Side Note: You will notice that I added int originalNumPages = myBook.NumberPages; and placed originalNumPages as the variable to pass by reference to Change(). Why? Because you can't pass an object's property by reference. So I had to modify my code a bit to illustrate the point.
-------------------------------------------------------------------------------------------------

So what happened?

Instead of creating a new block of memory on the stack for numPages, the method uses originalNumPages variable's memory location. Let me say that a different a way, just to make sure it's clear. numPages contains the originalNumPage's stack memory location So it's passing by reference (memory location) and not by value. Ah, the naming convention makes sense, right?

2.3 Passing Value Parameters for Reference Types:
Here is where you might get confused, as this is where I had my misunderstanding (which I explain in the conclusion below). Remember, reference type variables hold the heap's memory location (or address) to the actual object (Book being my object). We covered that above. When we pass a reference type by value to a method, we are passing a memory location to a newly created parameter, which is created on the stack. Did I lose you? Here's an example:

   1: using System;   2: using System.Collections.Generic;   3: using System.Linq;   4: using System.Text;   5:     6: namespace ParameterPassing   7: {   8:     class Program   9:     {  10:         static void Main(string[] args)  11:         {  12:             Run();  13:         }  14:         public static void Run()  15:         {  16:             Book myBook = new Book();  17:             myBook.NumberPages = 250;  18:             Console.WriteLine("myBook.NumberPages: {0}", myBook.NumberPages);  19:    20:             Change(myBook);  21:    22:             Console.WriteLine("myBook.NumberPages: {0}", myBook.NumberPages);  23:             Console.ReadLine();  24:         }  25:    26:         public static void Change(Book bookObj)  27:         {  28:             bookObj.NumberPages = 100;  29:             Console.WriteLine("bookObj.NumberPages: {0}", bookObj.NumberPages);  30:         }  31:     }  32: }

So what happens?
When myBook is passed to the parameter bookObj, a new block of memory is created on the stack for bookObj and the value in myBook's variable is passed (copied) to bookObj parameter. Remember that value in myBook's variable is the object's heap memory location. (I need to stress that only the object's heap memory location is passed and not the object, as the object lives on the heap.) Now both myBook and bookObj have the same value (reference to the Book object's memory location).

What happens when the method changes a property in bookObj? The property is changed in the actual object, which means both bookObj and myBook are changed and are equal. After running the program, the Console reads:

     myBook.NumberPages: 250
     bookObj.NumberPages: 100
     myBook.NumberPages: 100

Do you understand why both bookObj.NumberPages and myBook.NumberPages are equal to 100? Because they are both addressed to (referenced to) the same object.

2.3.1 Proof - Examine Memory Addresses:
Since I'm talking in terms of memory locations, I thought it would help to grab and read each out on the Console. In order to do that though, we need to modify and add some code to our example. Please note, that the code and concepts here are above and beyond the beginner level. But I still wanted to provide them to assist you in your learning process.

C# is a managed software and the garbage collector moves around memory. Therefore we need to pin down what the variable we want in order to evaluate it. We also have to make our Book class blittable (for more information on what that is, go to MSDN). We also modify our Program class to pin, get the handle, and then get the address of the pinned object.

   1: using System;   2: using System.Collections.Generic;   3: using System.Linq;   4: using System.Text;   5: using System.Runtime.InteropServices; //Added   6:     7: namespace ParameterPassing   8: {   9:     #region "enums"  10:     //enum CoverType  11:     //{  12:     //    Hardback,  13:     //    Softback  14:     //}  15:    16:     //enum ClassType  17:     //{  18:     //    Spy,  19:     //    Drama,  20:     //    Romance,  21:     //    Historical  22:     //}  23:     #endregion  24:    25:     //Our class is now blittable  26:     [StructLayout(LayoutKind.Sequential)]  27:     class Book  28:     {  29:         //public string Author { get; set; }  30:         //public string Title { get; set; }  31:         public int NumberPages { get; set; }  32:         //public CoverType Cover { get; set; }  33:         //public ClassType Class { get; set; }  34:    35:         //...  36:    37:     }  38: }

   1: using System;   2: using System.Collections.Generic;   3: using System.Linq;   4: using System.Text;   5: using System.Runtime.InteropServices; //Added   6:     7: namespace ParameterPassing   8: {   9:     class Program  10:     {  11:         static void Main(string[] args)  12:         {  13:             Run();  14:         }  15:         public static void Run()  16:         {  17:             Book myBook = new Book();  18:             /* In order to get the memory address of myBook,  19:              * we have to "pin it" first.  20:              */  21:             GCHandle myHandle = GCHandle.Alloc(myBook,  22:                 GCHandleType.Pinned);  23:             IntPtr myBookAddress = myHandle.AddrOfPinnedObject();  24:             myHandle.Free();  25:    26:             Console.WriteLine("myBook address: {0}", myBookAddress);  27:    28:             Change(myBook);  29:    30:             //Repeat code to see if address changed  31:             myHandle = GCHandle.Alloc(myBook,  32:                 GCHandleType.Pinned);  33:             myBookAddress = myHandle.AddrOfPinnedObject();  34:             myHandle.Free();  35:    36:             Console.WriteLine("myBook address: {0}", myBookAddress);  37:             Console.ReadLine();  38:         }  39:    40:         public static void Change(Book bookObj)  41:         {  42:             GCHandle bookObjHandle = GCHandle.Alloc(bookObj,  43:                 GCHandleType.Pinned);  44:             IntPtr bookObjAddress = bookObjHandle.AddrOfPinnedObject();  45:             bookObjHandle.Free();  46:    47:             Console.WriteLine("bookObj address: {0}", bookObjAddress);  48:         }  49:     }  50: }

The Console output is:
     myBook address: 11762472
     bookObj address: 11762472
     myBook address: 11762472

Notice that the memory addresses do not change.

2.3.2 Proof - Now What Happens If I Change bookObj to Another Book Object?
What happens if bookObj is instantiated to another Book object?

   1: public static void Change(Book bookObj)   2: {   3:     GCHandle bookObjHandle = GCHandle.Alloc(bookObj,   4:         GCHandleType.Pinned);   5:     IntPtr bookObjAddress = bookObjHandle.AddrOfPinnedObject();   6:     bookObjHandle.Free();   7:     8:     Console.WriteLine("bookObj address: {0}", bookObjAddress);   9:    10:     //What happens if I create another Book object?  11:     bookObj = new Book();  12:    13:     bookObjHandle = GCHandle.Alloc(bookObj,  14:         GCHandleType.Pinned);  15:     bookObjAddress = bookObjHandle.AddrOfPinnedObject();  16:     bookObjHandle.Free();  17:    18:     Console.WriteLine("bookObj address: {0}", bookObjAddress);  19:    20: }

The Console output is:
     myBook address: 11762472
     bookObj address: 11762472
     bookObj address: 11765252
     myBook address: 11762472

Interesting bookObj is now referenced to a different memory location (i.e. a different object on the heap), while myBook retains its original memory location. Therefore, we have two Book objects on the heap now and both are referenced.

2.4 Passing Reference Parameters for Reference Types:
Looking at the last proof in 2.3.2, what if we want to change the object that both variables are referenced to? We do that by passing the parameter by reference and using the ref keyword.

   1: using System;   2: using System.Collections.Generic;   3: using System.Linq;   4: using System.Text;   5: using System.Runtime.InteropServices; //Added   6:     7: namespace ParameterPassing   8: {   9:     class Program  10:     {  11:         static void Main(string[] args)  12:         {  13:             Run();  14:         }  15:         public static void Run()  16:         {  17:             Book myBook = new Book();  18:             /* In order to get the memory address of myBook,  19:              * we have to "pin it" first.  20:              */  21:             GCHandle myHandle = GCHandle.Alloc(myBook,  22:                 GCHandleType.Pinned);  23:             IntPtr myBookAddress = myHandle.AddrOfPinnedObject();  24:             myHandle.Free();  25:    26:             Console.WriteLine("myBook address: {0}", myBookAddress);  27:    28:             Change(ref myBook);  29:    30:             //Repeat code to see if address changed  31:             myHandle = GCHandle.Alloc(myBook,  32:                 GCHandleType.Pinned);  33:             myBookAddress = myHandle.AddrOfPinnedObject();  34:             myHandle.Free();  35:    36:             Console.WriteLine("myBook address: {0}", myBookAddress);  37:             Console.ReadLine();  38:         }  39:    40:         public static void Change(ref Book bookObj)  41:         {  42:             GCHandle bookObjHandle = GCHandle.Alloc(bookObj,  43:                 GCHandleType.Pinned);  44:             IntPtr bookObjAddress = bookObjHandle.AddrOfPinnedObject();  45:             bookObjHandle.Free();  46:    47:             Console.WriteLine("bookObj address: {0}", bookObjAddress);  48:    49:             //What happens if I create another Book object?  50:             bookObj = new Book();  51:    52:             bookObjHandle = GCHandle.Alloc(bookObj,  53:                 GCHandleType.Pinned);  54:             bookObjAddress = bookObjHandle.AddrOfPinnedObject();  55:             bookObjHandle.Free();  56:    57:             Console.WriteLine("bookObj address: {0}", bookObjAddress);  58:    59:         }  60:     }  61: }

The Console reads out:
     myBook address: 11762472
     bookObj address: 11762472
     bookObj address: 11765252
     myBook address: 11765252

So what happened here?

Since we are passing by reference, myBook's memory location on the stack is passed to the parameter bookObj. Think about that a moment. That means bookObj is referenced to myBook directly, which is referenced to the Book object.

When bookObj is instantiated to a new Book object (i.e. using the new keyword), the Book object is first created on the heap and then its memory location is stored in bookObj. Since bookObj is referenced to myBook, the new Book object's location is actually stored in myBook.

Effectively using ref allowed us to change from one object to another.

3 REFERENCE SITES:

Here are the sites that I used in my research:

http://www.yoda.arachsys.com/csharp/parameters.html

http://msdn.microsoft.com/en-us/library/s6938f28.aspx
http://rapidapplicationdevelopment.blogspot.com/2007/01/parameter-passing-in-c.html

4 CONCLUSION:

I hope this article was helpful for you. You might be wondering what was my misunderstanding that led me to this discovery. Well I thought that to change an object within a method, I had to pass it by reference. I didn't realize that was not necessary and actually frowned upon in the way I was using it. Rather, passing by value was all I needed and the methods were able to change the object just as I had intended.

Thank you for reading. I welcome your comments.

Sudoku Solver Progress Update

noreply@blogger.com (Unknown) — Sun, 05 Sep 2010 02:42:00 +0000

Today I finally completed the SolverEngine for handling Easy to Medium level boards. It solves each within 54 msecs. Of course that execution time could be improved, but I'm not concerned about that right now.

As for Hard to Super Challenger level boards, well it solves a portion of them and then is unable to proceed. I need to now add on to the SolverEngine algorithms. I know what I have to do in process; I just have to translate that into actual C# code.

I'm amazed at what I've learned so far just in this one project. Things like:

Don't use structs unless it represents one item and is less than 16 bytes. Otherwise you end up boxing and unboxing, which really kills performance and adds to the overhead. Plus properties look like methods, which just seems odd to me. That was my first rewrite. I have much more to learn about structs.
Refactor as much as you can. If you use it more than once, then refactor it. It saves errors, reduces code, and keeps you sane when you change one but forget to do the others.
Use base class for those common properties and methods that shared amongst classes. Why I hadn't implemented this in the beginning is beyond me. Instead at first I repeated properties and methods in the parent grid class (i.e. Row, Column, and Quad on the Sudoku board) and in the child sector class (i.e. a sector being 3 tiles). Then I finally got smart and refactored it into a base class.
using statement: So much more concise and readable than having to .Close or .Finalize a resource. I even got to implement IDisposable and Dispose().
foreach Don't use for ArrayLists that may change while in iteration. Use a for, do, or while.

There are many other things that I've learned along the way, but those are the main ones that come to mind.

Time to hit Phase 2. I'll keep you posted.

Working With ArrayList: What is the best Iterator choice?

noreply@blogger.com (Unknown) — Sun, 05 Sep 2010 02:03:00 +0000

When you first look at which statement to use to iterate through an ArrayList collection, the foreach statement stands out. It's syntax is concise and readable as well as no extra lines of code are needed to extract the element you want to work with. But...[pause for effect]...if the collection is changed (e.g. adding, modifying, or deleting elements and even copying to it), you'll get a runtime error that the "Collection was modified."

What's going on? Why does it throw an error?
The foreach statement implements the System.Collections.IEnumerable or System.Collections.IEnumerable<T> interface. The enumerator is used to read the collection's data, but it cannot be used to modify the underlying collection. It remains valid as long as the collection remains unchanged. If changes occur, the enumerator is invalidated and throws the error. Also note that the enumerator is not thread-safe because it does not have exclusive access to the collection. See this article from MSDN.

What constitutes "modifying" the collection?
The obvious modifiers are adding or deleting elements from the collection. Another is modifying the value of any of the elements. The one that got me chasing my tail for too many hours was copying a private ArrayList field to the public Property in the object. The data was dynamically updated each time the property was called, which meant that each time the foreach loop executed another loop (i.e. NextMove() in GetEnumerator()) to the enumerator the collection had changed. It drove me nuts as the data and number of elements were the same.

Here was the code in the SolverEngine:

            foreach (int digit in gridObj.DigitsNeeded)
            {
                // Work done here
            }
Here is the gridObj's property:
        private ArrayList digitsNeeded = new ArrayList();

        public ArrayList DigitsNeeded
        {
            get
            {
                CheckDigitsNeeded(); //Dynamically checks the board
                return digitsNeeded;
            }
        }
Solution for the foreach "Collection changed error"
I tried several methods to solve this:

Copying the ArrayList to another ArrayList so that the foreach locked down control. But that causes extra overhead and for my application I need to deal with the real-time board information by dynamically checking what is needed when called and not an old copy of it.
Changed to a for statement and iterated forward through it. Same error popped from time-to-time as the .Count value changed when elements were modified (e.g. a tile was solved within the for loop which decreased the NeededDigits ArrayList).
Iterated in reverse through the for statement. Ahha that works. No more "collection changed" errors.

Using #3 above, here was the code:
            int totalDigitsNeeded = gridObj.DigitsNeeded.Count;

            for (int d = totalDigitsNeeded - 1; d >= 0; d--)
            {
               digit = (int)gridObj.DigitsNeeded[d];

// Does some work

}

Do you see a problem? What happens when a digit gets solved and stored in a tile, meaning that DigitsNeeded ArrayList has an element removed? The index (d) could be out of range for the ArrayList. (Did you guess right?)

Solution: I had to implement a method to first validate d to .Count and then get the next element in the ArrayList.
      private void SomeClass(ref Grid gridObj)
      {

            //Get the sector number for the missing digit
            int totalDigitsNeeded = gridObj.DigitsNeeded.Count;
            for (int d = totalDigitsNeeded - 1; d >= 0; d--)
            {
                //Valid the ArrayList index & then get the next digit
                //If -1, then there are no more digits needed; so return.
                digit = GetNextElement(gridObj.DigitsNeeded, ref d, ref totalDigitsNeeded);
                // Does some work
            }
        }

        #region "GetNextElement"

        private int GetNextElement(ArrayList objArrayList, ref int index, ref int origCount)
        {
            int nextElement = -1;

            int count = objArrayList.Count;
            if (count == 0)
                return nextElement;

            if ((count != origCount) && ((count - 1) < index))
            {
                origCount = count;
                index = count - 1;
            }
            nextElement = (int)objArrayList[index];

            return nextElement;
        }
        #endregion

Final Thoughts:
I'm still not entirely understanding IEnumerable and why it gets confused. But I accept that it does and have seen the result of it.

Working with Arrays: Array.IndexOf

noreply@blogger.com (Unknown) — Mon, 30 Aug 2010 22:25:00 +0000

In my Sudoku project, I'm working a lot with arrays and ArrayLists. Searching an array for things like a value (e.g. a matching digit of 1-9) or an open spot (e.g. open tile in column) can be cumbersome. At first I was for statements often.

But then I discovered Array.IndexOf. The syntax is straightforward Array.IndexOf(arrayName, objectValueToSearchFor). It searches one-dimensional array, starting with the first element (i.e. 0, remember arrays are zero-based) and ending with the last element.. Each element is compared to the specified objectValueToSearchFor. If it finds it, it returns the first element location.

Here's an example:

        #region "StoreEiliminatedDigit"
        /// <summary>
        /// Stores the digit parameter into the first available
        /// slot in the EliminatedDigits bucket array
        /// </summary>
        /// <param name="digit">Digit to store, valid range 1-9</param>
        /// <returns>Index where stored or -1 if the incoming digit
        /// was invalid or no open slots were available</returns>
        public int StoreEliminatedDigit(int digit)
        {
            int index = -1;

            if ((digit >= 1) && (digit <= 9))
            {
                int openSlot = Array.IndexOf(EliminatedDigits, 0);
                if (openSlot >= 0)
                {
                    EliminatedDigits[openSlot] = digit;
                    index = openSlot;
                }
            }

            return index;
        }
        #endregion

The same code above using a for statement would like this:

                for (int i = 0; i < EliminatedDigits.Length; i++)
                {
                    if (EliminatedDigits[i] == 0)
                    {
                        EliminatedDigits[i] = digit;
                        index = openSlot;
                    }
                }

Obviously looping through each of the array elements with the for statement is inefficient as compared to using the Array.IndexOf() method.

First C# Project - Sudoku

noreply@blogger.com (Unknown) — Sat, 28 Aug 2010 19:01:00 +0000

I finished studying the C# basics up to Collections and thought it was time to test what I've learned so far. What better way to test myself than to build a project from scratch. I love playing Sudoku and have an assortment of the magazine books. I chose to build a project that did the following:

User loads in a beginning board (just like the game books), as a starting point.
Then the SolverEngine runs through a series algorithms to solve each row, column, quad, and then finally the entire board.

I'm using Visual Studio 2010 Express and building a WPF application. I've completed about 80% of the project and have the requirements and specification laid out for the remaining algorithms. Hopefully by midweek I should be done.

Screen Shots:

This is the starting board:

This is after it's run through the SolveEngine (that I've built so far):

I know that initially the project will be inefficient and ill-conceived. But it's a starting point. I plan to use it through my learning process, refining the code and performance as well as adding features as I progress. It should be interesting to see how much I can shrink the code and how much performance improvement I can achieve.

And yes, I do know that there are example solver programs out there for me to borrow from; however, I didn't look at them and frankly I wanted to solve it on my own using the same logic that I use when solving each board.

Starting my blog

noreply@blogger.com (Unknown) — Sat, 28 Aug 2010 18:49:00 +0000

This is my first blog post...ever. Hum, where to start? Let's start with what the blog is about.

Before becoming ill in 2008, I owned a software/engineering firm and had 23 years experience in Controls Engineering along with about 4 years of scattered experience with Visual Basic, i.e. scattered meaning that it was limited to when projects arose. For those of you who don't know, Controls Engineering is a branch dealing with factory automated equipment, such as servos, robotics, etc. However, in 2008, I became ill and was forced to close the business and stop working.

Fast wind to now.
About a month ago, I started studying code again. This time though I chose to start with C# 4.0, primarily because Bob Tabor (on LearnVisualStudio.net) had a series of videos for the absolute beginner for C# (and not one for VB). Plus, I had always wanted to make the leap over. My goal is to start from step one, assume I do not anything, and begin there. I plan to master C#, VB, ASP.NET, and WPF. I may even dabble in Java.

My primary learning tools are the videos I get from LearnVisualStudio.net (I'm a lifetime member) and the online books available at Safari Books Online. For those other beginners out there, these tools are much more economical than purchasing individual books, as you'll quickly fill your bookshelves. Back when I had the business, I had a bookcase full of them. And each time the platform jumps up, a new set of books is required. But by using these online resources, I always have the latest tools at my fingertips.

I hope you join me in my coding journey.