Code error

[dr223]

Please could anyone look why I receive the errors and advise me to fix them. Many thanks

Public Sub FormatData(ByRef MyForm As System.Windows.Forms.Form, ByRef MyFormValuesOnLoad As Object)
		
		On Error GoTo EH
		Dim MyCOntrol As System.Windows.Forms.Control
		Dim MyControlCount As Short
		
		MyControlCount = 0
        System.Windows.Forms.Cursor.Current = System.Windows.Forms.Cursors.WaitCursor

		For	Each MyCOntrol In MyForm.Controls
			
			If TypeOf MyCOntrol Is System.Windows.Forms.TextBox Or TypeOf MyCOntrol Is System.Windows.Forms.CheckBox Or TypeOf MyCOntrol Is System.Windows.Forms.ComboBox Then
				MyControlCount = MyControlCount + 1
			End If
		Next MyCOntrol
		ReDim MyFormValuesOnLoad(ValueType.MyIndex, MyControlCount)
        MyControlCount = 0

        Dim cbo As ComboBox

        For Each MyCOntrol In MyForm.Controls
            If TypeOf MyCOntrol Is System.Windows.Forms.TextBox Or TypeOf MyCOntrol Is System.Windows.Forms.CheckBox Or TypeOf MyCOntrol Is System.Windows.Forms.ComboBox Then
                MyControlCount = MyControlCount + 1
                MyFormValuesOnLoad(ValueType.MyName, MyControlCount) = MyCOntrol.Name
                If TypeOf MyCOntrol Is System.Windows.Forms.TextBox Then
                    MyFormValuesOnLoad(ValueType.MyTextOrValue, MyControlCount) = MyCOntrol.Text
                ElseIf TypeOf MyCOntrol Is System.Windows.Forms.CheckBox Then
                    MyFormValuesOnLoad(ValueType.MyTextOrValue, MyControlCount) = MyCOntrol.Value
                ElseIf TypeOf MyCOntrol Is System.Windows.Forms.ComboBox Then
                    cbo = CType(MyCOntrol, ComboBox)
                    MyFormValuesOnLoad(ValueType.MyTextOrValue, MyControlCount) = cbo.ListIndex
                End If

                If isControlArray(MyForm, MyCOntrol) Then
                    MyFormValuesOnLoad(ValueType.MyIndex, MyControlCount) = MyCOntrol.Index
                Else
                    MyFormValuesOnLoad(ValueType.MyIndex, MyControlCount) = ValueType.NotControlArray
                End If
            End If
        Next MyCOntrol
		
		System.Windows.Forms.Cursor.Current = System.Windows.Forms.Cursors.Default
		
		Exit Sub
EH: 
		System.Windows.Forms.Cursor.Current = System.Windows.Forms.Cursors.Default
		MsgBox(Err.Description & " In Form " & MyForm.Name,  , "FormatData")
	End Sub

Error messages;

Error 1 'Value' is not a member of 'System.Windows.Forms.Control'.
Error 2 'ListIndex' is not a member of 'System.Windows.Forms.ComboBox'.
Error 3 'Index' is not a member of 'System.Windows.Forms.Control'.

[HanneSThEGreaT]

You could save yourself a lot of trouble by properly making use of your Imports statement(s).

You should use it like this :

Imports System.Windows.Forms

At the top of your class.

By doing this you don't need to type System.Windows.Forms the whole time, and Most importantly, all the neceassary classes will be imported and part of your class..

[sotoasty]

Well, the main issue is that those controls do NOT have those properties.

Throw a CheckBox on your form. Check the properties. Do you see a "Value" Property? On a comboBox, do you see a listIndex?

It looks like this code has been converted from VB6. I think it is probably time for a re-write.

[dr223]

But is it possible to change

- MyCOntrol.Value
- cbo.ListIndex
- MyCOntrol.Index


To have a Vb.Net representation?


Thanks

[dglienna]

Not if the property is READ-ONLY.

You'd have to create a NEW Control to OVERRIDE the default behaviours of the original one.

[JohnnyD]

Does On Error Goto even work in VB.NET any more?

[HanneSThEGreaT]

Yes, can you believe it! Ridiculous isn't it?

