Im just trying to understand this code Im working with. I can find sources for single digits # https://learn.microsoft.com/en-us/office/vba/language/reference/user-interface-help/shell-function
Though I dont see anything there or online
Shell ("rundll32.exe """ & App.Path & "\SomeFile.dll"",F1")
'This is from the linked source earlier Shell (pathname, windows style)
It may also be using rundll32.exe as for adding the optional F1 arguement
https://support.microsoft.com/en-us/help/164787/info-windows-rundll-and-rundll32-interface
Though I dont see any docs on F1 there either
I could be misreading the quotes. But im pretty sure its passing in the path like so. "rundll32.exe\App.Path\somefile.dll" and the second argument is F1
If someone could either tell me I'm wrong on my quotes and F1 is an argument that would be enough. If it isn't an its a windows style. What it means would be great. Thank you.
As written, with the quote marks as they are, F1 is not an argument to Shell. It's an argument to rundll32 and is the entry point into SomeFile.dll. This is explained in the link you referenced to rundll32.
Related
So, reading this documentation:
https://learn.microsoft.com/en-us/visualstudio/ide/reference/immediate-window?view=vs-2022
It looks like the question mark (?) is an alias for the command >Debug.Print, which basically, will evaluate the expression and show the result.
So, in debug mode, instead of running this:
>Debug.Print DoSomething()
I can run this:
? DoSomething()
This is even better because I'm getting the autocomplete suggestions.
Now, the issue is that I can run the same line without a command at all, and it does exactly the same:
DoSomething()
So far looks like there is no need for the command >Debug.Print or the alias ?.
At first, I suspected that using ? will only print the result without changing the values, but this is not the case (When I assign a value to a variable using ? it is assigned and the new value is printed)
So, am I missing something here? Are there any other differences between these 3 options?
According to the documentation, if you want to use Visual Studio command, you need to add greater than sign before the command. If you run 'Debug.Print' without adding greater than sign, you will get an error.
My point is that the question mark ('?') is unnecessary if you in the Immediate Window, it is used to distinguish the typed expression from the result.
I'm trying to get Word to fill in cells in a table. The script works when run as a macro from within Word, but fails when saved as a .vbs file and double-clicked, or run with wscript. This is a part of it.
set obj = GetObject(,"Word.Application)
With obj
With .Selection
MsgBox .text
If (.Information(wdWithInTable) = True) Then
.Collapse Direction:=wdCollapseStart
tCols = .Tables(1).Columns.Count
tRow = .Information(wdStartOfRangeRowNumber)
tCol = .Information(wdStartOfRangeColumnNumber)
For I = 2 To 5
.Tables(1).Cell(tRow, I).Range.Text = "fred" & Str(I)
Next
` now make new row
For I = 1 To tCols - tCol + 1
.MoveRight unit:=wdCell
Next
End If
End With
End With
I have three problems. First, it won't compile unless I comment out the .Collapse and .MoveRight lines. Second, although the MsgBox .text displays the selected text, I get "out of range" errors if I try to access any .Information property.
I'm sure I'm missing something very simple: I usually write software for Macs, and I'd do this using AppleScript. This is my first attempt at getting anything done under Windows.
VBScript and VBA are different languages.
They are a bit similar, but not very. Moreover, VBScript is not like AppleScript; it doesn't let you easily interface with running programs.
The interfaces you'll get from VBScript can behave subtly differently in VBA and VBScript. However, I think you've got two problems here:
:= is invalid syntax in VBScript; you'll need to find an alternative way of calling the function. Try just using positional arguments.
You've no guarantee that this will open the expected file; there could be another instance of Word that it's interacting with instead.
Since your code is not running within the Word environment it would require a reference to the Word object library in order to use enumeration constants (those things that start with wd).
VBScript, however, cannot work with references, which means the only possibility is to use the long value equivalents of the enumerations. You'll find these in the Word Language References. Simplest to use is probably the Object Browser in Word's VBA Editor. (In Word: Alt+F11 to open the VBA Editor; F2 to start the Object Browser; type in the term in the "Search" box, click on the term, then look in the bottom bar.)
The code in the question uses, for example:
wdWithInTable
wdCollapseStart
wdStartOfRangeRowNumber
wdStartOfRangeColumnNumber
wdCell
The reason you get various kinds of errors depends on where these are used.
Also, VBScript can't used named parameters such as Unit:=. Any parameters must be passed in comma-delimited format, if there's more than one, in the order specified by the method or property. If there are optional parameters you don't want to use these should be left "blank":
MethodName parameter, parameter, , , parameter
I have the following code:
Set objHoldGroup = GetObject("LDAP://" & objGroup)
strGroupDesc = (objHoldGroup.Description)
WScript.Echo(strGroupDesc)
The variable strGroupDesc returns nothing when echoed. I can output the description directly but I need it for further processing. Thoughts?
Explanation: Apparently your script sets Option Explicit (good), which you didn't tell us about (bad). This option makes defining variables before you can use them mandatory (good). Normally that would raise an "undefined variable" error, though. Since that doesn't seem to happen with your code, you seem to also have an On Error Resume Next somewhere in your code (very bad), which, again, you chose to keep quiet about (bad).
Next time please don't omit parts of your code that are vital for troubleshooting the problem. And don't use On Error Resume Next.
Issue found: I forgot to Dim strGroupDesc.
Hello I have 2 batch files, it works perfectly on one machine but not so perfect on another.
Here is the code.
set /p "ln=" <"C:\LoginSystem\userl.txt"
set "%ln:&="&set "%"
set realuser=%user:"=%
echo %realuser%
So on my machine it shows like this:
echo Liam
Liam
On the other machine it shows like this:
echo "=
"=
It's the exact same machines only difference is one is running Windows 8 (working) and the other windows 7 ("=)
EDIT:
Thank you all for the answers, I managed to solve this by editing the way the userl.txt file is generated to make it display just the name, e.g "Liam" without quotes. Then use this
set /p user=
That seems to work for what I need s there is only 1 value ever going to be in that file.
Thank you all!
A simple echo %thisvariabledoesnoexist:"=% will show the same result.
The reason for the observed output is that the variable %user%, that seems that have to been assigned a value in the set "%ln:&="&set "%" line, did not get any value.
The problem is probably that the input line does not contain the required value or the format of the input line is different from the expected one.
As MC ND has pointed out, the critical point is that variable user must be defined to work properly. If it is not defined, then you get your problem result.
I don't see how identical user1.txt files being processed on two machines with identical batch scripts can possibly give different results as you describe.
Strike that, I can think of one way, but it is a long shot. The assumption is the first two lines are supposed to define the user variable, perhaps along with other variables. But suppose the first two lines do not define the user variable on either machine. Perhaps user is already defined on the machine that "works" before the script is even run, and it is not defined on the other machine. That is the only thing I can come up with that would yield the result you describe.
I do see one thing that concerns me in your code. The following line of code implies that sometimes you get quotes in your input.
set realuser=%user:"=%
You state that quotes in your value interfere, so you remove them. But you are removing them too late! The prior line may not set all the values properly if there are quotes in the value of ln.
Try the following:
set /p "ln=" <"C:\LoginSystem\userl.txt"
set "ln=%ln:"=%"
set "%ln:&="&set "%"
echo %user%
I usually get this new window open up suddenly while I am editing a Ruby file in VIM. This is getting irritating because, i cant type in anything while its processing. And it usually happens arbitarily. Does any one here know which plugin could be doing this? Or is this somekind of VIM's process?
This is happening when you hit K in normal mode.
K Run a program to lookup the keyword under the
cursor. The name of the program is given with the
'keywordprg' (kp) option (default is "man"). The
keyword is formed of letters, numbers and the
characters in 'iskeyword'. The keyword under or
right of the cursor is used. The same can be done
with the command >
:!{program} {keyword}
There is an example of a program to use in the tools
directory of Vim. It is called 'ref' and does a
simple spelling check.
Special cases:
- If 'keywordprg' is empty, the ":help" command is
used. It's a good idea to include more characters
in 'iskeyword' then, to be able to find more help.
- When 'keywordprg' is equal to "man", a count before
"K" is inserted after the "man" command and before
the keyword. For example, using "2K" while the
cursor is on "mkdir", results in: >
!man 2 mkdir
- When 'keywordprg' is equal to "man -s", a count
before "K" is inserted after the "-s". If there is
no count, the "-s" is removed.
{not in Vi}
If you notice, it's running ri in the open window, which is the ruby documentation app.
In Unixy environments, the help program normally runs inline, just displacing the vim output for a minute.
Is this using gvim, or command-line vim?
In either case, you can try monkeying with 'keywordprg' to fix the popup
Or, if you can't train yourself not to type it, you can just use :nnoremap K k to change what K does (in this case, just treat it as normal k command and go up one line).
I have this same issue on my work desktop, but not my home machine. The setups are near identical.
While stalking down a possible cause, I noticed that when I leave my cursor over a Ruby symbol such as File, Vim would popup a short description of the File class. After comparing all the various vim scripts and ri-related files that I could find, I finally settled on the only solution that worked...
Open $HOME/_vimrc and add the following line:
autocmd FileType ruby,eruby set noballooneval
Previously, I commented out a block in $VIMRUNTIME/ftplugin/ruby.vim, but Brian Carper suggested a better solution of :set noballooneval. I added the autocmd line so it is only executed with Ruby files.
If anyone figures out a true solution, please contact me. :(