Following the steps outlined in Testing Windows Store Applications with Coded UI Tests, I've built a Windows Store app project (built and run in Windows 8.1, VS2013 Ultimate Update 2), and have added a "Coded UI Test Project", selecting "Edit UI Map or add assertions". After clicking OK to this dialog, I am sent to the Windows Start screen and can open the app.
However, at this point I cannot select elements using the cross-hairs of the Test Builder -- the app minimizes whenever I click on the little Coded UI Test Builder window. If I use the Ctrl+Shift+I shortcut to attempt to map an element I get a "Object reference not set to an instance of an object." popup.
It seems like the Test Builder and the app aren't aware of each other. Suggestions?
Related
I am following the tutorial on https://learn.microsoft.com/en-us/office/dev/add-ins/quickstarts/excel-quickstart-jquery?tabs=visualstudio
When I run the add-in from VS2022 in debug mode (F5), the add-in does not load (error "This
add-in could not be started. Close this dialog to ignore the problem or click "Restart" to try again")
When I run the add-in from VS2022 without debugging (CTRL-F5), the add-in works fine...
In both cases, the page on https://localhost:xxxx/Home.html is working fine, it's only Excel that refuses to load the plugin while using VS Debug Mode.
I have another computer on which it both ways are working fine. Both computers have a similar software setup.
Where should I start looking for the cause of this?
Thanks
OK. I got this to run on my machine, it took a bit of time to figure out but steps are documented here - https://learn.microsoft.com/en-us/office/dev/add-ins/develop/debug-office-add-ins-in-visual-studio
Here is a hint - You write the plugin code in JavaScript, it gets loaded in legacy WebView (EdgeHTML) control in Excel IDE. How would you debug the code?
Here is what I tried and it worked -
Launch your project from VS IDE, this should launch excel window.
Click on 'Home'-'Show Taskpane' button. If it is not visible, the Taskpane window should appear on the right side. This is where add in is loaded.
This is the WebView control that loads your HTML UI + associated javascript code.
Right click on it, click on the 'Inspect' menu. This should launch the Developer Tools that you normally get when debugging web pages.
Put your break points in the JS code and hit the button. The debugger should break in associated JS code.
Is it possible to create custom windows features? for instance add new buttons to the start menu or maybe a button on the task bar like the Cortana button. Even add a new button to windows explorer. If it is can someone please point me in the right direction as google doesn't seem to return any helpful results
You can create custom widgets on the taskbar by creating a deskband shell extension.
Creating a button in the start menu or in other places that have no extension support requires major work and will often create a buggy/unstable result because you might have to inject yourself into the Explorer desktop process (and other processes on Windows 10).
I have one windows form UI wizard as custom action in MSI setup project in Visual Studio 2013. During installation one small progress bar dialog appears on top of the UI. This dialog also has a Cancel button and text like 'Please wait while Windows configures....'
Can we hide or disable this dialog somehow? Can we disable the Cancel button on this dialog? Or can we take this dialog behind the main UI so that user will not be able to click Cancel? Or Can we detect this Cancel button click event and handle in custom action?
There's no good answer to this, so basically this is just information.
The Windows Installer architecture expects all UI to be done in the first UI sequence, that's where data is entered. You probably understand this from the vast majority of other setups that do this. The execute sequence is intended to be silent except for errors and a progress bar. When Visual Studio setups allowed installer classes as a way for people to run managed code custom actions I don't think they expexcted people to have UI there. It often doesn't work because of the STA/MTA thread differences for message pumps, and since Windows Installer itself knows nothing about your custom action showing UI (there's not supposed to be UI!) it still believes it has the user's focus. The other issue is that many customers expect to be able to do silent installs, your requirement for a UI wizard defeats this.
I think some people have tried to solve your problem by enumerating all the Windows on the system to find the Windows Installer one and forcing it to the background, but I haven't seen anything recently on this or any code examples.
In your case, if your UI data can be collected up front with one of the canned UI dialogs then try that. Unfortunately VS setups don't give you a way to validate the input. If the UI wizard is for the app itself then it's usually easier to do it when the app first runs, as well as being easier to test and debug, being able to run later to reconfigure, and avoiding this kind of issue.
The limitations of VS setups include not being to design your custom dialogs to collect and validate input in the expected way at the beginning UI sequence. Also you cannot disable the Cancel button because VS custom actions run after everything is installed, which is too late to send the message saying "disable the cancel button". The overall issue is that you're fighting the limitations of VS setups, and another tool might be a better way to go, or have that UI wizard run at first boot of the app.
I am able to hide the progress bar dialog itself using Win32 APIs.
I am testing a chat client at a web service. I thought the best way to do this was to open the website in one internet explorer window, log in, open the chat. Then open a new IE window(in private mode so that the log in details will be forgotten) go the the page and then log in with another user and open the chat, and then start chatting with the other user in the other browser window.
The problem is when I have done everything in the first window and I open a new window, all actions are triggered in the first window even though the second window is selected. Is there any way to select which browser window to use? Or are there better ways to test this functionality without opening two internet explorer windows?
Solved: I solved this by opening a new window in private mode. When I wanted to do actions in that window I defined the browser window as:
BrowserWindow privateWindow = new BrowserWindow();
privateWindow.SearchProperties.Contains("[InPrivate]");
You need to find some characteristic of the two IE windows that is different and ensure that it is included in the search criteria used to find the two windows. However modern browsers are complex, the distinction between windows and tabs it not always clear; window titles can change depending on which tab is selected.
Specific windows are selected by setting the properties of the UITestControl objects (and of derived objects). In the UI Map editor the properties panel has fields for the "Windows Title" and the "Search Criteria". For some controls there is also a "Filter Properties" field. The same fields are available if hand coding rather than recording tests.
I am creating a coded UI test with assertions in VS2010. Here is what I want to do:
Run the application.
Test whether the text on a button is "button1".
Click the button.
Test whether the text on the button is "clicked!"
There seems to be no simple way to do this with the coded UI test. In particular, whenever I start recording and then run the application, the 'add assertions' button is greyed out.
It seems as if the only way to do this is in pieces: first launch the application, then close the coded UI test gadget, then go into the test and right click on Generate Code for Coded UI Test, then use the "Add assertions" button in the gadget to add the gadget, then edit the code because it places the assertions before it launches the application, etc.
Is there a way to do this in one fell swoop?
Automate "launching application from GUI" with Play and record functionality.