I am trying to prepare a script in Neoload application using SAP GUI protocol but facing few issues while replaying the script. There is one button with object type as GUI Shell and with Neoload while recording we are able to click the checkbox but while replaying the script we are not able to click any buttons/checkboxes with object type as GUI Shell
I am attaching two screenshots below, one with the object type as GUI Shell and other with the object type as GUI checkbox . We are able to click on the objects whose object type is GUI checkbox but GUI shell type objects are not clickable.
We are using Neoload 7.11.3 version and SAP GUI 7.70 version.
Any solutions to resolve the above issue?
Related
I'm automating the following program via Python: (Surfer)
http://www.goldensoftware.com/products/surfer
Some portions of it i cannot control using win32com.client (the program libraries do not support it). The part i need to get working can be done by using the programs menu bar. It's just 5 clicks i need to get done. So as an alternative i have been trying to use pywinauto (my first try with this). But this time i can not get the menu bar items. I tried analyzing the menus via swapy (https://github.com/pywinauto/SWAPY) but the MenuItems field show up empty (as an empty list []).
here is some test code:
from pywinauto.application import Application
app = Application(backend="uia").connect(process=2984) # tried "win32" as backend also
srf = app.window(process=2984)
srf.menu_select("Help")
I get the error:
"RuntimeError: There is no menu."
The menus I am trying to access are within:
Edit
Arrange
Geoprocessing
Any help will be appreciated.
I finally was able to get the menu controlled via pywinauto:
app_dialog.child_window(title="Menu Bar").set_focus()
From there is was a matter of controlling the keyboard with the SendKeys() module.
It's a workaround but it gets the job done.
Is there any workaround to execute an automation script over dialog in Maximo and next close it with dialogok event using the same push button?
It's probably not the answer you want to hear, but as of Maximo 7.6.0.8 (the latest version currently available), the only "workaround" would be a custom Java Bean class.
It's is possible to trigger two actions with one button. I've not tested it with automationscripts though....
For example use this in de button xml:
mxevent="dialogok" value="ROUTEWF"
You can add a sigoption with the same name as the action and make sure that you expand the 'Advanced Signature Options' section and set 'This is an action that must be invoked by user in the UI'.
You could create and object launch point automation script therefore when you click OK in the menu the object will be saved and the automation script triggered.
If you already know that some field is going to be update, you could do it with an attribute launch point for that object.
It seems the only way to open a client-side dialog is from within an embedded control which doesn't work for me. Most of my coding to populate the dialogs is contained in an external script library, yet when I try to XSP.openDialog(id) I receive a jumbled javascript error on Firebug.
I have tried
Accessing the object (an extension library dialog) directly from a button on the xpages. It opens without a problem
Calling a script function from an embedded button and passing the id of the dialog. Error.
Created a global variable containing the id of the dialog and called directly from a button. WORKS
Same global variable, but called in a javascript function. ERROR
from within script created variable with dojo.byId. ERROR
Is there something else I need to configure? Many of the buttons I will be using are also dynamically generated from a JSON-supplied feed.
We are using coded ui test using visual studio 2010.We are testing .Net 4.0 windows application.
Here is an scenario.
We have an windows app which has a button named submit and we have recorded a workflow which clicks on submit.
Now when we generate code using coded ui the serach criteria for the button is based on its name (display name of button).
If tommorrow developer changes the button's text to submit1 , our scripts fail.
We tried using "controlName"[name given to the control and not the display name] property in search criteria instead of Name , but it does not work.
We get following error - "The playback failed to find the control with the given search properties"
Related problem happens to me also. I solved it by sending the Focus to the UI control before using that control.
Try this.
this.UIAssettePresentationsWindow2.UINOWindow.UINOButton.SetFocus();
i have a legacy massive vb6 editor with plenty of 3rd party libraries and controls and recently there is a need to set it up to make it multi thread so i can run a few other forms independently from the main editor form. Basically there's minimum communication between these other forms and the main editor except for running the other forms on a click of a button from the main page.
So from a lot of googling i found a method which converts the current app into a multi threading one by setting it up as an activex exe and adding a class set to global-multi-use to allow this to happen. Now while doing editing and testing via debugging mode, i found that when i exit a lot of weird crash will happen sometimes.
'main.frm - button click call
'On the button click, create a new object
Set obj = CreateObject("MyApp.clsThread")
Call obj.NewThread
'clsThread
' Create a new form and load it to run on a new thread
Public Sub NewThread()
Dim frm As Object
Set frm = New frmDogbert
Load frmDogbert
frm.show
Set frm = Nothing
End Sub
So what do i absolutely must know when i do this,i.e. potential problems,etc?, as i'm fearing that the app seems to be getting more unstable. Or is there a better way to do this?
Updates:
Instead of forcefully hacking my app into a pseudo multithreading app, i've taken the advice from the good people here and refactor out the component into standard exe and reverted back my app to a standard exe and call them via shell. Works beautifully :)
Thanks
Visual Basic 6 is not multi threading in of itself. The difference in the multi-tasking behavior between a ActiveX EXE and a ActiveX DLL is only apparent when referenced from another VB6 EXE. Objects instantiated from a Global Multi-Use Class defined in a ActiveX EXE run in their own context. Object instantiated from a ActiveX DLL are run in the context of the calling EXE.
Now multi-threading can be hacked into VB6 but it is very touchy and has a lot of don't (for example you can't use the stop button in the IDE to stop a debugging session or the program will crash).
What a ActiveX EXE is good is for spawning a separate but related instance that can run separately without halting the main program. Based on your brief description I would say your best best is to keep your EXE as is but more the forms/modules/classes to a separate EXE and have the original EXE reference the ActiveX EXE.
Note that you don't have to compile down to .EXE you can change the extension to .DLL and it is still a activeX EXE. You do this so that the user doesn't mistakely run the ActiveX EXE by itself.
Can you clarify the question a bit? I don't understand why it needs to be multi-threaded? Why can't you just display the forms non-modal, then they will all be visible and responsive at the same time. Unless you have some background processing operating all the time in your main form, which sounds unlikely from your question as it would lock up the main form as well as the others.
Melaos says: Well the main editor frm is the main thing here and I need to allow the user to run additional forms to do some other stuff like uploading things to our server and convert video files to other formats. And these forms use shell to call other exes. And the running time takes quite a while.
In that case I recommend making the other forms into separate EXEs rather than use multithreading, which is difficult. You say there's little communication from the main form to the subforms - it just shows them. Therefore you don't even need to make the subforms ActiveX EXEs. Just make them standard EXEs and shell them from the main form.