Valhalla Legends Archive

I keep getting this,
Error: index out of bounds                       highlighted: ChannelList.ListItems.Remove (pos)

For everything ive tried, i cant fix it :-[

Means you are trying to remove an item array that does not exist in the upper bounded range. The index that you are supposed to supply for Remove() is the index of the item in the list.

simple fix (not good, but it works)
add "On Error Resume Next" to the sub or function

Quotesimple fix (not good, but it works)
add "On Error Resume Next" to the sub or function

I may not be a Visual Basic programmer, but I can tell you that in general it's almost never a good idea to just ignore all errors.  They're there for a reason.

well this is true, but depending on the sub or function it may be alright to slap that in there, but if the sub or function contains many more things than just that, i wouldnt reccomend it. some errors will still appear with on error resume next, depending on theyre priority.

In the case of referencing an array element that doesn't exist: that's probably a bad idea, especially if "resuming next" would wind up having you calling on that element. In C++ arrays aren't necessarily initialized, and referencing an uninitialized array (i.e. an element that has no specific value) causes errors via attempting to read or write restricted memory addresses. In case you didn't already know, that causes a crash.

Well, your all wrong, since you cannot put that line in front on the sub, or in it.
 - I found the bug any way ;\, the cleanslatebot.ocx version i had, had a bug in it, where for the information it had a line from one of the earlier versions

Thx for you help anyway :)

Wait, or maybe putting that at the top of the source would enable it ;\

On Error Resume Next can be put ANYWHERE, and it will have the scope of the place you put it.  For example:

Sub TestThis()
  On Error Resume Next
  
  Dim ayArray(12) as String

  MsgBox ayArray(13)
End Sub

This will simply pass over the erroneous MsgBox line, and continue processing (but not a good idea)

At the top of a code module/class module/form

Option Explicit
On Error Resume Next

<functions here>

This will make the statement global if in a code module, local to the form in a form, local to the class in a private, public or global class module.

Oh, and one more thing...

IT WORKS ANYWHERE

QuoteIn the case of referencing an array element that doesn't exist: that's probably a bad idea, especially if "resuming next" would wind up having you calling on that element. In C++ arrays aren't necessarily initialized, and referencing an uninitialized array (i.e. an element that has no specific value) causes errors via attempting to read or write restricted memory addresses. In case you didn't already know, that causes a crash.

Err.. If you follow your logic, you'd crash every time you tried to initialize an array.

QuoteAt the top of a code module/class module/form

I didn't think that works. Are you sure?

QuoteI didn't think that works. Are you sure?

Not in the version of Visual Basic I have... Even if it did work, I wouldn't recommend it since you're ignoring all errors which could be a very bad thing if you're just developing a program.

QuoteErr.. If you follow your logic, you'd crash every time you tried to initialize an array.

I guess that was unclear. I meant that if you tried to do something with the value stored in an array element that was not initialized, the program would crash. Actually initializing it doesn't cause a crash, of course.

It wouldn't crash, it would just get a meaningless value.
(This can indirectly cause a crash, if that meaningless value is expected to be meaningful... But just reading it won't crash.)

yes thats what i was saying, if you try to set a value some place where it cannot be set, or use an invalid syntax or anything that cant really be skipped, you will get a runtime error, and it will crash, but reading data will not cause a crash if you trap it.

Yeah, I was half asleep when I wrote that little code.  I mixed up Option Explicit and On Error  

/me is an idiot
lol

Anyway, yeah, you can put On Error Resume Next ANYWHERE that happens to be IN A CODE BLOCK.  Code block meaning a routine, such as Sub Main() or Form_Load()

When that routine is called, the On Error statement, if I remember correctly, will have priority over any prior On Error statements until the called routine with the On Error statement terminates.

What I mean by this is, if you call Sub Main() which has an On Error statement in it, and in that routine you call Sub Main2() which has On Error in it, and in Sub Main2() you call Sub Main3() which does NOT have On Error, the Main2() routines On Error will be called on any error... I think.

Anyway, it is better to have an On Error Goto ErrHandler type statement, that will call a routine to handle any errors.  

Sub Main()
  On Error Goto ErrHandler

  Err.Raise -1, "Source is MyForm", "ERROR"

  Exit Sub

ErrHandler:
  Call HandleError(Err.Number, Err.Description)
End Sub

Sub HandleError(errNum as Long, errDesc as String)
  'More code here
End Sub

Or something to that effect.

I don't understand.  Could you say that again, slower?

In case I made it unclear, reading *will* crash if you read from an address that's not in a valid context. It won't crash, but will give meaningless data, if you read from an address that's in a valid context (i.e. your process heap or thread stack) but not initialized.

Quote

Code Select Expand

:ErrHandler

Btw, as similar as they may sometimes be, this is VB, not batch. ;)

lol, oops

ErrHandler:

I make that mistake the most, I swear it. lol


Grok: The original Sub Main() is Sub Form_Load(). To see what I mean in action, simply cut and paste this code into a VB6 project form code, and run it.

You will see a msgbox with "-1 Main2 RAISED ERROR", even through the error raised was given a source of "Main3"

Note that if you use Err.Source, you will see "Main3"

Private Sub Form_Load()
  On Error GoTo ErrHandle1
  Call Main2

  Exit Sub

ErrHandle1:
  Call ErrHandler(Err.Number, "Main1", Err.Description)
End Sub

Sub Main2()
  On Error GoTo ErrHandle2

  Call Main3
  Exit Sub

ErrHandle2:
  Call ErrHandler(Err.Number, "Main2", Err.Description)

End Sub

Sub Main3()
  Err.Raise -1, "Main3", "RAISED ERROR"

End Sub

Sub ErrHandler(num As Long, source As String, desc As String)
  MsgBox num & " " & source & " " & desc
End Sub

if you remove the on error statement and the handler in Main2(), you will get a msgbox with Main1 as the source, which is what I was trying to explain.