I'm writing some tests and one of the assertions has to ensure an HTML document only uses px units of measurement where specified. I'm using jQuery but I can't work out the way to select those elements. These elements will be the ones with things like margin and padding specifically set and not just the inherited values or pixel values converted from em etc.
Cheers
I'm not sure exactly what you're dealing with, but if these elements have the pixel values set in the "style" attribute, you could use something like
$([style*='px']);
For all of the elements with a style attribute which contains the letters "px". Otherwise, if they are explicitly set in the "width", "padding", and "margin" attributes, it would be something like
$([padding*='px']);
You can read more about the "contains" selector in the jQuery API here:
http://api.jquery.com/attribute-contains-selector/
If this doesn't answer your question, you'll have to be a little more clear about the structure of your document, and perhaps provide some example code.
Related
In iText's DITO template designer product, I have one field which has a fairly complex calculation. In another field, I want to use the result of that calculation.
The tooltip says "Identifier used for referencing fields in calculation expressions". So I assumed if I named it blah I can use it in a calculation in another field like this: sum({{blah}},42) (e.g. add 42 to the value of blah). But if I do that I get the error
Unable to resolve reference: "{{blah}}" in node with tag: <span> and text:
The iText DITO documentation does not elaborate on this feature at all. I'm evaluating iText DITO and there does not seem to be any way to get support while evaluating the product.
Suppose I have a field with a very complex calculation. In order to reuse the calculation result, I can do the following:
Give a name to this field (in the image below I've chosen name "total")
Insert a calculation to another field (where I want to reuse "total")
Add "total" as the calculation's body:
That's it, now the total value is reused:
I think the documentation you are looking for is at https://kb.itextpdf.com/home/ditokb/latest/manuals/itext-dito-editor/calculations
You have to give the rich text element a name in the properties to be able to reference it on other rich text element and/or calculations.
See image example at https://kb.itextpdf.com/home/ditokb/files/latest/68620314/68620309/1/1660291029000/image2020-5-27_17-56-41.png
I have two Shape Data rows for a Shape's ShapeSheet:
Shape Data Label Prompt Type Format Value Invisible
Prop.Type "Type" "" 4 "Alpha;Beta;Gamma;Delta;Epsilon;Zeta;Eta;Theta;Iota;Kappa" INDEX(4,Prop.Type.Format) False
Prop.Abbrev "Abbrev" No Formula 4 "A;B;G;D;E;Z;E;T;I;K" INDEX(4,Prop.Abbrev.Format) True
The way I intent to use this is to have the user select the Type, say Epsilon, and then have the Abbrev automatically switch to the corresponding value in the Prop.Abbrev.Format.
Note: the values used here are placeholders for the actual values for my application, which are not shown here so they don't distract from the real answer I need, how to keep the selections in sync when the first one is chosen or changed.
Thanks for any help you can give!
I don't have Visio on this machine, so I am unable to copy and paste a working solution. The approach gets a little complicated, but extremely flexible.
Save your lists in the User section, rather than Prop - this then becomes underlying data for use in properties. If you are using a master stencil then this also helps with managing the fields.
You can now store an index in your data as well - this index points to the appropriate values in your arrays. You can use Actions and side menus to set the index which, when referenced properly, means you can have the full name and/or abbreviation in the side menu and the ShapeSheet does all the work underneath.
The functions you want to look at are:
Index (e.g. INDEX(1,User.Type) will return "Beta". (0-based)
Lookup (e.g. LOOKUP("D", User.Abbrev) will return "3". (0-based)
GetAtRef
SetAtRef
SetAtRefExpr
SetF
I had a similar business problem which relied on setting a background colour based on the value of shape data. Your final solution could end up including formulas like this: =SETF(GetRef(Prop.Type),"GUARD(INDEX(LOOKUP(Prop.X,Prop.X.Format),User.Type))").
For more in-depth discussion - check out https://superuser.com/questions/1277331/fillforegnd-in-shapesheet-using-wrong-data and the extended discussion at http://visguy.com/vgforum/index.php?topic=8205.15 - the latter link also includes an example file with working shapesheets (well, working to the extent that they exposed my problem).
I need to show in a page a list of, let's say, person's properties that should be rendered more or less as follow:
name: Name
date: 1/1/2000
other: Other
Reading the doc they say:
The LABEL element may be used to attach information to controls.
So, is it the right tag to encompass the names of the properties like name, date...
even if there's not an <input> to associate with?
Nope, as per Quentin’s answer.
However, in HTML5, <dl> can be used for generic associations where <label> isn’t appropriate.
No.
It says that it can associate information with controls.
It does not say that it can associate information with anything else.
See also the newer (but draft) specification:
Some elements, not all of them form-associated, are categorized as
labelable elements. These are elements that can be associated with a
label element.
button input (if the type attribute is not in the hidden state) keygen
meter output progress select textarea
No, it is not correct to use the label element like that.
The important thing here is the meaning of may.
The LABEL element may be used to attach information to controls.
RFC 2119 (which the HTML4 spec follows) defines may:
May: This word, or the adjective "OPTIONAL", mean that an item is truly optional
So here, may does not mean the label element can be used for other purposes; it just means that it is not required to use a label element with controls.
As far as alternatives go, it depends what you want to achieve. If you are just trying to follow the spec closely, then I suggest using p and a strong element for each pair. If you want the data to be more meaningful to computers, you could consider using one of the Microformat specifications.
I partially agree with the answers so far but want to add that if you want to use labels for some reason, then I would display the property values in read-only controls, and then your labels will be valid.
I've done this using appropriate styling to differentiate the read-only controls from the functioning controls to avoid confusing your users. This was on a sequence of pages which built up the information gathered from the user in a wizard.
I have this link to W3C - the "Editor's Draft" as opposed to the link above which is the "Working Draft", which states that you can associate it with any element - as long as it's 'labelable' - even though this is a subsection of the Form section. It states earlier that a labelable element does not have to be within a form.
http://dev.w3.org/html5/spec/single-page.html#the-label-element
Does anyone know of an easy way, using jQuery, to select all <select> elements whose val() attribute yields a certain value?
I'm trying to do some validation logic and would like to just select all those elements with a single selector, then apply a warning class to each of their parents. This I know how to do once I select all the elements, but I didn't see a selector that handles this case.
Am I going to have to select all of the <select> elements into a selector, then iterate through them and check each of their values? I was hoping there would be a simpler way.
Thanks.
Why doesn't select[value=x] work? Well firstly because <select> doesn't actually have a value attribute. There is not a single value of a select box: there may be no selected options (there shouldn't normally be, but there can be in at least IE), and, in a <select multiple>, there can be any number of selected options.
Even input[value=x] doesn't work, even though <input> does have a value attribute. Well, it does work, it just doesn't do what you think. It fetches the value of the value="..." attribute in the HTML, not the current value you have entered into the form. The value="..." attribute actually corresponds to the defaultValue property and not value.
Similarly, option[value=x][selected] doesn't work because it is checking the <option selected> attribute from the HTML source (selected attribute -> defaultSelected property) and not the current selectedness of the option (selected property not attribute) - which might have changed since the page was loaded.
Except in IE, which gets the value, selected etc form attributes wrong.
Except (again): Tesserex's example may seem to work, and the reason for that is that that it's using a non-standard jQuery-specific selector, :has. This causes the native querySelectorAll methods of modern browsers to fail, and consequently jQuery falls back to its own (native JavaScript, slow) selector engine instead. This selector engine has a bug where it confuses properties for attributes, allowing [value=x] to do what you expected, and not fail like it should! (Update: this is probably no longer the case in newer jQuery versions.)
Summary: form field state checking and selectors don't mix. Apart from these issues, you also have to worry about escaping issues - for example, what if the value you want to test against contains quotes or square brackets?
So instead, yes, you should check it manually. For example using a filter:
$('select').filter(function() {
return $(this).val()==='the target value';
}).parent().addClass('warning');
(There is a value property in HTML5 and supported by modern browsers, that when you read it gives you the value of the first selected <option>. jQuery's val() is safe to use here because it provides the same method of getting the first selected option even on browsers that don't support this.)
The existing answers don't work on select tags, but I found something that does. Ask for a select that has a selected option.
$("select:has(option[value=blah]:selected)")
You can use :
$("select[value=X]");
where X is the value against which you want to check the select's value.
Attribute selectors Is what you're looking for I believe.
Something like $+('element[attribute="value"]')
See also:
*= anywhere
^= starts with
$= ends with
~= contains word
etc.
You can create a change event that puts the value in a custom attribute on the select element whenever the value changes. You can then use a simple selector to find all of the select elements that have that value. For example:
$("select").on("change", function (e) {
var $select = $(e.currentTarget);
$select.attr("select-value", $select.val());
});
And then you can do this:
var $matches = $("select[select-value='" + searchVal + "']");
$matches will have all of your matching selects.
This is a lot easier than having to iterate through elements. Remember to set select-value to the initial value when rendering the page so you don't need to trigger a change event for each select so the select-value is set.
My SSRS report contains 7 input parameters and while running my report the size of the parameter(i.e. length) is increasing.
One of my input parameter(drop down list) may contain 100 characters so the size is not constant but i want to place all parameters in 2 lines or 3 lines(in a row).
Now it is coming 2 parameters per a row
Please advice
As gbn indicates, it's not easy to change the built in report server method of presenting the parameters. SSRS likes to always use two parameters per line, presented in the order that they exist in the report (which must match the dependency order.)
So the alternatives that gbn mentions: Both involve building a "Wrapper" application: some custom code or a web page that you can code however you like to get the parameters. Then you call Reporting Services, either in code or by passing a formatted URL with your parameters. The report can be displayed in a frame, new window, or passed as a stream to where ever you'd like.
The URL access is pretty straightforward and reliable: I often use it either by hand (to create "favorites") or in code.
http://msdn.microsoft.com/en-us/library/ms153586.aspx
For what you are looking for, these might be more work than you expected, but they will be extremely flexible for your interface.
Jamie
You can certainly do that, just right click on the RDL file in the solution explorer and select view code. then move the XML tags named <ReportParameter Name="Nameofparameter"> under <ReportParameters> according to where ever you want to position. And then save it. thats it!!!
The report parameters are kind of floating in values of 2, so if u have 4 report parameters then it will be shown as 1,2 next line 3,4. Best of luck!!
Use ASP.NET for the paramaters and a ReportViewer control or URL access to render. Seriously.
I don't know of any option to present parameters any way other then the default
I believe you could try using jQuery. The report parameters are rendered in a table under a div tag with class sqlrv-ParameterContainer. Write a jQuery or JavaScript function that will extract the full innerHTML from this div ie. the table content and then extract the table row information like the <label> or <input> tags.
Create your desired table structure with <table><tr><td>{extracted sections}</td><td></td></tr></table> or leave it to your requirement...
Then just append this new HTML structure in place of the original default structure.
In jQuery it will be like
$(".sqlrv-ParameterContainer").html();
which will give you the entire table structure that comes inside the parameter. Use XML parsing and get the input controls and all. Extract these controls as-is, don't change anything.
$(".sqlrv-ParameterContainer table").remove(); // it will remove the SSRS rendered default table from DOM
$(".sqlrv-ParameterContainer table").appendChild('<table><tr>......</tr></table>'); // Append your custom html structure here....
This was something that came to my mind quickly... I would suggest you test it... :)
This doesn't help the OP with SSRS-2008 but in case it helps others - Microsoft have improved this in SSRS 2016 - parameters can now be easily managed via the GUI in Report Builder / Visual studio:
https://www.intertech.com/ssrs-parameters-2016-update/