How do I set the accesskey property of a Button control in XPages to be a function key, e.g. F1?
The property panel for a Button in XPages only allows a single character. I can compute the value, but I'm not expecting a return value of F1 to work. Is it possible to set the accesskey to one of the function keys or are those keys restricted as browser shortcuts?
Access Key doesn't work for those keys (I have read it somewhere I don't remember. I'll update when I find).
You may also use Dojo for cross-browser solution.
This is an example how to register keypress events:
http://dojo-toolkit.33424.n3.nabble.com/how-to-listen-for-onkepress-event-td1870699.html
This is the list of keys for Jojo:
http://dojotoolkit.org/reference-guide/dojo/keys.html
This Stack Overflow question (with answers) might be useful for you:
Handling key-press events (F1-F12) using JavaScript and jQuery, cross-browser
Related
I am using chromeless API (https://github.com/graphcool/chromeless)
How can I select an option from a dropdown list?
Specifically I want to select last option having value="other".
My HTML is:
You could achieve this with the evaluate() method which lets you evaluate any Javascript within the browser-context of any page you load:
await chromeless
.goto('http://yourwebsite.com/yourpage')
.evaluate(() => {
select = document.querySelector('select.decline-form-select')
select.value = 'other'
})
Or, specifically select whatever the last item is in the select list:
await chromeless
.goto('http://yourwebsite.com/yourpage')
.evaluate(() => {
document.querySelector('select.decline-form-select option:last-child').selected = true
})
It can be done without the evaluate() method, too, albeit in a somewhat convoluted way. Avoiding evaluate() is useful when it is unknown exactly which events have to be triggered upon change, for the web application to work.
await chromeless
.click('#the-select-element')
.type('First characters of description text of desired option', '#the-select-element')
.click('#the-select-element option[value="the-matching-value"]')
Or using the example posted in the question:
await chromeless
.click('select.decline-form-select')
.type('Oth', 'select.decline-form-select')
.click('select.decline-form-select option[value="other"]')
Selecting an option using native Chromeless commands involves first clicking the select element, then typing text to select the desired option, based on the visible text content of the option (the first few characters that unambiguously identify the option should be enough), and then clicking the desired option element. Since it is not possible to find the option element by text content using css selectors, the element must be selected by some other means – e.g. value or ordinal number.
Sending arrow key presses instead of typing characters to select the option might work, but I found in my testing that using the press() method was buggy. (A tab with Chrome settings would open randomly while executing tests that used press() to send either the return or the space key.)
All this said, I was unable to make tests run reliably with Chromeless. There seemed to be problems related to scrolling elements into view or not. While the webdriver-based systems http://webdriver.io, http://nightwatchjs.org and https://www.npmjs.com/package/selenium-webdriver are a bit more complicated to set up and code for, it might be worth the effort in order to get better reliability.
when we type into autoComplete, primefaces automatically highlighted first shown item. so when we press enter key that item will be selected. how can i change the behavior of enter key, so when it pressed, just entered text be submitted in backing bean property.
I know we can hit ESC button then continue but but user don't like it.
I am using primefaces 5.0 & jsf 2.1.11
What helped me to solve the same issue where the answers here and here. Basically, you have to override 2 different behaviours.
First one is the default selection of the first result, that can be achieved adding this to your autocomplete (as stated by the accepted answer in the first link, available in primefaces for versions 5.1.5, 5.0.14 and 5.2):
autoHighlight="false"
The second thing you want to override is the behaviour when Enter is pressed, as you want the form that contains the autocomplete to be submitted. For doing so, just add this code to either the containing form or the autocomplete:
onkeyup="if (event.keyCode == 13) {
document.getElementById('[searchFormId]:[submitButtonId]').click();
return false; }"
Change the ids between square brackets for your own ones and it's done.
PS: I know this is a rather old question but it still applies to the current version of primefaces (6.1 when this question was answered). And I also think it can help to have both changes combined in one answer.
Truth be told, this feels like a bug. Richfaces do that implicitly (submit on enter while suggesting). I haven't found an official fix so I did some research and turns out the simplest way is to override the JS function that resolves key presses. The whole autocomplete js is here. You just need to override the bindKeyEvents function so you declare it likewise:
PrimeFaces.widget.AutoComplete.prototype.bindKeyEvents = function () {
Then add the rest of the code for this specific function from the JS I mentioned before. I've omitted that code so it's more readable. Then you want to find a switch that resolves different keys that have some behavior mapped to them. And under the code:
case keyCode.ENTER:
case keyCode.NUMPAD_ENTER:
Add something like:
if (highlightedItem.length == 0) {
document.getElementById("<your_form_id>").click();
_self.hide();
} else {
highlightedItem.click();
}
Also, make sure that you got forceSelection and the autohighlight off on the autocomplete component.
The problem in the JS is that even though you haven't selected any item from the suggestions it still triggers the event that tries to click the item... which doesn't even exist.
This is the simplest way as I said... you can also create your own autocomplete implementation and override the behavior there. But that's a lot of work and if you only need this one feature I suggest overriding the JS function.
In order to override the original JS with your custom one you need to make sure yours is loaded after the original one. To do that you can either use h:outputScript or simply just load the javascript like you're used to... but in the body (not the head).
Also there's probably a fancier way than having to specify the form id. But I just wasted too much time searching for a solution that I had to get it done real fast.
I was looking at the function CMFCRibbonCategory::RemovePanel and I saw something that I don't understand. The 2nd optional parameter is bDelete which according to the docs:
[in] bDelete
TRUE to delete the panel object from memory; FALSE to remove the panel object without deleting it.
I don't see a way of referencing the same panel elsewhere and this isn't like hiding the panel as there is no way to bring it back, so why wouldn't I want to do this?
Unless this is in case I were to keep a live pointer to it using CMFCRibbonCategory::GetPanel? Sounds kinda like a bad idea.
I agree. There is no real use for Setting bDelete to false at all.
m_arPanes is no where accessed in a way that some one can add a Panel with a plain pointer.
It seams to be a relict when they transported the BGC ribbons implementation into the MFC. The BCG version also have this bDelete flag and it isn't useful there too, but there are more complex functions that handle such panels.
But I don't see this functions and internal customizable panels in categories in the MFC.
So from the design point it would have been better to create a special protected function like InternalRemovePanel. That just remove th Panel and keps the pointer...
According to that API definition:
https://developer.chrome.com/extensions/windows.html#type-Window
window has a (new) property called 'alwaysOnTop' (As I understand, it means that even if the user clicked somewhere else on the screen, this window sticks to the front, like 'chat for google' does).
I can't get how to create a window which has this property (chrome.window.create() doesn't contain it among the parameters it gets). I've tried several ways, like using the function that create gets and other options, but none worked. The console messages didn't help me to figure out what the right way is.
Could someone please post a short example that demonstrate a creation of such a window ?
alwaysOnTop is not a valid argument for chrome.windows.create.
Indeed, it is mentioned in the documentation, but listened under the Window type, which describes an object which is passed to many of the chrome.windows API method callbacks.
Compare chrome.windows.create#createData and the Window type's properties.
Our web application has some event code to "format" any text with pasted into a field so that any HTML styles do not break our data.
What would be a good way to pre-load the browser clipboard so that I can test pasting into the input field?
Is there any way to do it programmatic-ally or would I have the test script visit "a source page" and copy text before moving onto our application?
Any ideas or code snippets would be welcome.
Working with the clipboard will depend on your platform. E.g. on OS X, you can use pbcopy and Command-V:
open('|pbcopy', 'w') { |io| io << 'some text' }
browser.text_field(:name => 'q').send_keys([:command, 'v'])
I know there are equivalents on Linux (xclip?). Not sure about Windows.
I would consider using the .value= method to set the value. If it's been implemented the same as in watir, then it causes no events to be fired and sets the value directly, and then follow that up by sending an appropriate event (depending on what if any events are being monitored) such as onKeypress. I tried to figure out from the Watir-webdriver rdoc for textfield, if this distinction between .set and .value= has been maintained, but the way the doc describes them (at least there) makes them seem interchangable.. (Jarib can you clarify???)
Potentially you might need to first fire something like onFocus depending on the controls you are using. For example, as described in this SO case Setting a text field that has a JQuery mask on it for a jquery mask, they had to end up firing an unmask event to be able to even set the field.
This is a good case for utilizing the techniques described here How to find out which JavaScript events fired? and in the SO item linked in the comments for that question, to figure out just what events are fired when you manually paste something into a field. (note I would slueth it with both using the mouse, but also using something like tab to move between fields and set the focus, events common to those two methods are the ones most likely to be implemented by the controls.
I presume you have some kind of client side javascript that needs to check what was pasted into the field, and thus the reason for this test. If you are using standard HTML fields, with no javascript stuff, then I would consider this particular test case to be effectively the same as 'testing the browser' since supporting cut and paste in input fields is a standard browser function. In that case, you are sort of 'off the reservation' and I'd not bother with such a test case.