If I were working in VBA, my current procedure would go something like this:
Do While MyFile.AtEndOfStream <> True
arrRecord = Split(MyFile.ReadLine, ",") ' Make an array of the values in this line
'There are certain records I don't want to process:
If arrRecord(1) <> "USA" then goto skip
If arrRecord(0) <= "12/31/2001" then goto skip
' Otherwise, run the rest of the code on this record
skip:
Loop
But I'm working in VBScript, which doesn't have this kind of Goto function.
I'm thinking of doing the same thing by delibaratly raising an error. For instance:
Do While MyFile.AtEndOfStream <> True
arrRecord = Split(MyFile.ReadLine, ",") ' Make an array of the values in this line
On Error Goto skip
'There are certain records I don't want to process:
If arrRecord(1) <> "USA" then Call NoSuchFunction
If arrRecord(0) <= "12/31/2001" then Call NoSuchFunction
' Otherwise, run the rest of the code on this record
skip:
Loop
Is there any potential problem with this? Should I use Err.Raise instead?
VBScript, unlike VBA, doesn't have On Error Goto. It only has On Error Resume Next.
However, the case that you're looking for, of exiting a control flow early, can be handled with the Exit statement. See this article from the Microsoft Scripting Guys for more details and examples.
If you're not currently in a control flow that you are looking to exit, you can hack it by creating one that will only execute once:
Do
'Stuff
If something Then Exit Do
'More Stuff
Loop While False 'Execute once, can be left early by "Exit Do"
And while that's clearly a hack, I'm not sure it's any worse than trying to use a straight "Goto" in the first place. Usually one can restructure the logic to be clear as to what one is actually doing, without needing such inelegant constructs.
This is not possible in VBScript. The only error handling you have is On Error Resume Next and, to disable that within a certain scope, On Error Goto 0.
There's no such think as a label in VBScript.
Related
I'm using a VBScript to write into a configuration file config.txt, then run an executable SomeName.exe with the configuration I set.
The excecutable is not mine, I cannot interact with it.
The result is written in another text file Result.txt.
In the end, it looks like this
Set objShell = CreateObject("WScript.Shell")
For MyParameter = mystart to myend
'here I overwrite conf.txt with MyParameter value
Rt = objShell.run(SomeName.exe, 1, True) '--> True means "wait until the end before processing"
Next
What I'd like to do is to check the result.txt file and, if it's ok, stop the .exe and resume the loop with next value of MyParameter.
I already know how to read the file and decide whether the result is good enough or not (basically I read the last line and compare it with something else, very easy stuff) with a second script.
What I don't know is how to make this two scripts work together.
For now the only way I have is to run manually my second script and make it check from time to time (with Sleep function) if the result is good. In that case, I use taskill /im "SomeName.exe". But it's quite ugly and I have to run it with an infinite loop since I don't know how long it will take to SomeName.exe to reach the result (it's a simulation, it can be very very long !).
Have you got any idea on how to do that ?
Thanks a lot in advance for any help you can give me,
Why use WaitOnReturn=True?
Change that to False and then add your script code loop that checks for final line right after it.
I am new to Ti-basic, and I am trying to code it. I'm trying to make this 'special type of input' program. It is kind of like input, but it will show the word as it is being pressed (and there is no need to put in alpha)
Here is the code so far that I believe is pertaining to the error
:{41,42,43,51,52,53,54,55,61,62,63,64,65,71,72,73,74,75,81,82,83,84,85,91,92,93,94,102,103,103}→∟KEYS
:"ABCDEFGHIJKLMNOPQRSTUVWXYZθ :?"→Str7
:0→K
:""→Str1
:
:Repeat K=105
:getKey→K
:If max(∟KEYS-K)
:prgmFINDIND
:.........
:End
Inside prgmFINDIND, This is the code
:1+sum(not(cumSum(∟KEYS=K)))→I
://I is used later on in the code. It isn't pertaining to the problem.
I have done some testing with pause on this already, and I found the problem was in the if statement. It returns an 'INVALID DIM' error.
Anybody know what's wrong?
In this part (edited a bit)
Repeat K=105
getKey->K
If max(|LKEYS=K
prgmFINDIND
Str1+sub(Str7,I,1->Str1
End
prgmFINDIND is only called if the key that was pressed is in the list, otherwise the index I is not changed (and possibly implicitly zero, or whatever other value that was left there).
Pressing GOTO on the INVALID DIM actually goes to Str1+sub(Str7,I,1->Str1, indicating that a bad index was used to index into Str7.
It could be fixed by using an If/Then block, which can cover more than one statement:
Repeat K=105
getKey->K
If max(|LKEYS=K
Then
prgmFINDIND
Str1+sub(Str7,I,1)->Str1
End
End
small question, in Visual Basic 6.0 (VB6)
Assuming I missed a possible situation and the user did something and did not expect, then he gets an error that crashes my application. Is there an event I can work with that will execute a certain code if that happens ?
Tried Form_Terminate \ Unload \ Query_Unload, not much luck there.
Crash:
AKA Run-Time Error.
You can add an On Error check at any level, including your Sub Main. Any errors that are not caught by an error check at that functions level will rise through the call stack to the main/initial method where you could there catch them.
You could then gracefully display the error (so you or your users are aware of it) and then resume whatever method is best at that point. And, remember, you can do this at several different strategic levels and locations.
If the errors occur in an event procedure, then these won't be trapped in Sub Main() so you will also need to catch them there.
Any errors that rise to the top of the stack, either out of Sub Main() or an event procedure will be caught by the runtime and are fatal. Your code will get no notification of this.
You may also be interested in the post Good Patterns For VBA Error Handling.
On the the frequent ways to capture error in VB6, is by using the On Error and the GOTO tags. At the beginning of each Function, you just declare the goto in case of error, and whenever an error arises, the GOTO part will be executed.
Note that the Goto part should go at the end of the method, so as after running the codes, no other piece of code is executed but leave the Function. Check the example below;
Private Function MyMethod()
Dim sMsg As String
On Error Goto ErrHandler
' ...code here...
Exit Function
ErrHandler:
sMsg = "Error #" & Err.Number & ": '" & Err.Description & "' from '" & Err.Source & "'"
GoLogTheError sMsg
End Function
I am trying to loop through all controls in a form:
For Each ctrl in Me.Controls
in order enable/disable the control based on some conditions.
But there is a control on the form that gives an error when I try to access it. What kind of control does that, and how do I find it?
When you get your error and click Debug, is the error on the line setting a control's Enabled property?
If so, add a Debug.Print statement writing out the control's name. Do so on the line before setting the Enabled property.
Here's what I mean:
Dim ctrl As Control
For Each ctrl In Me.Controls
Debug.Print ctrl.Name
ctrl.Enabled = True
Next
The Debug.Print statement will write out to the Immediate Window the name of the control that was last processed in the loop, presumably the one that caused your error.
EDIT
This might work. Put this control in a Panel control and set the Panel's Enabled property to False. If I recall correctly, in VB6 setting a container control's Enabled property to False will also set the container's child controls Enabled to False. If your control's Enabled property really is read-only, I'm curious what would happen.
Try this:
Dim ctr As Control
Dim CtrStatus Boolean
CtrStatus = False
For Each ctr In Me.Controls
If (SSTab.hwnd = GetParent(ctr.hwnd)) Then
Call CallByName(ctr, "Enabled", VbLet, CtrStatus)
else
ctr.Enabled = CtrStatus
End If
Next
Another approach is as follows, that also works at runtime (as opposed to just in the IDE):
private sub SetEnabled()
on error goto errHandle
Dim ctrl As Control
For Each ctrl In Me.Controls
ctrl.Enabled = True
Next
exitPoint:
exit sub
errHandle:
MsgBox "Error " & err.Description & " with Control " & ctrl.Name
resume exitPoint
end sub
Suppress the error reports before the loop and then set it back to standard error handling:
On Error Resume Next
For Each ctrl In Me.Controls
ctrl.Enabled = lIsEnabled
Next
On Error GoTo 0
OR name your controls with a standard prefix/suffix that you can check by name and skip in the loop.
For Each ctrl In Me.Controls
If Left(ctrl.Name, 3) = "sst" Then
ctrl.Enabled = lIsEnabled
End If
Next
Tosa: from your comment on AngryHacker's answer, I think you are checking the container incorrectly.
Your code is like this
' BAD CODE '
If ctrl.Container = fraMovies Then
For me that gives error 450 Wrong number of arguments or invalid property assignment. Do you get the same error?
The code should use Is rather than =, like this
' GOOD CODE '
If ctrl.Container Is fraMovies Then
Explanation. You want to check whether two variables "point" to the same control. Controls are objects: you must use Is not = to check whether two object variables "point" to the same object. This is a classic pitfall in VB6.
One last word. Next time, could you try to post 10 lines or less of actual code, reproducing the error, and give the exact error number and message and the exact line on which it occurs? It really does make it much easier for us to solve your problem - I know it's work for you to shorten the code, but you'll get better answers that way.
EDIT Welcome back! :) You said some controls don't have a Container property. You could try wrapping the test in On Error Resume Next, something like this.
' GOOD CODE '
Dim bMatch As Boolean
Dim ctrl As Control
For Each ctrl In Me.Controls
bMatch = False
On Error Resume Next
bMatch = (ctrl.Container Is fraMovies)
On Error Goto 0
If bMatch Then
ctrl.Enabled = True
End If
Next
To avoid such problems follow the given rules while naming contols
When you name an element in your Visual Basic application, the first character of that name must be an alphabetic character or an underscore.
**Begin each separate word in a name with a capital letter, as in FindLastRecord and RedrawMyForm.
Begin function and method names with a verb, as in InitNameArray or CloseDialog.
Begin class, structure, module, and property names with a noun, as in EmployeeName or CarAccessory.
Begin interface names with the prefix "I", followed by a noun or a noun phrase, like IComponent, or with an adjective describing the interface's behavior, like IPersistable. Do not use the underscore, and use abbreviations sparingly, because abbreviations can cause confusion.
Begin event handler names with a noun describing the type of event followed by the "EventHandler" suffix, as in "MouseEventHandler".
In names of event argument classes, include the "EventArgs" suffix.
If an event has a concept of "before" or "after," use a suffix in present or past tense, as in "ControlAdd" or "ControlAdded".
For long or frequently used terms, use abbreviations to keep name lengths reasonable, for example, "HTML", instead of "Hypertext Markup Language". In general, variable names greater than 32 characters are difficult to read on a monitor set to a low resolution. Also, make sure your abbreviations are consistent throughout the entire application. Randomly switching in a project between "HTML" and "Hypertext Markup Language" can lead to confusion.
Avoid using names in an inner scope that are the same as names in an outer scope. Errors can result if the wrong variable is accessed. If a conflict occurs between a variable and the keyword of the same name, you must identify the keyword by preceding it with the appropriate type library. For example, if you have a variable called Date, you can use the intrinsic Date function only by calling DateTime.Date.
When an error occurs in a function, I'd like to know the sequence of events that lead up to it, especially when that function is called from a dozen different places. Is there any way to retrieve the call stack in VB6, or do I have to do it the hard way (e.g., log entries in every function and error handler, etc.)?
You do have to do it the hard way, but it's not really all that hard... Seriously, once you've written the template once, it's a quick copy/paste/modify to match the function name in the Err.Raise statement to the actual function name.
Private Function DoSomething(ByVal Arg as String)
On Error GoTo Handler
Dim ThisVar as String
Dim ThatVar as Long
' Code here to implement DoSomething...
Exit Function
Handler:
Err.Raise Err.Number, , "MiscFunctions.DoSomething: " & Err.Description
End Function
When you have nested calls, this unwinds as each routine hits its Handler and adds its name to the error description. At the top level function, you get a "call stack" showing the list of routines that were called, and the error number and description of the error that actually occurred. It's not perfect, in that you don't get line numbers, but I've found that you don't usually need them to find your way to the problem. (And if you really want line numbers, you can put them in the function and reference them in the Err.Raise statement using the Erl variable. Without line numbers, that just returns 0.)
Also, note that within the function itself, you can raise your own errors with the values of interesting variables in the message like so:
Err.Raise PCLOADLETTER_ERRNUM, , "PC Load Letter error on Printer """ & PrinterName & """"
(The syntax highlighting looks wonky in the preview... I wonder how will it look when posted?)
I'm pretty sure you have to do it the hard way. At a previous job of mine, we had a very elegant error handling process for VB6 with DCOM components. However, it was a lot redundant code that had to be added to every method, so much that we had home-grown tools to insert it all for you.
I can't provide too much insight on its implementation (both because I've forgotten most of it and there's a chance they may consider it a trade secret). One thing that does stand out was that the method name couldn't be derived at run-time so it was added as a string variable (some developers would copy-paste instead of using the tool and it would lead to error stacks that lied...).
HTH
The hard, manual way is pretty much the only way. If you check out this question, someone suggested a tool called MZTools that will do much of the grunt work for you.
As other people said (years ago, I see... but there's so many people still using VB6! :) ), I think it's not possible to programmatically retrieve the Call Stack, unless you use some 3rd-party tool.
But if you need to do that for debugging purposes, you can consider of adding to the called routine an Optional input string variable, were you'll put the caller's name.
Sub MyRoutine
(...) ' Your code here
call DoSomething (Var1, Var2, Var3, "MyRoutine")
' ^
' Present routine's name -----------+
(...) ' Your code here
End Sub
Public DoSomething (DoVar1, DoVar2, DoVar3, Optional Caller as string = "[unknown]")
Debug.Print " DoSomething Routine Called. Caller = " & Caller
... ' (your code here)
End Sub
Not so elegant, maybe, but it worked for me.
Regards,
Max - Italy
Compuware (or was it Numega at the time) DevStudio for Visual Basic 6 used to do this. The way was by adding adding instrumenation to every call that called a very small snippet that added to the code stack. On any error it dumped out that callstack, and then did things like mail or post to a webserver all the debuging information. Adding and removing the instrumentation was a potentially lethal operation (especially back then, when we were using VSS as our source control), but if it worked, it work well.
As Darrel pointed out, you could add something very simlar by using MZTools and setting up a template. It's a lot of working, and is probably more effeort than the reward would be but if you have very difficult to track down bugs, it might help).