Issue: I need to change the UFT's Remote Agent Settings(image attached) programmatically on a machine before running my test set on that machine.
Method(s) tried so far:
I looked up on the internet and found that all the Remote Agent's Settings' values are placed inside the file mic.ini which is placed inside the bin folder in UFT's installation directory. I thought of opening the file as textstream using a filesystem object and make the required changes. But, it turns out, that I do not have admin rights on that bin folder due to which I am not able to save the changes made in mic.ini file(error: Access is Denied). Unfortunately, Getting the admin privileges is not an option for me.
Apart from this method, I could not find anything which would help me to accomplish this task.
Is there any other way I can change these settings programmatically? Is there an object model for the Remote Agent's Dialog which I can make use of?
Note: This might NOT be the answer you are looking for, but this is what I found and justify itself.
To start with option to uncheck Keep UFT open... option, here is the note directly from UFT help file:
Keep UFT open after a Test Lab run session ends:
By default, when ALM opens UFT on a remote computer during a test set
run (or when it runs selected tests or configurations from the Test
Lab module), it closes UFT at the end of that Test Lab run session.
This ensures that the UFT license is released at that point and made
available for other UFT users.
Selecting this option causes UFT to stay open on your computer (and to
continue using the UFT license) after a Test Lab run session ends.
Note: The behavior described above is relevant only when UFT is opened
from an ALM server that has the SUPPORT_TESTSET_END parameter set to
Y. (Y is the default setting). If UFT is opened from an earlier
version of ALM (or the above-mentioned parameter is set to N), this
option is ignored and UFT always remains open at the end of run
session.
For details on the SUPPORT_TESTEND_END parameter, see the section on
setting ALM configuration parameters in the Application Lifecycle
Management Administrator Guide.
So as mentioned, ALM will close UFT by default if the SUPPORT_TESTSET_END parameter set to Y. So I would check with ALM admin team on this.
Now for option to uncheck Run UFT in debug mode option, you can keep UFT application object's RunMode option to Fast.
Note: You really don't need to do this change as ALM will run UFT scripts in Fast mode by default.
Here is the sample script for understanding:
On Error Resume Next
Dim qtApp '~~> Declare the Application object variable
'~~> Create the UFT Application object
Set qtApp = CreateObject("QuickTest.Application")
'~~> If UFT is notopen then open it
If qtApp.launched <> True then
qtApp.Launch
End If
'~~> Make the QUFT visible
qtApp.Visible = FALSE
If Not qtApp.TDConnection.IsConnected Then
'~~> Make changes in a test on Quality Center with version control
qtApp.TDConnection.Connect "QC URL","DOMAIN Name","Project Name","User Name","Password",False
End If
'--------------------------------------------------------------------
Dim defaultRunMode, fastRunMode, normalRunMode
defaultRunMode = qtApp.Options.Run.RunMode
qtApp.Options.Run.RunMode = "Fast"
fastRunMode = qtApp.Options.Run.RunMode
qtApp.Options.Run.RunMode = "Normal"
normalRunMode = qtApp.Options.Run.RunMode
Msgbox "Different RunModes" & VbCrLf & _
VbTab & "DEFAULT RunMode : " & defaultRunMode & VbCrLf & _
VbTab & "After FAST RunMode : " & fastRunMode & VbCrLf & _
VbTab & "After NORMAL RunMode : " & normalRunMode
'--------------------------------------------------------------------
'~~> Script path and script name in ALM
qtApp.Open "[ALM] Subject\QCScriptPath\ScriptName", False
qtApp.Test.Run
qtApp.TDConnection.Disconnect
'~~> Close UFT
qtApp.quit
'~~> Release Object
Set qtApp = Nothing
'~~> Handle Error
If Err.Number <> 0 Then
Msgbox Err.Number & " : " & Err.Description
Err.Clear
End If
And here is the msgbox output:
Related
I am trying to install a VB6 application in Windows 10 computers, but when I load a child form and then unload it, the program crashes. If I start the application as Administrator from the shortcut, I can load and unload everything without issues. Have you experienced this before?
So far I've tried the following:
Started the .exe directly as Administrator. Not working.
Checked the Run As Administrator checkbox in the contextual menu (Properties / Compatibility) of the .exe. No good.
Created a .reg file to affect the HLKM\ ... \AppCompatFlags\Layers keys. Nada.
Tried affecting both the HKLM AND HKCU keys. Thank you, next.
Checked if some Recordset or variable was filled or active. Everything empty.
Tried Unload [name of the form] instead of Unload Me for one of the forms. Same result.
Part of the Unload code for one of the forms is as follows:
Private Sub cmdSalir_Click()
On Error GoTo ErrHandler
Dim frm As Form 'Identifica las formas a cerrar
For Each frm In Forms
If Not frm Is frmPoliza And Not frm Is MDIPrincipal Then
If Not frm Is frmAsegNoReclam And Not frm Is frmEndosoMedico Then _
Unload frm
End If
Next frm
gsPlan = ""
gmstrInstPagoInd = ""
gmstrCondEnv = ""
If IsFormLoaded("frmCotiza") = False Then
'gbInicio = True
End If
Unload Me
ErrHandler: 'APM 2019-01-31: Captura el error que se provoca al descargar la forma
If Err.Number <> 0 Then
MsgBox "Ocurrió un error al cerrar: " & Err.Number & " - " & Err.Description, vbOKOnly
End If
End Sub
It is important to say that WinXP's installations are working correctly, but in 2 Win10's computers the error was replicated, so I'm guessing either Win10's security policies or the way the installation package is made has something to do with this.
If you can help me with this issue, I will appreciate it greatly.
Thank you,
Tony.
If the issue is that you need to run with elevated rights, then I suggest you declare that in you application manifest such that the user is prompted grant that. You can either create a separate manifest file or embed it. See here for details:
How do I create a manifest file in Visual Basic 6.0?
So I told the client about this issue, and decided to have the program virtualized in XP better than adapted to x64. Not the closing I wanted, but a closing after all.
Thank you all for your efforts.
Not sure if this will fix the specific problem but have found that running the application in Windows 8 Compatibility Mode on Windows 10 helps with issues like this. Worth a try.
Shouldn't you be able to implement the ADOX library via VBScript? The code below runs perfect via Access 2010 on Windows 7, Office 2010 32-bit, but doesn't via a VBScript. Isn't ADOX just another COM Object like say FileSystemObject?
Dim objADOX
Set objADOX = CreateObject("ADOX.Catalog")
objADOX.ActiveConnection = "Provider=Microsoft.ACE.OLEDB.12.0;Data Source=C:\Users\Zamdrist\Desktop\Work\Scripts\Shell.accdb"
MsgBox objADOX.Tables.Count
Sorry, I should point out, VBScript complains that the provider does not exist. Odd because I do in fact have Access 2010 installed.
This is not meant as an answer just simply as a tip that has helped me tremendously. I am constantly working with providers that only work with 32 bit so i always add the attached code to all of my scripts. This way it doesn't matter if the machine that is executing the code is 32 or 64 bit.
'Check for 64 bit and run as 32 bit if needed.
'On error resume next
Set oFso = CreateObject("Scripting.FileSystemObject")
Set oWs = CreateObject("WScript.Shell")
windowsdir = oWs.ExpandEnvironmentStrings("%windir%")
If InStr(LCase(WScript.FullName), windowsdir & "\system32\") And oFso.FolderExists(windowsdir & "\SysWow64") Then
oWs.Run windowsdir & "\SysWow64\WScript.exe """ & WScript.ScriptFullName & """"
WScript.Quit
End If
'code to run as 32 bit
I have a macro runTest in a PowerPoint file test.pptm that I wish to call by using the following VB script. All works well when the script is called on a machine with Office 2010, but the script will only work with Office 2007 providing the PowerPoint application has been opened before calling the script. I'd be interested to hear whether anyone has experienced a similar problem, or to hear of any potential solutions.
Option Explicit
On Error Resume Next
RunProcess
Sub RunProcess()
Dim pptApp
Dim pptPresentation
Set pptApp = CreateObject("PowerPoint.Application")
Set pptPresentation = pptApp.Presentations.Open("C:\test.pptm", True)
pptApp.Run "test.pptm!runTest"
pptApp.Quit
Set pptPresentation = Nothing
Set pptApp = Nothing
End Sub
I resolved the problem by adding
pptApp.Visible = True
after creating pptApp and before opening the presentation.
In the event that it needs Powerpoint launched, I would just trigger the launch as part of the vbscript
Set WshShell = wscript.CreateObject("wscript.Shell")
WshShell.Run "C:\Program Files (x86)\Microsoft Office\Office12\POWERPNT.EXE"
You could build in some error handling to see which version is installed, and call the appropriate exe file
The script work on the local computer but not remotely. Any idea?
I'm getting VBScript runtime error "ActiveX component can't create object: XStandard.MD5".
strSource = "C:\WINNT"
Set objFSO = CreateObject(Scripting.FileSystemObject")
Set objFolder = objFSO.GetFolder(strSource)
Set colfiles = objFolder.Files
For each file in colfiles
Set objMD5 = CreateObject("XStandard.MD5")
Go to the DLL folder and use in command prompt > regsrv32 XMD35.dll
http://www.xstandard.com/en/documentation/xmd5/
When you want to instruct a remote computer to instantiate a given ActiveX object, you need to specify the name of the remote server when calling the CreateObject(progID, [serverName]) function.
Otherwise, the script engine attempts to instantiate the object from the local machine.
For example:
Set objMD5 = CreateObject("XStandard.MD5", nameOfYourServer)
And of course, the component must be available on the server.
More info about CreateObject at MSDN
I don't know if it has anything to do with the syntax of line 2. you are missing an open quotation. You have:
Set objFSO = CreateObject(Scripting.FileSystemObject")
You should have:
Set objFSO = CreateObject("Scripting.FileSystemObject")
I realize this is an old question, but google sent me here with the same problem. In my case it was a 32-bit vs 64-bit issue - I needed to use the 32-bit version of CScript to execute.
More details here http://blogs.msdn.com/b/helloworld/archive/2007/12/12/activex-component-can-t-create-object-when-creating-a-32-com-object-in-a-64-bit-machine.aspx
The XStandard.MD5 is a component that is NOT standard in all computers. it is something that needs to be installed. However even after installing you may still run into the same error. This may be because you are running the script in a 64bit system. for some reason the 64bit wscript won't use the xmd5.dll. however you can make a workaround by associating the scriptfiles to run on the 32bit version of wscript. by
going into your default programs. (Windows 8+ Right click the startbutton area [category view] Click Programs, then Default Programs then Associate a file type or protocol with a program) (Windows 7- click on start then click default programs)
Then click vbs then click change program, change it to
C:\Windows\SysWow64\Wscript.exe
NOTE ONLY ON 64BIT
As dmogle says in his comment, you need to make sure that the component is installed on the remote computer. Assuming that you've got access to that computer, download the dll to it and then run the command regsvr32 XMD5.dll as can be seen here.
On another note, your script looks a little funny, the twp last lines are:
For each file in colfiles
Set objMD5 = CreateObject("XStandard.MD5")
Which means that you'll be creating an instance of the MD5 object for each file. I've never used the component in question, but I'm fairly sure that you probably want to create only one instance of the object and then call the functions on that object multiple times. So I'd suggest changing the order of those lines to:
Set objMD5 = CreateObject("XStandard.MD5")
For each file in colfiles
I have an application written in VB.Net with Visual Studio 2005. The application allows the user to create and save project files. When I distribute the application, I include some demo project files, which I install in the common application data folder.
XP - C:\Documents and Settings\All Users\Application Data
Vista & 7 - C:\Program Data
I have discovered an unexpected behavior -- if any file in the common application data folder is removed, and the application is run from the start menu, then the install procedure will start and attempt to restore the missing file(s). If the MSI file no longer exists at its original location or has been changed, then the application will fail to run. I perceive that this is a "feature", but it is one I don't want. Can anyone tell me what is going on and how I can avoid it?
Some more details:
I created the setup package by using a Visual Studio deployment
project.
This behavior will not occur if I launch the EXE directly. I
expect, therefore, that the behavior has something to do with the
start menu shortcut. I've noticed that the shortcut isn't a normal
shortcut -- it doesn't have a "Target Location".
All advice is appreciated.
-TC
I have learned that this behavior involves something called "Install-on-Demand" (aka "Self Heal"). The unusual shortcuts created by the setup package are called "Advertised Shortcuts". Now that I have a name for the problem, it is easy to find information on how to fix it. Notably:
http://msdn.microsoft.com/en-us/library/aa368297.aspx
http://groups.google.com/group/microsoft.public.dotnet.distributed_apps/browse_thread/thread/401847045f104af3
http://blog.jtbworld.com/2007/11/enable-target-and-change-icon-of.html
Those pages contain a wealth of information. For the convenience of others who may stumble upon this post, I will summarize what they say:
Advertised shortcuts are special shortcuts which do some fancy things. Most notably, they reinstall damaged application before launching their target. There is some debate over whether they are good, evil, or harmless. In my opinion, they do something most users don't expect, and that makes them evil. Therefore, I'd like to disable them for my application.
Visual Studio setup projects automatically create MSI packages which generate advertised shortcuts by default. It is easy to override that default when installing the MSI package by using DISABLEADVTSHORTCUTS=1 as a command-line argument for Setup.exe. Also, with a utility like Orca, you can manually change the default by inserting DISABLEADVTSHORTCUTS=1 as a property of the MSI. However, if you want Visual Studio to automatically create MSI packages which don't create advertised shortcuts, that is harder. I did it this way:
First, I created a VBS file using the DisableAdvt code provided by Gary Chang in one of the links above (I've repeated that code below). Just create a text file, paste in the code. and save it as DisableAdvt.vbs.
Then, create a post-build event for your setup project. The exact syntax will depend on your file locations. Because my DisableAdvt.vbs is in a "Tools" subfolder of the solution folder, my post-build event looks like this:
"$(ProjectDir)..\Tools\DisableAdvt\DisableAdvt.vbs" "$(BuiltOuputPath)"
That's all I had to do. It works like a charm.
-TC
Some notes:
In Visual Studio 2005, Build events are accessed differently for setup projects than they are for other types of projects. Click on the project name in the solution explorer, then look for PostBuildEvent in the Properties pane.
Orca is a utility that can be used to manually insert the DISABLEADVTSHORTCUTS property into the MSI file. With my approach, Orca is not necessary. However, it is useful for verifying that the build event is making the expected change.
http://www.technipages.com/download-orca-msi-editor.html
In the build event, the misspelling "BuiltOuputPath" is intentional.
Here is Gary Chang's DisableAdvt.vbs code (note that I fixed a typo on line 21 -- Very important!):
Option Explicit
Const msiOpenDatabaseModeTransact = 1
Dim argNum, argCount:argCount = Wscript.Arguments.Count
Dim openMode : openMode = msiOpenDatabaseModeTransact
' Connect to Windows installer object
On Error Resume Next
Dim installer : Set installer = Nothing
Set installer = Wscript.CreateObject("WindowsInstaller.Installer") :
CheckError
' Open database
Dim databasePath:databasePath = Wscript.Arguments(0)
Dim database : Set database = installer.OpenDatabase(databasePath, openMode) : CheckError
' Process SQL statements
Dim query, view, record, message, rowData, columnCount, delim, column
query = "INSERT INTO Property(Property, Value) VALUES ('DISABLEADVTSHORTCUTS', '1')"
Set view = database.OpenView(query) : CheckError
view.Execute : CheckError
database.Commit
If Not IsEmpty(message) Then Wscript.Echo message
Wscript.Quit 0
Sub CheckError
Dim message, errRec
If Err = 0 Then Exit Sub
message = Err.Source & " " & Hex(Err) & ": " & Err.Description
If Not installer Is Nothing Then
Set errRec = installer.LastErrorRecord
If Not errRec Is Nothing Then message = message & vbLf & errRec.FormatText
End If
Fail message
End Sub
Sub Fail(message)
Wscript.Echo message
Wscript.Quit 2
End Sub