I'm currently working on simplifying a process at work. It involves a Chatillon DFIS Force Meter which uses a serial connection to transmit data. The data gets sent to the Chattillon program as text and can only be saved as a .dat file. I'm trying to set up an Excel workbook that can just automatically open the program and have different commands to put the information straight into Excel. The Commands would involve changing the units, zeroing the sensor, and transmitting.
I've done some looking around and found that the Shell feature gives you access to opening the file and should help allow you to control it but I haven't found a way to call and manipulate the program through Excel.
Chatillon Program, basically buttons to click with a mouse
Excel and VBA can control external applications if they have a COM interface - that is to say, if you can declare the application as an object, create an instance of the object, and see its methods and attributes.
If you can possibly get hold of a COM wrapper for your program, do it that way.
If you can't... You won't enjoy doing it using I/O streams and a Windows Shell object, because command-line DOS interfaces aren't particularly friendly as a User Interface, and they are flakier than breakdancing in a pastry factory when you try to use them as an API in VBA.
Firstly, you need the 'WshShell' object exposed by the Windows Script Host Object Model. You can declare and instantiate it by late binding as shown:
Dim objWshell As Object
Set objWshell = CreateObject("WScript.Shell")
But the correct method (which will give you Intellisense drop-downs of the properties and methods) is to use the 'Tools:References...' dialog to create a reference to the parent library, which is usually found at C:\Windows\System32\wshom.ocx
You can then declare the Shell object as:
Dim objWshell As IWshRuntimeLibrary.WshShell
Set objWshell = New IWshRuntimeLibrary.WshShell
Running a command-line executable and reading the I/O streams in VBA:
This is an example that opens a command window and runs a command-line executable, feeding it a command-line switch '-s' and a parameter encapsulated in double quotes.
Note that the executable I'm running is NOT 'regsvr32.exe' - my shell object is executing cmd.exe, and that is the source and sink of the I/O streams.
You can, of course, run your application directly. It might work. But it is very common for the output stream to lock or 'hang' your calling function and its VBA thread when you call .StdOut.ReadLine or .StdOut.ReadAll - you have been warned.
With objWshell.Exec("CMD /K")
.StdIn.WriteBlankLines 3
.StdIn.WriteLine "C:"
.StdIn.WriteLine "CD C:\"
.StdIn.WriteLine "regsvr32.exe -s " & Chr(34) & "%LIBDIR%\FXPricer.dll" & Chr(34)
.StdIn.WriteBlankLines 1
Do Until .StdOut.AtEndOfStream
Debug.Print .StdOut.ReadLine
Loop
Do Until .StdErr.AtEndOfStream
Debug.Print .StdOut.ReadLine
Loop
.Terminate
End With
Share and Enjoy. And, as always, watch out for line breaks inserted by your browser (or by StackOverflow's textbox interface) in the source code samples.
Related
Background:
Recently, a macro I use via VBA (in Excel) to run a script has stopped working; this subroutine worked for the previous six years. This is on a work device in which I do not have full admin privileges. The script file is stored on a network drive which I have access to, and can open and double-click to execute.
I have read from multiple sources, each not having an answer (including here on SO), that people have begun to see RTE5 when using Shell(), which may be related to security settings from the administrator.
One suggestion was to use use ShellExecute, which I have not had luck using.
Issue:
I receive RTE5 (invalid procedure call or argument) on the line for Shell() within the below code.
Question:
Has anyone had this same issue and been able to resolve said issue? Please indicate how you resolved.
Code:
'To open file, which previously worked:
Dim Loc As String
Loc = "Z:/filename.bat"
Call Shell(Loc, 1)
'Attempt at using ShellExecute, which gives Network Access error
Dim Loc As String
Loc = "Z:/filename.bat"
Call CreateObject("Shell.Application").ShellExecute(Loc, 1)
I use SQUISH to perform automated tests (written in python) on a GUI application (based Linux SUSE 15) with Qt version 5.9.4.
This application contains objects with properties (example name of a menu) containing the character "&".
My test script crashes everytime an object containing the character "&" (in its properties) is called in the script.
The error is :
"LookupError: Object 'Hardwired links from RCSL to turbine I&C' not found
For debugging, I erase this character from the the application design ==> No more issues were observed, the test scripts passed.
But, it is not a sustainble solution, I need the "&" character in my application.
Do you guys have any information about SQUISH having problem with managing certain characters as "&" ?
The error message may indicate a special case: Using the plain text of an object to look up the same.
Please do not use this undocumented (and generally unsupported) approach.
Instead, please record an interaction with the respective object, and then make use of the object name that Squish automatically generated for it.
Or pick the object and copy the object name.
I have a Windows Forms application with an OpenFileDialog. The user clicks a "Process" button and the application goes through the file - an Excel spreadsheet - and processes the data in it. All of this works as expected with one caveat.
After the application is done processing, the file remains locked for editing so when I open the file to make changes, I get this message:
If I close the application completely, the file is unlocked so I'm assuming the application is just holding onto the file for longer than it should. I'm guessing there should be some sort of Close() method or something that will release the resources but I can't figure out exactly what I need. I tried using Dispose() and wrapping my code in a Using block which I thought destroyed everything automatically but no luck.
Here's my code:
Using excel = New ExcelPackage(OpenFileDialog1.OpenFile)
Dim ws = excel.Workbook.Worksheets.First()
'Process data in ws...
OpenFileDialog1.Dispose() 'Doesn't seem to release the file
excel.Dispose() 'Doesn't seem to release the file
End Using
The OpenFileDialog.OpenFile Method returns a Stream object that likely is not being closed by the ExcelPackage.
To ensure that the stream is released, use the following pattern.
Using strm As IO.Stream = OpenFileDialog1.OpenFile
Using excel = New ExcelPackage(strm)
' ...
End Using
End Using
I have a VB6 application that, despite everything manages to work on lots of systems, including the numerous Windows 7 x64 systems.
On most of them, the windows dialogs accessed through COMDLG32.OCX work just fine. However, on one particular system, this doesn't work at all. Some forms, when attempting to show the "Open" (or "Save") dialog causes an exception:
Run-time error '32765'
The common dialog function failed during initalization. This error often occurs when insufficent memory is available
Although some other forms that use it simply never show the dialog box at all. Needless to say, memory is not an issue. Microsoft have a kb article on the error where they say:
You have a Microsoft Visual Basic 6.0 program that runs on a Terminal Server, the program uses the Common Dialog control to open a file, and the following conditions are true:
The user is using a roaming profile.
There is a policy to delete the roaming profile when the user logs off.
When these conditions are true, you may receive [the error quoted above]
The conditions mentioned are not true - this is all through the (only, local) user on the system. The suggested solution involves calling the relevant API calls directly.
Reluctant to implemenet the pile of code suggested in every form relevant, I found a class already built for the purpose - CDlgEx. While this works fine on all the computers where the OCX also works fine, on the system which has problems, whenver this line is reached:
RetValue = GetOpenFileName(OFN)
where
Private Declare Function GetOpenFileName Lib "comdlg32.dll" Alias "GetOpenFileNameA" (pOpenfilename As OPENFILENAME) As Long
and OFN is of the private type expected by the function, nothing happens. No dialog box appears, and the program simply moves on to the next line.
Further testing has shown that this only happens when running from the IDE. Running from a compliled executable, everything is fine.
Had the exact same problem. Grab the cCommonDialog class from the following link and add it to your project.
https://github.com/ziggythehamster/ignitionserver/blob/master/vbtracer/cCommonDialog.cls
You can then do something like this in your code
Private Sub Command1_Click()
Dim commonDialog As New GCommonDialog
Dim fileName As String
commonDialog.VBGetOpenFileName fileName
MsgBox fileName
End Sub
I am using visual studio 2008 and MFC. I accept arguments using a subclass of CCommandLineInfo and overriding ParseParam().
Now I want to pass these arguments to the application while running. For example "test.exe /start" and then to type in the console "test.exe /initialize" to be initialized again.
is there any way to do that?
Edit 1: Some clarifications. My program starts with "test.exe /start". I want to type "test.exe /initialize" and initialize the one and only running process (without closing/opening). And by initialize I mean to read a different XML file, to change some values of the interface and other things.
I cannot think of an easy way to accomplish what you're asking about.
However, you could develop your application to specifically receive commands, and given those commands take any actions you wanted based upon receiving them. Since you're already using MFC, you can do this rather easily. Create a Window (HWND) for your application and register it. It doesn't have to be visible (this won't necessarily make you application a GUI application). Implement a WndProc, and define specific messages that you will receive based on WM_USER + <xxx>.
First and obvious question is why you want to have threads, instead of processes.
You may use GetCommandLine and CommandLineToArgvW to get the fully formatted command line. Detect the arguments, and the call CreateProcess or ShellExecute passing /watever to spawn the process. You may also want to use GetModuleBaseName to get the name of your own EXE.