[JohnnyD]

I had no idea. I moved from VB6 to VB.NET a few years ago and I haven't used a single GOTO yet. TBH I thought it had been phased out completely with VB6 (and was glad of it).

[TT(n)]

Hey guys, I don't want to come off as contradictory or anything, but..

"On Error GoTo" is actually more reliable than the .net equiv, "Try".

As it implies Trying can fail, and the with some errros, it will never try again!
This is not what most would expect, want, intend, or even know about until it happens in a very frustrating way. Solution close program, and start it over.
It will try that block once again, fail, and lock the block from trying again. ARrrgg! Does MS, or anyone else know of any documentation on this?

For example, the wide ranging Accessiblity API have been notorious for this behavior in my experience over the last couple months, although I've seen it before in various other examples, so I was already keen on identifying and reproducing it. Trying just blows(can i say that), and it's slow, and should be used as a last resort when debugging(developing), or simply to give the user feedback, ie opening files etc. Or if you want to impress a .net-er, that insists that all .net stuff must be better because it has superceded an older function.
Don't use "Try" in your release code, if you can at all help it. Seriously.

I personally don't use On Error GoTo, but I wouldn't consider it crayon coding compared to Trying.

If good code is written defensively, it rarely needs to handle any errors to begin with. With some exceptions ofcourse(no pun intended).
__

I've also come to believe that Imports(contrary to my previous opinion) are often better when used directly in terms of modular programming.
Not in this OP maybe, where it seems to be excessive, but functionally speaking.
It's easy to copy and paste a funciton without having to track down the import too(when there are many imports up top, and you don't remember which one does what exactly). Unless it's used alot, and causes the code to be less readable(like in the original post), or much larger. It also avoids naming conficlts, that require you to declare Shadows. Either way to import it can be proper, but just for different reasons.

[HanneSThEGreaT]

I so hoped that On Error GoTo would be depracated with VB 2010, but alas, it is still there. Just wondering how long will Microsoft include it for "backwards compatibility" as they put it...

[TT(n)]

Probably as long, as it provides unique error handling capability that is reliable compared to Try.

When debugging, I found that On err goto, did catch that error every time the block was fired, while try did not because it locks the block out after the first failure.

[DataMiser]

I have not noticed any issues with the try block as of yet.
I have a TCP client which uses a try block around the connection attempts and when the address is bad or some other problem that would cause an exception the catch block executes as expected.

If the user tries again the try block executes again and generates the exception. When the exception is no longer present the try block runs and the connection is made.

It is troubling if there could be a case where the code no longer executes due to a previous failure but I have yet to see this happen.

[TT(n)]

It is troubling if there could be a case where the code no longer executes due to a previous failure but I have yet to see this happen.

Oh there are several cases, I'm not making it up, and I did reproduce them.
Just keep it in mind, when debugging, you may indeed run into it someday, and it rots badly, because you really would have no idea unless someone pointed it out previously.

It is fairly rare, but completely unexpected with the false sense of security.

[dglienna]

Post a sample, and I'll pass it along...

[TT(n)]

Well I didn't save the snippets of code, but I am absolutely certain, and I could do it again.

Off the top of my head the easiest example would be my first encounter when working on the SendKeys module.
I made a simple wrap around the keyboard_event API,(for up down sending) with a Try Block, and upon failure it simply would not fire that block again.

I had correspondence with microsoft feedback about the keyboard event api, which was quite embarrasing for them. I got a bunch of childish responses from the dev team, trying to discredit me for what I had presented. I guess some of them keep their jobs this way. lol
It's like class warfare.

In particular, the keyboard event api, is a FUNCTION, with a very valid RETURN VALUE, contrary to the entire teams knowledge. Msdn key_bd
How do I know? Well I captured the return, when a keyboard stroke fails(and you can too), and it indeed returns 0, instead of 1. Usually you will hear a messagebox bonk noise upon error for various reasons of invalid focus or whatever. Somewhat rare, but prevelant enough to see and easy to proove.

Perhaps the principle applies to microsoft, in that when they don't expect there to be a valid return failure, the dev team never prepares correctly or something.

It's just a joke, and I no longer try and help though ms feedback.
I will try and help fellow peers though.