How to add the input from InputBox into MsgBox - windows

I want to add the inputted text from an MsgBox into a Msgbox I got this but it don't work. Can anyone help me?
Dim x
x = MsgBox("Welcome to this software. Are you new with this?", vbYesNo +
vbQuestion, "Welcome!")
Dim f
f = strMessage =Inputbox("First enter your name","The software")
Dim z
z = MsgBox(Welcome strMessage!)

There are a couple of issues with what you have here. I'll go through them one by one.
f = strMessage = InputBox("First enter your name","The software")
I assume you're trying to store the value the user entered into the InputBox into some variable--either f, or strMessage, or maybe both. VBScript does not allow multiple assignments in the way that you've written them. Instead, VBScript is testing whether the value stored in strMessage (which you haven't declared or initialized) is equal to the value the user entered. The value of that test (which will be either True or False) is then stored in f.
If you're trying to store the user's input in just f, this will work:
f = InputBox("First enter your name","The software")
If you want to store it in both f and strMessage, you'll need two assignment statements:
Dim strMessage
f = InputBox("First enter your name","The software")
strMessage = f
Next, there are a couple issues with these lines:
Dim z
z = MsgBox(Welcome strMessage!)
First, MsgBox with only one argument will always return 1, so there's no real use in having variable z.
Next, you haven't put quotes around the first argument to MsgBox. As a result, Welcome strMessage! confuses the interpreter, and throws an error. If you instead add quotes, "Welcome strMessage!", that will resolve the error.
I expect, however, you want to display the user's input back to them. In that case, you can't just put the variable within the quotes--you need to concatenate it on, using &. Thus, you should come to:
MsgBox("Welcome, " & f & "!")
Finally, an important note, the variable names you have (x, f, strMessage, and z) not particularly descriptive. Consider some helpful names, like isUserNew and userName. With those changes, you'd get to:
Dim isUserNew
Dim userName
isUserNew = MsgBox("Welcome to this software. Are you new with this?", vbYesNo, "Welcome!")
userName = Inputbox("First enter your name","The software")
MsgBox("Welcome, " & userName & "!")

Related

vbscript X and Cancel not doing what they should

im writing a code in vbscript where it will ask the user for input and then run certain files according to the input and i have the else so that it will redo the if else sequence when you type something that isnt an option but when i try to press cancel or the red 'X' it acts as if i have put in an invalid input and goes over the else sequence.
Dim sInput
sInput = InputBox("input")
If sInput = "input1" or sInput = "input2" Then
set shell=createobject("wscript.shell")
shell.run "file.bat"
elseif sInput = "exit" or sInput = "Exit" Then
WScript.Quit
else
name=msgbox (" That is not a valid response",0+16,"ERROR")
set shell=createobject("wscript.shell")
shell.run "input.vbs"
end if
Don't try to restart the script.
Use a loop instead. End the loop when the user entered a valid option, or quit the entire program if requested.
Option Explicit
Dim Shell, input, button
Set Shell = CreateObject("WScript.Shell")
Do
input = InputBox("input")
If IsEmpty(input) Or LCase(input) = "exit" Then WScript.Quit
input = LCase(Trim(input))
If input = "input1" Or input = "input2" Then
Shell.Run "file.bat"
Exit Do
Else
button = MsgBox("That is not a valid response.", vbExclamation + vbRetryCancel, "ERROR")
If button = vbCancel Then Exit Do
End If
Loop
Notes:
Option Explicit makes variable declaration mandatory. It's a good idea to always have this enabled.
IsEmpty() is true when the user pressed the Cancel button (or the Esc key) in the InputBox - but this will work only before the response is manipulated in any way, such as LCase or Trim. Supporting the Cancel button is more intuitive than having a special "exit" keyword, so maybe you should get rid of that.
The various constants you can use with MsgBox are described on ss64.com and in more detal in the official VBScript language reference.
You can change what Enter and Esc do in each MsgBox by using the vbDefaultButton1 or vbDefaultButton2 constants.
The Do loop without any conditions (Do/Loop While ... or Do/Loop Until ...) will run forever - be sure not to forget using Exit Do or WScript.Quit(). (If you do, killing the Script with the Task Manager will get you out of it.)

how to compare single char in VB6?

i'm trying to do a guessing game in VB6. it involves comparing a letter that the user input. i already searched for it, unfortunately, they only have for the latest version.
can anybody help me on comparing a single char in Visual Basic6.0 . because, frankly i have no idea on it.
Asc and Chr$ are the functions to look for.
Private Sub Form_Load()
Dim lSecret As Long
Dim sInput As String
Dim lAscChar As Long
'Define a secret character as an ANSI code.
lSecret = Asc("m")
Do
'Let the user input a single character.
sInput = InputBox("Enter a single character. " & _
"If more characters are entered, only the first one " & _
"will be used. To end just click OK without entering text.")
If Len(sInput) = 0 Then Exit Sub
'Obtain the first character's ANSI code.
lAscChar = Asc(sInput)
'If the user entered the correct secret character, tell her.
'Otherwise give a hint.
If lSecret = lAscChar Then
MsgBox "Great, you are a hero."
Exit Sub
ElseIf lSecret < lAscChar Then
MsgBox "Nope, in the ANSI table, the correct answer is " & _
"before this one."
Else
MsgBox "Nope, in the ANSI table, the correct answer is " & _
"after this one."
End If
Loop
End Sub

Vbscript type mismatch error apparently not justifiable

I'm trying to figure out why I would get this error for the code below. I've searched on the web for possible causes but I couldn't find. Please have a look:
Dim descr, code
If WScript.Arguments.Count = 0 Then
Set objShell = CreateObject("Shell.Application")
objShell.ShellExecute "wscript.exe", Chr(34) & Script.ScriptFullName Chr(34) & " Run", , "runas", 1
Else
descr = InputBox("restore point description","Crepo")
If (descr) Then
code = GetObject("winmgmts:\\.root default:Systemrestore").CreateRestorePoint (descr, 0, 100)
If (code) Then
Msgbox "System Restore Point not created (" & code & ") !", 48, "Crepo"
Else
Msgbox "System Restore Point successfully created", 64, "Crepo"
End If
End If
End If
At runtime, if I input anything, i.e. qwerty I get this error:
Line: 8
Char: 2
Error: Type mismatch: '[string: "qwerty"]'
Code: 800A000D
From my researches, return type of InputBox is string and CreateRestorePoint first argument is also string. In fact, it works if I call InputBox directly as the argument.
The If clause needs a boolean (not a string):
>> descr = "qwerty"
>> If (descr) Then WScript.Echo "nonsense"
>>
Error Number: 13
Error Description: Type mismatch
InputBox returns a string or an empty value (see here), but never Null.
Instead of If (descr) Then try If (Not IsNull(descr)) Then.
You may also want to check for empty strings too: If (Not IsNull(descr) and descr <> "") Then. In fact, as pointed out in the other answer, since the VBScript InputBox function docs note that If the user clicks Cancel, the function returns a zero-length string ("") you definitely need to check for an empty/zero-length string.

How to extract context informationm the equivalent of __LINE__, __FILE__,etc., in VBSCRIPT

I'd like to know how to get the line number of a line in vbscript programmaticly either at the point of the code like __LINE__ or more ideally a way to get the line number of where the current function was called like python's stack module so I can write a reusable debugging function(and the file the code is located in) and no I don't want to know how to turn on line numbers in my editor.
Also I'd like to now any similar useful information that can be extracted such as calling function, variable type as string, etc.
Unfortunatly that doesn't work the way like in Ruby and Python. The next best thing i worked out is putting a call to a errorhandling function everywhere where things could go wrong. The numbers in the parameter of this function are adapted each time i execute a macro in my editor (i use textpad, the \i is autonumbering in a Regular Expression). If your editor doesn't support this you could write a script that does this. So when an error occurs, it is logged with the number the errorhandling function was called and you can easily find it back in the source by looking for #number#.
This is usable for both asp and vbs but for vbs there is an easier way.
Some editors like textpad or sublimle text let you execute a vbs script, show the output in a tab and if an error is produced let you double click the line with the errormessage which opens the script at that line. This is also done by a regular expression. Let me know if you need the one for textpad.
on error resume next
'initialize constants DEBUGLEVEL and LOGFILE
'initialize strHostName
'some code
oConn.execute(sql)
if not LogError("#1#") then
'do the things if successfull, otherwise log error with number
end if
'again some code
if not LogError("#2#") then
'do the things if successfull, otherwise log error with number
end if
'the debug and log functions
function LogError(errornumber)
'LogError\(\"#[0-9]+#\"\) replace by LogError("#\i#")
if err.number <> 0 then
call debug("<name of script>/Logerror","","","Errornumber:" _
& errornumber & " " & err.number & " " & err.description & " " _
& err.source)
LogError = True
err.clear
errors = errors+1
else
LogError = False
end if
end function
function Debug (pagina, lijn, varnaam, varinhoud)
if DEBUGLEVEL > 0 then
const forReading = 1, forWriting = 2, forAppending = 8, CreateFile = True
dim fs,f, var, strHostName
set fs=CreateObject("Scripting.FileSystemObject")
strHostName = fs.GetFileName(WScript.FullName)
if fs.FileExists(LOGFILE) then
set f=fs.OpenTextFile(LOGFILE, forAppending)
else
set f=fs.OpenTextFile(LOGFILE, forWriting,true)
end if
var = now & " " & pagina & ":" & lijn & ":" & varnaam & ":" & varinhoud
f.WriteLine var
if LCase(strHostName) = "cscript.exe" then 'debugging
if DEBUGLEVEL > 1 then
wscript.echo var
end if
end if
f.Close
set f=Nothing
set fs=Nothing
end if
debug = true
end function
VBScript doesn't expose that information, so you can't access it programmatically from within the script (edge cases notwithstanding). You're going to need a debugger for extracting this kind of information. Or you could have another script interpret the first one and keep track of line numbers (like this). I wouldn't recommend the latter for any kind of production environment, though.
As long as it's happening outside of a function, the following works.
Automatic error-handling is turned off at the start of the script by On Error Resume Next, so that the script doesn't just exit before you can do anything. BUT, you can then turn error-handling back on using On Error GoTo 0 and Raise an exception yourself. That will output the line number in addition to any of your debugging messages.
For example:
On Error Resume Next
server = WScript.Arguments(0)
If Err.Number <> 0 Then
WScript.Echo("Need to pass in an argument!")
On Error GoTo 0
Err.Raise(1)
End if
If you run this without any arguments, you get the following output:
Need to pass in an argument!
C:\script.vbs(6, 5) Microsoft VBScript runtime error: Unknown runtime error
The "6" refers to the line number where the exception was raised.
This way you can print custom output, and also you'll know what line the error happened at.
Yes!
There is a way to get the exact error line number, but it's HUGLY, as we are talking about an ancient programming tool....
And yes, it is worth it, especially if your code is going to run in front of many users. That way you can get past isolating and reproducing the bug, right to solving it.
Take a close look at the last variable "Erl" in the line of code below. It is an undocumented global variable the VB script processor holds.
Dim sErrorMsg as String
sErrorMsg = Err.Description & "(" & Err.Number & ")" & vbNewLine & "Source: " & Err.Source & vbNewLine & "At line number: " & Erl
In order to get anything from that global "Erl" variable you need to (manually)** set its value at the beginning of each line of code as shown below. Beware, you set the line number, if you forget to set the number for a specific line, Erl will report the last set value. See the division by zero error line, it reports the line number set above because I did not set a line number value at the beginning of the line that caused the error.
I have not figured out the inbuilt call stack, though I know there is one. Please let me know if you figure that one out, for now I use a module level variable to build the stack.
More tips at the very end, below this code sample
Sub WhatEverSub ()
2 Const iColIdxPageNbr As Integer = 2
3 Const iColIdxDefinition As Integer = 3
5 Dim oDoc_Source As Document
6 Dim oDoc_Target As Document
10 Dim oTable As Table
11 Dim oRange As Range
12 Dim n As Long
13 Dim strAllFound As String
14 Dim Title As String
15 Dim Msg As String
On Error GoTo PrepErrorHandler
Dim xyz As Long
xyz = Rnd(3) / 0
16
17 Title = "Evil Finder - This program is about doing something important for the world"
18
19 'Show msg - stop if user does not click Yes
20 Msg = "This macro finds all evil things consisting of 2 or more " & _
"uppercase letters and extracts the hex representation to a table " & _
"in a new document." & vbNewLine & vbNewLine & _
"Do you want to continue?"
21 If MsgBox(Msg, vbYesNo + vbQuestion, Title) <> vbYes Then
22 Exit Sub
23 End If
(... whatever code ...)
820 Application.ScreenUpdating = True
830 If n = 1 Then
840 Msg = "No evil things were found. Need to find better detection tool"
850 oDoc_Target.Close savechanges:=wdDoNotSaveChanges
860 Else
870 Msg = "Finished extracting " & n - 1 & " evil thing(s) to a new document."
880 End If
PrepErrorResumeLine:
890 MsgBox Msg, vbOKOnly, Title
'Clean up
1000 Set oRange = Nothing
1010 Set oDoc_Source = Nothing
1020 Set oDoc_Target = Nothing
1030 Set oTable = Nothing
Exit Sub
PrepErrorHandler:
Msg = Err.Description & "(" & Err.Number & ")" & vbNewLine & "Source: " & Err.Source & vbNewLine & "At line number: " & Erl
Resume PrepErrorResumeLine
End Sub
**Some more tips:
1)
As for setting the error line number values manually, I wrote a utility (more than a decade ago) to automate the addition or removal or renumbering of all lines in a module by working directly on the VB project files (or standalone .vbs files), but the below will take care of the basic, with a few manual adjustsments remaining...
Set up VB code line #s using MS Excel
a) paste code in column C
b) set column A's first cell value to 10, and second to 20 and drag copy down to auto increment until you reach the last line/row of code in column B
c) in column B paste in the following formula and drag copy down =A1 & REPT(" ", 8 - LEN(A1))
d) copy columns B and C back into the VB code pane et voila!
Strip out the line numbers to do major edits using Word
Paste the code in,
Hit CTRL + H and make sure wildcards is checked (click the "more" button)
Fill in the following settings
FIND
[^13][0-9 ]{4}
REPLACE
^p
Done!
2)
number each line in increments of 10 at least so you can wedge in a few lines at the last minute without having to renumber each line below your change
3) On Error Resume Next is evil and will cost you a lot of debugging hours!
At least 90% of the time, one should use a specific handler, or nothing. If you do not already know how to recover from an error, do not use RESUME NEXT to silence it, instead, log all the details (using Erl) and learn from the run time logs and use GoTo 0 'Zero, not the letter O to let the rest of the errors bubble up the call stack.
On Error GoTo MyErrorHandlerSection
(... write your risky code here ...)
On Error GoTo 0
'the line immediately above disables all error handling in the current function, if any error happens, it will be passed to the calling function
Nothing prevents you from adding another handling section in the same function if you have another chunk of risky code using
On Error GoTo MySecondErrorHandlerSection

