This feels like it should be really simple, but I for the life of me can't figure it out. I have a StatusIndicator in my application and wish to give it a non-numeric label based on its value. I believe that this should be possible, because the fiori guidelines for status indicators have example screenshots showing this behaviour on the bottom of the page (ok, granted, they're still all numeric, but not labelled with percentages).
Referring to the API Documentation shows that StatusIndicator possesses an aggregation "label" which takes a Text-control. So I tried to use that (XMLView excerpt, link to plunkr below):
<si:StatusIndicator value="70" showLabel="true">
<si:ShapeGroup>
<si:Circle cx="50" cy="50" r="20" />
</si:ShapeGroup>
<si:propertyThresholds>
<si:PropertyThreshold fillColor="Good" toValue="100"/>
<si:PropertyThreshold fillColor="Error" toValue="50"/>
</si:propertyThresholds>
<si:label>
<Text text="Hi there"/>
</si:label>
</si:StatusIndicator>
(Example in plunkr)
However, this doesn't work. From my application I know the Label is used in some way (a formatter-function for the text is called), but the displayed label remains "70%" in the above case, instead of the expected "Hi there". Using a numeric value here does not work either, so it appears not to be due to that.
Am I misunderstanding something here? Unfortunately I was not able to find anything on this, and the API documentation on the label aggregation is rather sparse to put it mildly.
Final notes:
I already tried using 'showLabel="false"' (thinking, maybe it only uses the custom label if the default is turned off), but that just removes the label entirely (as expected).
I'm sure I could make a custom control for this, but would prefer not to, if I don't have to.
tldr: Why is the label-aggregation for a StatusIndicator control (seemingly?) ignored, and how can I add a custom label to the StatusIndicator that is based on, but not equal to, the value property?
Related
The attached screen below works just fine but underneath the covers I have a slight problem ^^
Smartform with both simple and smart fields
Behind the view there's a smartform (no annotations used). Field "Agreement Action Type" and the last two pairs of fields are not smartfields (found no "smartcombo" or something similar to use) they are just pairs of labels and comboboxes and here comes the issue. While the smart fields were all perfectly aligned, comboboxes (aka simple fields I suppose) were not aligned along. In order to solve this for the moment, I used a couple of SAPUI5 formatting classes and...width declaration in pixels in the combo definition within the view. Results works fine, even in different size monitors but, even though I'm currently in the process of learning and understanding the technology, I already know that the latter is a crime against SAPUI5. Is there a way to align smart and simple fields in the same view (or an equivalent dropdown control for smartforms alternatively) or I will have eventually to get rid of my smartform (losing small bonuses like the togglable attribute) and use a simple form instead?
Thanks for taking time to read it.
Regards,
Greg
The GroupElement aggregation manages the SmartLabel for you so try to remove the label inside the GroupElement aggregation like this:
<smartForm:GroupElement label="Label">
<Input type="Text" value="someValue"/>
</smartForm:GroupElement>
On the contrary, if you want to change the appearence of your SmartField, you can use ControlType to configure the internal control.
In Articulate's Storyline product, how does one retrieve the total number of slides (or pages) in a storyfile or project?
There's not much documentation so it's kind of hard to figure out how to query common environment values like this. If we can get the total number of slides then we don't have to manually set a value for it.
One must manually set and update a variable to store the number of slides.
The most lengthy conversation on the matter seems to be found here at the Articulate forums.
In that thread the users and staff describe the need to manually define such a variable.
I asked the question on the official forum more directly here, and so far have not received a response.
Another poster at that forum mentioned using PHP to solve this problem, but unfortunately we can't add the requirement of PHP to the final product. I'm sure some server side language tricks might be used to solve this issue, but that also adds the dependency of a particular server-side language.
The Answer Mark gave is correct. So if you want to track the number of question slides in a quiz you would either hard code the value in a variable such as totalQuestions, or increment it as you go through each slide using adjust variable trigger. To call that value and display it on screen you would just add it to a text field and surround it with "%".
EG. "You have answered %Results.ScorePoints% out of %totalQuestions% questions correctly."
I find it rather pointless to hard code it since it's just as easy to put the value in the text field at the end. Using the increment method seems more logical because then you can add more question slides without having to adjust the variable or results screen each time.
I usually load frame.xml, browse for all slidelink tags and sort all slides by their Id.
Usually you get something like slideid=_player.5xoxGTW6QCh.6bmeRt3tCqP, where 5xoxGTW6QCh is the scene id and 6bmeRt3tCqP is the slide id. displaytext also gives you the slide title.
If you browse for slidetranscript and match the Id for each transcript you also get the slide notes.
Articulate 360 now has an internal (Built-in) variable for this and other counts. See Project.TotalSlides and Menu.TotalSlides
See https://community.articulate.com/series/articulate-storyline-360/articles/storyline-360-add-slide-numbers
I'm probably biting off more than I can chew with this particular problem, but I'll try to be as specific as possible in case it's within my scope. Disclaimer: I'm not terribly experienced with MS Word, beyond simple data entry/some formatting, and I have absolutely zero experience working with macros or VBasic. Unfortunately, I'm afraid the solution to my problem will come in the form of one of those last two.
THE GOAL:
What I want to do is to have placeholder text throughout my template document that will change content but not formatting when the first instance of it is changed. Basically, I'm writing a template for support manuals for a software suite. Each app has certain similar features like the menu bar, data entry screen, diagnostic log screen, transaction history, etc., so I am pre-writing those sections and using placeholders when I need to insert certain app specific properties.
I started off using the Insert->Quick Parts->Document Property->Subject tool which I used as a placeholder for the app name. I set the Property to [Subject] and then used Insert->Quick Parts->Field->Subject throughout the document, wherever I needed to include the app name. This worked fine in this case because the app name will always be capitalized. I simply change the text in the first [Subject] (which is content controlled) and update the fields throughout the document, and they all match nicely, easy-peasy, work done, go home and drink beer, right?
Not quite.
Our software handles part tracking via scanners and SQL Server, so while the interface and menu in the apps remains largely unchanged, the parts they track change from app to app. Because of this, I need to change the part name when I reference it within the text of the manuals; for example, if I'm working in ToiletPap.app and our TP is tracked by the roll, I need every mention of [Component] to be changed to roll. If I'm working in LightBulbs.app, I need [Component] to say bulb.
My first efforts went toward creating a custom doc property called Component using the Advanced tab under the Document Properties dropmenu. I then created a plaintext content control around my first [Component] titled Component and made my next [Component] a field with modified code: {COMPONENT * MERGEFORMAT}. This comes from copying what I can find when [Subject] works. This didn't work at all; updating the text in the first CC doesn't change the Content doc prop, and my fields return "!Undefined Bookmark, COMPONENT".
I got close to what I need by using the [Comments] doc property, set initially to [Component]. I used it just like [Subject], but (this is when I realized that capitalization was going to be an issue) when I mention my [component] in-text, as often as not, I need to to be lowercase instead of upper.
I've looked on MS's forums and a few others as well as here on SO, and I can't find anyone who's trying to do the same thing, much less an answer to how. Please keep in mind when answering, it would be a great help to me if you would include step-by-step instructions on how to enter/implement the code you provide because, as I mentioned, I have no idea how to go about editing macros/VBasic for MS Word.
To restate and summarize my overall question: How can I use a placeholder that displays the text "[Component]" so that, when I change the first instance of [Component] to something else, say "hopper", every subsequent instance of [Component] is updated to hopper but maintains its current capitalization and formatting scheme?
Apologies for the length of the request, but I wanted to make sure I explained the situation as accurately as possible. Thanks in advance for your consideration and responses.
I managed to solve this one after a couple extra hours of tinkering. I didn't need macros or VBasic, either.
On the first instance of [component] I created a plain-text content control to act as a container (not a necessity, but it makes it look nicer. Will likely cause a problem eventually, but for now, it's working as intended) and bookmarked it. Then, for all other instances of [container] I selected each and used Insert->Quick Parts->Field->Ref with the following field code:
REF Text1 \*Lower
Where "Text1" is my bookmark and "*Lower" indicates all lower case. The *Lower can be replaced with *Upper or *FirstCap to indicate all upper case or capitalize the first letter respectively. Now, each field reflects the text of the first with the capitalization appropriate to each field's location within the document. Just like using the doc prop with [Subject], ^a -> f9 is needed to update all fields within the document.
What's the correct XPath syntax to check if an option element is currently selected, or just to get the selected option element from a select element, on an open page with which the user, and JavaScript, may have interacted? Is this even possible with XPath, or does it lack the ability to look at DOM properties?
I can't find any documentation on this, and have (speculatively) tried:
//option[#selected=true]
//option[#selected="selected"]
//option[#selected]
but none of these work; they simply don't match any elements.
(In case it matters, I've tried this both using the $x function in the Chrome developer console, and using the find_elements_by_xpath method in Selenium for Python.)
Short answer: it's not possible.
Longer answer: XPath can look at HTML attributes, but it can't look at DOM properties. Selecting an <option> element in a <select> changes the selected property of the <option> to true, and also changes the value property of its parent <select> element, but it doesn't affect the attributes of either, so it is invisible to XPath.
To find <option> elements that have the selected attribute set, which is often how a page author might determine which option is initially selected, you can use //option[#selected]. But this does not find the currently selected <option>; changes that the user makes to the selection are invisible to XPath. There's no guarantee it will even find the initially selected option, since it's possible that the page author didn't put the selected attribute on any elements and either let the browser select the first option by default or had some JavaScript select the initial option via the selected property.
The multiple other answers here claiming that a selector like //option[#selected] can detect selection changes made by the user after the page loads are simply completely wrong.
Of course, if you're able to use CSS selectors instead of XPath selectors, then option:checked will do the job.
The problem could be the " (double quotes).
//select/option[#selected='selected'] - Will match the selected option, i am using this successfully.
//select/option[#selected='selected' and #value='specific value'] - Will only match the selected option if it has a 'specific value', i'm also using this.
If you are still having trouble, it could be an entirely different problem, perhaps there is no option node. I hope this helps.
I think we can use a knowledge from #Mark's answer and account that. Let's just find a node which HAS desired attribute:
tree.xpath('//select/option[#selected]/text()')[0].strip()
I tried "//option[#selected=''] and it has worked for me.
it is able to highlight the selected option within Page objects model.
I would try //option[#selected='true']
i.e. driver.findElements(By.xpath("//option[#selected='true']")).getText();
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