I'm trying to record a test using TestComplete 10.
The application I test contains popups. The popup contains clickable buttons and links.
The problem is that when executing the recorded test- TestComplete does not recognize the popup itself and all the elements in the popup.
TestComplete waits for the popup element and then the test fails.
The application bases on WPF on Windows OS.
I'll be glad for some help regards this issue.
There is a way to pass this, any extension needed?
Since you are using TC10, I would always suggest updating to the newest version 12.5!
Beyond that, it could be a couple of different things, but first you should run through this requirements link to determine whether or not TC can see your application.
https://support.smartbear.com/testcomplete/docs/app-testing/desktop/wpf/requirements.html You could also take a look at this other link https://support.smartbear.com/testcomplete/docs/app-testing/desktop/wpf/index.html and see if it helps. Both links are for TC12.5, but some of these functionalities might still be available in your version.
Please let me know if you need some more assistance.
Related
I'm having a hard time finding any documentation on how to interact with the SCSM Console.
Almost all samples and documentation I stumble upon, are regarding interacting with the System Center Backend.
My goal is to have a TextBox and a Button, in the TextBox goes an Incident ID, and a click on the button would then open the incident in the SCSM Console.
I don't know if its even possible, does anyone of you have experience with this?
I've worked with the SCSM SDK for 2 years now and have not come across anything within it which would allow you to launch the console and go straight to a particular incident form. The ConsoleContextHelper requires the console to be already open and mainly interacts with the current view/form.
lovedatsnow's suggestion for using a ConsoleTask on the incident view would be the closest way to implement something similar to what you desire however this wouldn't give much advantage over using the search bar and double clicking the result to open the form.
I've walked through Travis Wright's post with success:
https://blogs.technet.microsoft.com/servicemanager/2010/02/11/tasks-part-1-tasks-overview/
Here is a simpler tutorial that may also be helpful
https://blog.jhnr.ch/2013/12/09/how-to-create-a-custom-scsm-console-task-by-using-some-c-and-xml-magic/
for several days now I am trying to create a program that reads and writes values from/to textboxes in another application. To be more specific: I want to auto-update ticket cathegories in HP Service Manager.
My first attempt was using SendKeys. But I faced the problem that this method seems to be not really reliable as I need to reach text fields far from another and using loops that sended TAB was unreliable [of course I added an Application.DoEvents() and a Thread.Sleep].
After some time of testing I am now unable to control HPSM at all [SendKeys get executed on every program EXCEPT HPSM]. Dunno what is wrong but I read in the internet that there are several problems [only works with Visual Studio running, only while debugging etc.] so I dropped this solution.
I would welcome it if I can access the desired text fields directly. Now, using Spy++ I can select the desired text fields. But unfortunately, there is no fixed value to identify a certain text field: No way to do this programmatically.
The only thing that always seems to stay the same is the structure/hierarchy of the "Windows" provided by HPSM [see attached screenshot].
Now my idea: Is there a way to iterate through those sub-windows and read/modify the "Window Caption" portion of the certain window?
Or is there another, maybe simpler way to get this sucker automated?
Thanks in advance for every help since I slowly drown in desperation :)
HPSM structure:
i want to write an application, which reads under windows xp the quick launch items in the order like they are located in the taskbar,
and sets hotkeys for each of these item.
windows + 1 should start the first application
windows + 2 the second, etc.
(like in windows 7)
all of these items are found i a folder, but if i read the items of this folder, i dont get the right order of these items.
i found two solutions the get the right order - first:
in the registry an entry is found, where its saved how they are located, but not in plain text. i dont know how to read this, and cant reverse engine it.
the second:
read via winapi the items tooltip from the taskbar, so i can (if there are not items with the same name) search via the name in the quick launch folder.
the quick launch bar is just a listview (syslistview32).
via sendmessage i got it work to count the items, and start one (faking a click on this item), but how the hell can i read the tooltip?
i have googled a lot, tried everything, but i didnt get it run.
i hope you have any snippets for me, to solve this problem.
cheers
Determining the order of the items in the Quick Launch toolbar programmatically is going to be inherently fragile. There's not an API exposed for this, which means that it's subject to change in future versions of Windows, breaking your code that relied on assumptions about undocumented implementation details.
However, this is less of a problem in this specific case than it normally would be, since the Quick Launch toolbar doesn't exist anymore (or, at least, no one uses it anymore). The last version of Windows that used the Quick Launch toolbar was Vista, so if you make sure that your code is compatible with Vista and earlier, you should be fine. It won't work with newer versions anyway.
The positions of items in the Quick Launch toolbar is stored in the Registry in the following key:
HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Streams\Desktop
You can extract the information from there, parse and interpret it, and then use it as you like. As you mention, this information isn't stored in plain text form because that would be very slow for the shell to load and parse itself. Since this is undocumented and not designed to be used by clients, they had no particular benefit in making it user (or developer) friendly. All that matters is what's most efficient for the shell, and storing the binary information from its internal structures is the obvious choice.
You will need to reverse engineer this in order for it to be useful to you. The way I'd go about it is probably by setting up a test environment with a couple of items in the Quick Launch bar in a particular order, exporting the information from the Registry, moving one of the items around, exporting the updated information from the Registry, and comparing the two exported Registry files to see what changed. Rinse and repeat as many times as necessary to deduce the pattern. (Really makes you wonder why so many developers actually do take the time to reverse-engineer undocumented aspects of Windows, doesn't it?)
The other option would be to use Spy++ to investigate the windows that implement the taskbar and its Quick Launch toolbar. I don't have a pre-Windows 7 system around, but it sounds like from the question that you've already done this and determined that the Quick Launch toolbar is implemented using a standard ListView. If you know the name of that window (and the names of its ancestor windows), you can walk through those windows to obtain a handle to the window you're interested in. And then you can determine the order of the items in the window as if it were a standard ListView in your own application.
The documentation for ListView controls is here; that should get you started in the right direction. You can get the text of one of the subitems by sending the LVM_GETITEMTEXT message.
This is probably the easier way of doing it. The same caveats apply--there is nothing keeping future versions of Windows from changing the names of those windows or the way that the taskbar is implemented, but since the only versions of Windows that have a Quick Launch toolbar have already been released (and therefore aren't likely to change), this may not be a big problem.
Then again, with the fact of the Quick Launch toolbar's obsolescence in mind, I struggle to comprehend why this endeavor is even worthy of investing developer time.
Also, even once you get this program all written and installed, consider what happens when the user adds a new item to the Quick Launch toolbar or re-arranges the existing items. How is your utility going to know that and adjust the keyboard shortcuts accordingly? What if an installer adds/removes an item from the Quick Launch toolbar?
I would like to record the actions of a user when they are using the base Operating System with my application open.
For example, Clicked Start, Clicked All Programs, Clicked Microsoft Office, Clicked Microsoft Word....
Can anyone suggest a sensible method to achieve this?
The idea is that the user's actions are only recorded when my application is open, its meant to be an alternative to the Microsoft recorder. It creates a written procedure that can be sent to a customer service department.
I guess you should ask yourself if your users will appreciate this! Maybe they care about their privacy.
Anyway you can do it using hooks (I think you're writing for Windows). Same task as a macro recorder.
If you are trying to do that, why not just use an existing program. We used AutoHotkey at my last job to do this for creating UI testing code.
You could ask the user to install AutoHotkey and have them record the script. It can then be sent to you. You can run the script yourself (although you may have to tweak the screen resolution and things like that), and see what was happening.
EDIT:
Another idea is have the user record a screen cast and send that to you. It might make it easier to debug.
I didn't know what Microsoft Recorder was, thought it was the sound recorder, didn't realize there is a Microsoft Problem Recorder bundled in Win7, which does the whole screen cast recording.
I want to create a program or use a program that will read the memory values out of another application. Does anyone know of an application/library that will do this?
The target app is this. I would like to read the exchange rate values from it.
I'm an experienced c# programmer, but have never worked with the Win32/user32 api which is what I'm assuming I'll have to deal with to pull this off.
Any help that gets me going in the right direction is greatly appreciated.
Update:
I managed to use Spy++ to get the window handle, so I'm sure I can get the values some how.
Have you looked into AutoIT or AutoHotKey?
Both of these open source options have well documented abilities to read text from application windows (and send keystrokes or mouseclicks to them).
AutoIT is very easy to use and well documented.
An example of reading text from a window would be:
$text = WinGetText("title of window", "")
MsgBox(0, "Text read was:", $text)
This can be compiled into an executable.
Typically an application creates controls in a dialog in a consistent manor, same ID, same order etc, so finding a control programatically is fairly simple. Using Spy++ find the control's ID and then you can search the windows created by the application for the desired control. Not being familiar with the app in question I cannot give specifics, but if Spy++ shows the value you desire, it is likely not difficult to obtain the value in your code.
What type of control is the value displayed in? You'll may be able to use GetDlgItemText to obtain the value once you have the parent window handle and control ID? To get the parent window try using EnumWindows.
It might be easier to scrape their data by automating a screenshot and then ocr process. If that's your goal.
Potentially relevant links:
get-a-screenshot-of-a-specific-application
ocr-with-the-tesseract-interface
May be this article helps - http://msdn.microsoft.com/en-us/magazine/cc163617.aspx, but I think it's not universal and for your task is better to get access directly to Forex API/Web-Service or try to catch needed data on network.
It is possible to screen-scrap things created with native windows controls; if that is the case, you should be able to see the controls using Spy++. But some times controls are implemented "by hand", and there is no way to screen-scrap them (e.g. some Java graphic toolkits play directly with the graphics, so everything day do is meaningless from the outside, or even some Office menus are implemented without using the menu control).
The Windows accessibility API is a possible way to screen-scrap the values; check if "Narrator", the screen reader that comes with windows, is able to read aloud your target application.