This is a noobish question but I am getting started with MS Coded UI Tests. And I was wondering if there's a way to find page elements using XPath, instead of the default matching mechanism? What I want to do, is match a parent elements and programmatically navigate down the DOM tree to get the elements I want to work with. This can be easily done with Selenium, but I am not sure how to do it with Coded UI Tests.
Thanks
You should be able to manage navigating an xpath using the UITestControlCollection. Use CodedUI's recorder to get to the top level control, then use GetChildren to navigate your way. Keep in mind that the xpath changes because all the object types are similar, CodedUI's API doesn't distinguish.
Example:
HtmlDocument doc = this.UIYourWindowName.UIYourDocumentName; // mapped control
doc.Find();
UITestControl toline = new UITestControl(doc);
toline.SearchProperties["Id"] = "to_d"; // use the id of the top most control
UITestControlCollection toline1 = toline.GetChildren(); // get the child objects
toline1 = toline1[0].GetChildren(); // xpath: \\ctrl[#id='to_d']\item[0]
toline1 = toline1[0].GetChildren(); // ctrl[]\item[0]\item[0]
// and so on...
Related
I have multiple buttons and form inputs in one page. All these buttons and form inputs need to be disabled or enabled depending on a condition.
I know that it is possible to use the disabled keyword inside a tag to disable a specific input or button. Also, I can just add the code
:disabled="true"
to disable the inputs depending of the boolean value of a variable.
However, this solution is not acceptable for me, since I will have to add this line of code to every inputs on my page (I may create new pages in the future, containing as many inputs).
I would like to know if there's a way that allows me to simply disable the parent container of all the inputs so that the children item (the inputs) are disabled.
If you inspect the Vue instance itself of the VM when running your code you can have something like this when you console.log(this),
It will give you output similar to this if you use the correct scope:
{
$attrs
$options
.......
$el
}
Inside $el there's object properties for accessing firsElementChild, previousElementChild, previousElementSibling, etc. There's a lot of HTML related properties, however, accessing HTML element this way can get messy pretty fast. I think that your best solution is the one you already mentioned or changing the CSS class dynamically.
If you use v-if to conditional render on a parent you can achieve pretty similar functionality too.
See: Conditional rendering
IE 11 has been out just one day as of this posting.
I cannot get an element to go full screen (div or document)
http://msdn.microsoft.com/en-us/library/ie/dn265028
msRequestFullscreen will error 'object does not support this...)
However, the above msdn example will work on passing a target - makeFullScreen(evt.target).
Can I get an div to go fullscreen as in following jquery code?:
var xxx = $('#container');
xxx.msRequestFullscreen();
Or better still: click a button then have a div or the entire document to go fullscreen?
As it stands now, when a click a button, it's the button that goes full screen.
I think this is actually a small misconception of JQuery. JQuery-ing an ID doesn't actually return the element found - it returns a "JQuery object" which allows many actions on that element (or, on a series of elements if you used a class selector)
I don't have IE11 available so I can't test for you, but try this. The [0] should retrieve the element itself.
var xxx = $('#container')[0]; xxx.msRequestFullscreen();
Your code:
var xxx = $('#container');
xxx.msRequestFullscreen();
This is wrong, because you're trying to call a DOM method on a jQuery object.
jQuery calls like $('#container') return jQuery objects. You can do lots of things with these objects, but one thing you can't do is call standard DOM methods. For that, you need an actual DOM object.
jQuery objects contain an array of matching DOM objects, which you can access via [0] for the first one, and [1], etc if there was more than one matching element. So you can do your call by changing your second line as follows:
xxx[0].msRequestFullscreen();
This will call the msRequestFullscreen() on the DOM element rather than the jQuery element, and that should work for you.
In this case, you don't even need jQuery at all, since you're not using any of the jQuery functionality. You could simply use document.getElementById('container') to get the DOM object in the first place rather than the jQuery method. Then you don't need the [0] syntax on the second line because you've already got the DOM object.
Finally, you might want to be careful of course, because this is an IE-specific method; the ms at the front of the name tells you that, which means that your code won't work in other browsers, even if they support the same feature. You need to do it in a cross-browser way. There are some tips on how to do this here: How to make the window full screen with Javascript (stretching all over the screen)
I'm not necessarily looking for code help, but rather a high level answer so I can research the solution myself. Basically, I have an MDI app with multiple docs and their views, I'd like all the views to open up as tabs in the one child frame that I have. The thing is my child frame is statically configured with a splitter window with two views, a form and a list view, in the OnCreateClient method. I'd like to keep this as the default tab that appears when the app is launched.
I have a third view (editview) with it's own document template, which I'd like to be able to open as a separate tab. I will have other views that will behave this way. What's the best way to approach this?
Will I need to create separate child frames for each view? Will I lose the 'tab' feature if I create separate child frames?
Or will I have to modify the child frame's OnCreateClient method to test which document template is the current one and create the view for that doc template? I'd like to know how some of you seasoned programmers have had or would do it.
Thanks.
In case this helps others, from what I've gathered, it is perfectly acceptable to create a new child frame class derived from CChildFrame or just use that as your frame with your new view. The doc, frame, and view will be added to the doc template in the initInstance method. for example, let say you have a pair of trios (2 docs, 2 views, 2 frames):
pDocTemplate = new CMultiDocTemplate(IDR_testappTYPE,
RUNTIME_CLASS(CMydoc1),
RUNTIME_CLASS(CMyframe1),
RUNTIME_CLASS(CMyview1));
if (!pDocTemplate)
return FALSE;
AddDocTemplate(pDocTemplate);
pDocTemplate2 = new CMultiDocTemplate(IDR_testappTYPE,
RUNTIME_CLASS(CMydoc2),
RUNTIME_CLASS(CMyframe2),
RUNTIME_CLASS(CMyview2));
if (!pDocTemplate2)
return FALSE;
AddDocTemplate(pDocTemplate2);
If you add another trio with a different childframe because this new frame doesn't use splitters like the ones above, you would do it this way.
pDocTemplate3 = new CMultiDocTemplate(IDR_mditest3TYPE,
RUNTIME_CLASS(CMydoc), //same doc
RUNTIME_CLASS(CMyframeWithoutSplitters), //new frame
RUNTIME_CLASS(CMyview3)); //new view
if (!pDocTemplate3)
return FALSE;
AddDocTemplate(pDocTemplate3);
I am new to MonoTouch from a VS/C# background and am trying to rewrite an existing c# app.
I have made one simple MonoTouch app which succesfully loads data into a List<> from an XML file, and was starting to add Master/Detail code when I discovered the existence of MonoTouch.Dialog which looked like it would make my job much easier. So I started a new project using the sample code at http://docs.xamarin.com/ios/tutorials/MonoTouch.Dialog , changing the basic class to match what I needed.
But I am stuck with trying to prepopulate the DialogViewController with my existing List<>. I have tried using LoadMoreElement but cannot find an example of its use and don't know if it's the best way of doing this.
Thanks Anders.
In the interim period I discovered a different method:
_rootElement = new RootElement ("Riders")
{
new Section()
{
from x in riderList.Riders select (Element) new RootElement(x.Name)
{
new Section()
{
new StringElement("Rider",x.Name),
new StringElement("Club",x.Club),
....
....
...ill try both and see what suits best.
But I'm struggling to find any documentation to describe the methods for the dialog classes, e.g. Section.AddAll() and others used in the link you have provided.
If you want to create a list within an existing dialog view, you can for example create an empty Section and to this section add the list the elements from the list as RadioElement:s or CheckboxElement:s, depending on how many elements you want to be able to select simultaneously.
To facilitate selection, you may need to create a Group/RadioGroup and reference this group when you create the respective list elements in your section.
Here is a quick example of creating a new Section and adding the list elements, assuming that only one element can be selected simultaneously:
var list = new List<SomeClass> { ... };
var listGroup = new RadioGroup("grp", 0);
var listSection = new Section();
listSection.AddAll(list.Select(elem =>
new RadioElement(elem.ToString(), "grp") as Element));
If you want more specialized handling of the elements in the list or the events associated with list actions, you may want to subclass RadioElement or CheckboxElement. There is a good example on how to do this in the answer to this SO question.
I am using the WebBrowser control in my project to display complex HTML documents that are generated/manipulated at runtime.
I have noticed that constructing the DOM programmatically from C# by creating HtmlElement objects is about 3x slower than generating an HTML string and passing it to the WebBrowser, which in turn parses it to generate the DOM. Both ways create a noticeable delay when navigating between lengthy documents.
I am looking for the fastest way to switch between multiple documents in the same WebBrowser control, ideally without having to repeatedly generating the DOM tree for each document. Is it possible to cache a tree of HtmlElement objects somewhere in my program, and then re-insert them into the WebBrowser as needed?
I will describe the solution in terms of the native win32 COM APIs; it shouldn't be too difficult to write the interop to do it in C# (or find it at pinvoke.net). Alternatively, you may need to use the properites that the managed objects expose to get the native ones.
You're not likely to be able to build the DOM yourself faster than IE's parser, so create a blank HTMLDocument (which in native code would be CoCreateInstance(CLSID_HTMLDocument)) and QueryInterface() the HTMLDocument for its IMarkupServices implementation. Also create two IMarkupPointers using the IMarkupServices::CreateMarkupPointer() method.
Next call IMarkupServices::ParseString() to parse your HTML. This will give you a pointer to an IMarkupContainer that contains your DOM, as will as two IMarkupPointers that point to the beginning and end of you DOM. Now you can use IMarkupServices::Move() to move your data from one IMarkupContainer to another.
So the general scheme you would use is to have a single HTMLDocument which is your "display" document, and it's associated IMarkupContainer (which you can just QueryInterface() for). Then you have a vector or list or whatever of all the non-displaying markup containers. Then you just create a markup pointer for your display doc, call IMarkupPointer::MoveToContainer(displayDocumentContainer, true) and then use that to move stuff around from your display container to the not-displaying containers and vice-versa.
One thing to note: you must only access these objects on the thread you create them from, or acquire them on. All IE objects are STA objects. If you need multi-threaded access, you must marshal.
If you have specific follow up questions, let me know.
References:
IMarkupContainer
IMarkupServices
Introduction to Markup Services
This will do it
// On screen webbrowser control
webBrowserControl.Navigate("about:blank");
webBrowserControl.Document.Write("<div id=\"div1\">This will change</div>");
var elementToReplace = webBrowserControl.Document.GetElementById("div1");
var nodeToReplace = elementToReplace.DomElement as mshtml.IHTMLDOMNode;
// In memory webbrowser control to load fragement into
// It needs this base object as it is a COM control
var webBrowserFragement = new WebBrowser();
webBrowserFragement.Navigate("about:blank");
webBrowserFragement.Document.Write("<div id=\"div1\">Hello World!</div>");
var elementReplacement = webBrowserFragement.Document.GetElementById("div1");
var nodeReplacement = elementReplacement.DomElement as mshtml.IHTMLDOMNode;
// The magic happens here!
nodeToReplace.replaceNode(nodeReplacement);
I'd really need to know more about how you are generating these documents. It might be faster to get your data into a XML document and then use a XSL transform to convert the data to HTML and pass that to the WebBrowser control.
The nice thing about the XSLT implementation of .NET is that it takes the XSL source and compiles it to a temporary assembly to speed up the transforms.
If you decide to go that route look up the MVP.XML project which adds some nice exslt functionality to the stock XSLT implementation.
Maybe rather than caching the DOM you could just flip between several WebBrowser controls on the form - with only the active one being visible?
Could you do something like this?
Create the contents you want to display inside a DIV
Create secondary contents (in the background) inside non-visible DIVs
Swap the contents by playing with the visibility