In the error console concerning a math lab program, there is a continuous error reporting about a bad selector. What is a bad selector?
A selector, generally, is a label / path to a code element. For example, in CSS, to style any paragraphs within a container div with id="container", the selector is
#container p, where # just means 'id'. I imagine in other languages it means something similar - the program is looking for an element but can't find the one it's been told to, so it throws the error.
Related
What the problem with this << give the button name like this not accepted in xaml
< , > , & , "" and space Thank You
Try this:
<Button Content="<<"/>
To explain this behavior we need to know the following:
Button is one of content controls, which are simply controls that are
constrained to contain a single item. Content controls all derive from
System.Windows.Controls.ContentControl, which has a Content property
of type Object that contains the single item. Because a content
control’s single item can be any arbitrary object, the control can
contain a potentially large tree of objects. There just can be only
one direct child.
If you open an Error list window, you can see many errors there, not just that one in your picture.
For me, it's
White space is missing.
The value "<" is not valid in an attribute.
Expecting an XML tag name.
The token "" HorizontalAlignment="Left" (omitted for brevity) is unexpected.
2x The open angle bracket character '<' is not valid in an attribute. It should be written as &lt;.
Now, you could guess why it's not a valid character, not to mention that a solution is also described there in the last error. The compiler is confused, it thinks that you are nesting in a new UI element.
As for the other question about not allowed characters in a name, it's obvious. They are not allowed to be used in names in C# or VB.NET either. If you try it in XAML, it will produce an error saying what's allowed. It's just a decision made by a team who designed this. There are languages where these characters can be used as identifiers for objects.
There's a more elaborative explanation in the following blog post.
Try « for << and » for >> this are called "ISO Latin-1 code" for more checkout this link:
http://www.utexas.edu/learn/html/spchar.html
I have just written an answer which is
I guess you should use < instead.
but actually I mean
I guess you should use < instead.
The characters < in my answer were escaped to <.
<Button><</Button>
Using selenium for the first time here, I was wondering why:
final WebElement justAnId = findElement(By.cssSelector("#someId"));
final WebElement whatIWant = justAnId.findElement(
By.cssSelector(".aClass.andAnother input[type=text]")
);
works, but not:
final WebElement whatIWant = findElement(By.cssSelector(
"div#someId.aClass.andAnother input[type=text]"
));
Although they seem equivalent to me I get:
org.openqa.selenium.NoSuchElementException: Unable to locate element:
{"method":"css selector","selector":"div#someId.aClass.andAnother input[type=text]"}
Is this intended behaviour or a bug in Selenium? I had a quick look in the bug tracker in Selenium but I didn't see anything about that. I wanted to ask here before raising an issue that doesn't need to be. Also as far as I understand it doesn't work in IE6 but who cares. I was using firefox for this run.
Actually the two are quite different selectors.
Here is your cssSelector:
div#someId.aClass.andAnother input[type=text]
But what you really wanted to write was:
div#someId .aClass.andAnother input[type=text]
notice the space between ID and class. you need that.
findElement() finds an element in the current context, which means your first snippet of code is really finding an element that matches .aClass.andAnother input[type=text], which is contained within #someId. The element with that ID may or may not contain the two classes; WebDriver doesn't assume you're referring to the same element; it just finds the input as long as its ancestors are #someId and .aClass.andAnother.
This is completely different from div#someId.aClass.andAnother input[type=text], which finds any input[type=text] within div#someId.aClass.andAnother only (i.e. it's a div that contains both the ID and the classes).
Viewing/Searching java arrays and collections in the Eclipse Java debugger is tedious and time-consuming.
I tried this promising plugin (in alpha as of Aug 2012)
http://www.cvast.tuwien.ac.at/projects/visualdebugging/ArrayExplorer
But it freezes Eclipse for simple arrays beyond a few hundred elements.
I do use Detail formatters, but that still needs clicking on each element to see the values.
Are there any better ways to view this array/collection data?
Use the 'Expressions' tab.
There you can type in any number of expressions and have them evaluated in the current scope.
ie: collection.size(), collection.getValueAt(i), ect...
Eclipse > Preferences > Java > Debug >Detail Formatter
This may be close to what you are looking for. It is another tedious work to setup but once done you can see the value of objects in Expressions window.
Here is link to start
override toString method of your class and you will be able to see what you want to see. i'm attaching example to show you exactly that.
Even though i could not find a way to see them in nice table/array, i found a halfway workaround.
The solution is to define a static method in a throwaway class that takes the array as input and returns a string of concatenated values that one wants to quickly glance at. it could include the array index and newlines to view results formatted nicely. It can be fine tuned to print out only certain array indices to reduce clutter.
This static method can then be used in the watch area.
I've got some code that does a simulated recursion tree walk to scrape stuff from an HTML tree using SeleniumRC. I've run the code using both Xpath and CSS locators.
The tree is represented as a series of nested tables. If it matters at all, some of the tree content starts out not visible as branches are "collapsed". For both Xpath and CSS, the tree is in the same state in terms of visible vs. not visible.
To get node values, my code starts with a "root" expression, adds "branch" tokens that can be incremented for each successive sibling node, and then uses a "node" token to get the text content.
It all works, but much slower using the CSS expressions I've come up with.
I suppose it is a kludgy way to make locator expressions, although it works for my purposes. I'm just trying to figure out how to best use CSS to get closer to the times involved using Xpath.
The loop tests many invalid expressions (keeps looking for nth sibling until not found) and the expressions get really long, due to the way I am incrementally drilling further and further into nested tables.
Below follows the bits of expression and examples that come from the recursion. If anyone can provide some insight as to what I am doing that is making CSS take so much longer than Xpath, that would be very helpful.
I am a total newb at doing this kind of manipulation of HTML content, if you see something dumb in terms of how I've moved from Xpath to CSS, please say so.
XPath “tokens”:
final String rootbase = "//*[contains(#id,\"treeBox\")]/div";
// in next string, "{branchIncrement}" will be replaced with integer values from 2 to get to text content, and skip graphical elements
final String leveltoken = "/table/tbody/tr[{branchIncrement}]/td[2]";
final String nodetoken = "/table/tbody/tr/td[4]/span";
CSS “tokens”:
final String rootbase = "css=[id*=treeBox]>div";
// in next string, "{branchIncrement}" will be replaced with integer values from 2 to get to text content, and skip graphical elements
final String leveltoken = ">table>tbody>tr:nth-child({branchIncrement})>td:nth-child(2)";
final String nodetoken = ">table>tbody>tr>td:nth-child(4)>span";
The first XPath expression for the content at the "root" is:
//*[contains(#id,"treeBox")]/div/table/tbody/tr[2]/td[2]/table/tbody/tr/td[4]/span
The last XPath expression for a 40 node tree with four levels, three sibling each level below the root (1+3+3x3+3x3x3) is:
//*[contains(#id,"treeBox")]/div/table/tbody/tr[2]/td[2]/table/tbody/tr[2]/td[2]/table/tbody/tr[3]/td[2]/table/tbody/tr[2]/td[2]/table/tbody/tr[2]/td[2]/table/tbody/tr/td[4]/span
The first CSS expression is:
[id*=treeBox]>div>table>tbody>tr:nth-child(2)>td:nth-child(2)>table>tbody>tr>td:nth-child(4)>span
The last CSS expression is:
[id*=treeBox]>div>table>tbody>tr:nth-child(2)>td:nth-child(2)>table>tbody>tr:nth-child(2)>td:nth-child(2)>table>tbody>tr:nth-child(3)>td:nth-child(2)>table>tbody>tr:nth-child(2)>td:nth-child(2)>table>tbody>tr:nth-child(2)>td:nth-child(2)>table>tbody>tr>td:nth-child(4)>span
In Firefox, Selenium RC's XPath locators are processed by the browser's native XPath engine, which the CSS locators are processed by a JavaScript library (Dean Edwards' cssQuery.js). Later Selenium releases (e.g., the 2.0b* series) use jQuery's sizzle library for CSS, but they still do it in JavaScript. On top of that implied difference in speed, you're doing pattern-matching in the root expression (i.e., [id*=treeBox), which requires enumerating the entire DOM tree to locate the matches, even before you descend down from there. Think about how you'd write that in pure JavaScript and you'll start to see the problem.
If it makes you feel any better, IE still doesn't have a native XPath implementation, so Selenium uses one of several JavaScript implementations in that browser, and it's anywhere from one-half to one-tenth the speed of XPath in Firefox 3.6 because of that.
Long answer short, there's not much you can do to make CSS locators faster in this particular case.
Usually, it's not something you can help. The XPath selector mechanism in Selenium makes use of the browser's XPath tools. Even IE6 has one of those. I'm not aware of a browser that provides CSS selector tools through JavaScript, so Selenium has to use its own code. As their code is all JavaScript and internal browser XPath parsing is usually done in native code, it's much slower (especially in IE6).
Thanks for that feedback. After reading your note, I wondered if I could get substancial improvment by using a tiny bit of code to resolve a literal Id value to replace the contains expression used repeatedly.
Here are four different locators I've used for the same thing. A pair of the locators are XPath, and two are CSS. For each of those pairs, one uses a contains expression, and one resolves to a literal first. In each case, the example locator are for the last node of a three level 1307 node tree.
XPath with contains:
//*[contains(#id,"treeBox")]/div/table/tbody/tr[2]/td[2]/table/tbody/tr[2]/td[2]/table/tbody/tr[2]/td[2]/table/tbody/tr[26]/td[2]/table/tbody/tr/td[4]/span
XPath where literal replaces contains expression:
id('ns_7_5R4GAB1A0GKQ50IQJQR7VV10M6__treeBox')/div/table/tbody/tr[2]/td[2]/table/tbody/tr[2]/td[2]/table/tbody/tr[2]/td[2]/table/tbody/tr[24]/td[2]/table/tbody/tr/td[4]/span
CSS with contains:
css=[id*=treeBox]>div>table>tbody>tr:nth-child(2)>td:nth-child(2)>table>tbody>tr:nth-child(2)>td:nth-child(2)>table>tbody>tr:nth-child(2)>td:nth-child(2)>table>tbody>tr:nth-child(24)>td:nth-child(2)>table>tbody>tr>td:nth-child(4)>span
CSS where literal replaces contains expression:
css=[id=ns_7_5R4GAB1A0GKQ50IQJQR7VV10M6__treeBox]>div>table>tbody>tr:nth-child(2)>td:nth-child(2)>table>tbody>tr:nth-child(2)>td:nth-child(2)>table>tbody>tr:nth-child(2)>td:nth-child(2)>table>tbody>tr:nth-child(24)>td:nth-child(2)>table>tbody>tr>td:nth-child(4)>span
Working with two different sized trees, one 102 nodes, the other 1307 nodes, I found the following.
102 nodes:
| contains | literal |
XPath | 15 sec. | 13 sec. |
CSS | 19 sec. | 19 sec. |
1307 nodes:
| contains | literal |
XPath | 255 sec. | 145 sec.|
CSS | 1893 sec. | 1811 sec.|
Clearly, a native implementation (XPath on Firefox with Se-RC) is much faster than a JScript implementation. The trade off is that it might not work as well across browsers.
I have the following problem:
I need to use XSLFO to generate a 2-column multipage document. Problem is: I need to have a vertical line between the 2 columns. Since XSLFO does not seem to specify a option for creating such a divider, I need to manually put it there.
I was thinking of using a static rotated blockcontainer with a leader in it.
However, it looks like it's not possible to use static-content on the same region as where the flow content comes.
<fo:layout-master-set>
<fo:simple-page-master
page-width="170mm"
page-height="222mm"
master-name="page"
>
<fo:region-body region-name="xsl-region-body"
margin-top="2mm"
margin-bottom="2mm"
margin-left="10mm"
margin-right="10mm"
column-count="2"
column-gap="5mm"
/>
</fo:simple-page-master>
</fo:layout-master-set>
<fo:page-sequence master-reference="page">
<fo:static-content flow-name="xsl-region-body" ><!-- This gives a error -->
<fo:block>test</fo:block>
</fo:static-content>
<fo:flow flow-name="xsl-region-body">
<xsl:apply-templates/>
</fo:flow>
</fo:page-sequence>
Results in (XEP):
[error] Duplicate identifier: flow-name="xsl-region-body".
Property 'flow-name' should be unique within 'fo:page-sequence'.
Are there any methods to place static content on the main region when also flow content is placed there?
Or: Is there a way to define the divider that divides a 2-column layout?
I finally went with the following solution:
Use a <FO:Region-Before "extend=100%">.
It looks like you can easily overlap content this way. So, it's a bit of a hack, but with some absolute positioning of a block-container, or just a relative positioned block, it does the job.