Implicit conversion from 'System.Array' to '1-dimensional array of Byte' in copying the value of 'ByRef' parameter 'Value' back to the matching argument

I converted a project from VB6 to VB2003 to VB2005.

In VB6 we had the following type of code:

      Dim tempBytes() As Byte, readFileHandle As Long
      readFileHandle = FreeFile
      Open imgFile For Binary Access Read As #readFileHandle
      ReDim tempBytes(1 To LOF(readFileHandle))
      Get #readFileHandle, 1, tempBytes 'dataoffset is 0-based; GET is 1-based

What this basically did was it opened an image file and then read in the image file to a byte array.

When we converted to VB2003, the code was converted and fixed as such:
        Dim tempBytes() As Byte
        Dim readFileHandle As Integer
        readFileHandle = FreeFile()
        FileOpen(readFileHandle, imgFile, OpenMode.Binary, OpenAccess.Read, OpenShare.Shared)         '!!## errors?
        ReDim tempBytes(LOF(readFileHandle) - 1)           
        FileGet(readFileHandle, tempBytes, 1)            'dataoffset is 0-based; GET is 1-based

In converting it to VB2005, I decided to turn Option Strict ON, which gave a warning on the following line.  The warning is the subject of this post:
        FileGet(readFileHandle, tempBytes, 1)            'dataoffset is 0-based; GET is 1-based

The warning made sense, tempBytes is type Byte, and FileGet is expecting a System.Array.

The way to fix this is to cast tempBytes as an array, and the warning will go away, and it will still work.
            FileGet(readFileHandle, DirectCast(tempBytes, Array), 1)            'dataoffset is 0-based; GET is 1-based

Single Instance Applications is a lot easier in VB 2005

For more information, read the following post:

http://blogs.msdn.com/tyler_whitney/archive/2005/11/23/VB-Application-Model.aspx

From the article:

So what's a Single-Instance application?  Imagine launching an application where additional attempts to launch the app while the first one is running doesn't actually launch a new instance of the app.  Instead the original instance of the app gets notified that another launch attempt occurred.  When we introduced an application model for Visual Basic in VB 2005, one of the things we wanted to do is make it drop-dead easy to create single-instance applications.

Pretty much what you need to do in VB 2005 is to right click on your main project and go to properties. 
then select Application, then make sure you have "Enable application framework" checked.

Then check of "Make single instance application"

For the other items. I have everything checked, and the authentication mode, I chose Windows, and the shutdown mode, I chose When startup form closes, and for the Splash screen, I have code that takes care of this.

Either way, this is a lot easier than writing code in order to make this happen properly.

-- Ted

Integer Division in VB.NET

Copied this from http://www.devx.com/vb2themax/Tip/18244

It pretty much talks about the difference between doing division with the "/" vs "\"

Use integer division operator

Use "\" instead of "/" when performing divisions between Integers. The "/" operator returns a Single value, therefore the seemingly efficient line

C% = A% / B%

actually requires three implicit conversions, two for converting the operands from Integer to Single (to prepare them for the division) and one to convert the result from Single to Integer (to complete the assignment). If you use the "\" operator you don't incur in this overhead, and the division itself is faster. While we are on this topic, keep in mind that the "/" operator returns a Double value if at least one of its operands is a Double; therefore if you wish the highest precision when dividing two Integer or Single values, you should manually coerce one of them into Double type:

' this prints 0.3333333
Print 1 / 3
' this prints 0,333333333333333
Print 1 / 3#

Using the ^ operator that can slow your application down

I recently had an application where we used the "^" operation to do a Power operation.

For example in order to square X, we did X^2.  It turned out that using the "^" operator was slower than using X*X, or even using Math.Pow(X, 2).  It wasn't noticeably faster if you only did this once or twice, but in our situation, we called this function millions of times, so a little improvement made a big difference.

-- Ted