Issue with variable set to variable in VBS

In a VBS I have which I use in conjunction with SecureCRT to automate some processes on Cisco devices, I have (very much pared down) the following code:
Sub prConnectToHost(strConnectHost)
'If no host is passed into subroutine then we need to prompt for one.
If strConnectHost = "" Then strConnectHost = LCase(crt.Dialog.Prompt("Enter hostname or IP address:", "Connect to a host", strHost, False))
strHost = strConnectHost
'If user hits Cancel or hits Ok with no hostname entered then exit.
If strHost = "" Then
booReconnect = False
Exit Sub
End If
'Write to connection log
Call prWriteToConnectionLog
'Run command capture subroutine.
Call prCommandLoop
Set intWaitString = Nothing: Set strScreenGet = Nothing
Set strLatestScriptVersion = Nothing: Set strConnectHost = Nothing
End Sub
Sub Main has a section like this:
Do While booReconnect = True
Call prConnectToHost("")
Loop
crt.Dialog.Prompt is the same as MsgBox, only it centres on the window and not the screen, so it's a little neater. The variable strHost is the actual hostname string which is global in the script and contains the hostname we want to connect to. It is used in the Prompt line as a default text, the idea being that if you disconnect and the booReconnect flag is set, this Sub is called again, and next time you're prompted for a hostname the old one is there - useful if you spelled it wrong first time, or you're connecting to a bunch of devices with a similar name.
You can see where we call prCommandLoop at the end of this Sub, which is a loop which uses a crt Function called WaitForStrings which puts the script on hold until it finds a particular string sequence. When it does, it fires off some stuff, then loops back around until it sits waiting again.
One of the automation commands detects for the presence of the connection menu (so therefore we have quit the router session) and prompts the user for another hostname to connect to.
The important bit is in the variable clearup at the end - Set strConnectHost = Nothing. If I leave this in and immediately exit prCommandLoop with booReconnect set, as soon as Set strConnectHost = Nothing is applied, strHost dies - if I try to reference it I get an error Object Variable not set. I experimented with putting a MsgBox strHost line right at the end of the Sub, which proved this.
The bizarre thing is that if I choose a different automation command in prCommandLoop first and then quit the session, the Set strConnectHost = Nothing doesn't seem to bother anyone.
Can anyone help me explain why this is a problem, as it is baffling me. I can easily work around it (by not issuing Set strConnectHost = Nothing at the end of the prConnectToHost Sub), but I just want to understand what the problem is.
Set is used to assign objects to variables. Think of Nothing as a very special object
>> WScript.Echo IsObject(Nothing)
>>
-1
which is useful only to indicate the emptiness of the variable. Your
Set strConnectHost = Nothing
assigns this Nothing to strConnectHost. After that, the variable is good for nothing - it holds the empty object that can't be printed or used in computations or asked to do methods.
The type prefix fraud (*str*ConnectHost) should alert you that this is fishy. You work with strings (and numbers?); to clear/reset them use (simple) assignment with Empty:
>> strConnectHost = Empty
>>
>> WScript.Echo IsEmpty(strConnection)
>>
-1
or with a suitable value:
intWaitString = -1 ' or 0 ...
(assuming intWaitString isn't another type prefix fraud).
SECOND ATTEMPT:
I assume you call your sub like this:
strHost = "SomeHost"
prConnectToHost strHost
The relevant digest of your sub is:
Sub prConnectToHost( [ByRef] strConnectHost)
...
Set strConnectHost = Nothing
End Sub
As VBScript uses by reference passing of parameters as default, your modification
changes the caller variable strHost. This happens to non-object variables too:
Dim sVar : sVar = "String 0"
WScript.Echo 0, sVar
changeString sVar
WScript.Echo 1, sVar
Sub changeString( sByRefVar )
sByRefVar = "String 1: changed by changeString( ByRef sByRefVar )"
End Sub
output:
0 String 0
1 String 1: changed by changeString( ByRef sVar )
In your case the modification assigns Nothing to the variable that is called
strConnectHost in the Sub and strHost on the caller level. As I said before,
that makes the variable useless (except of testing for Is Nothing).
I hope that explains the clobbering of strHost.
WRT 'memory management': Except for very special cases, you don't need to
clear/reset/SetToNothing variables in VBScript. Using local variable in your
Subs/Functions is all that is necessary. If you decide to use global variables
and manage their state yourself, you must pay attention to the variable types:
Changing the type from object (including Nothing) <=> non-object and lying
about types by misleading type prefixes is dangerous/a sure way to desaster.
If you think you must clear strHost, assign Empty or "" to strConnectHost.
NEXT ADDITION
All VBScript variables are Variants, but not all Variants are created equal:
>> s0 = "string"
>> s1 = CStr( 12.35 )
>> WScript.Echo TypeName( s0 ), TypeName( s1 )
>>
String String
>> n0 = 1
>> n1 = CByte( n0 )
>> WScript.Echo TypeName( n0 ), TypeName( n1 )
>>
Integer Byte
TypeName() and VarType() show the sub-types and a progammer can use a set of
C[hange/onvertTo]<Type>() functions to enforce them - to a degree, as assignments
may change types 'under the hood'.
>> WScript.Echo TypeName( n0 ), TypeName( n1 )
>>
Integer Byte
>> n0 = 1.1
>> n1 = 2 ^ 20
>> WScript.Echo TypeName( n0 ), TypeName( n1 )
>>
Double Double
There are even Type Mismatch Errors:
>> WScript.Echo Nothing
>>
Error Number: 13
Error Description: Type mismatch
>>
>> WScript.Echo s0 Is Nothing
>>
Error Number: 424
Error Description: Object required
So sub-types matter. Some people think type prefixes are uncool, but others see
them as valuable help in weakly typed languages. If you decide to use them, you
should use them correctly -
Set strWhatEver = objWhatever
objWhatever = intWhatever
intWhatever = objWhatever
If strWhatEver = intWhatever Then
all smell (of not paying attention to types and hard to pin down errors in later code).

Resources