Aloha adds mousedown, blur, ... handlers to the document body, to recognice when the the Toolbar is shown/ hidden and the document selection should be changed.
Now I have a plugin (a ColorPicker), which appends itself to document body. So when I click the the element aloha recognizes that no editable element is selected and hides the toolbar.
I found two ways to prevent this and both look like really dirty hacks.
Catching the mousedown handlers and not promote them to document body.
This is bad, since the plugin requires this click handlers too.
Add the class 'aloha-dialog' to editor
Aloha seems to treat elements which have this class differently. However this seems to break some intern functionality, if it is not hidden correctly.
So did I miss some functionality, or is this not handled by a standard functionality yet?
BR,
Stefan
Aloha uses Surface.trackRange on the toolbar, so that clicks in the toolbar (which is outside the editable) don't hide it.
For example:
Aloha.require(['aloha/jquery', 'ui/surface'], function ($, Surface) {
Surface.trackRange($('#color-picker'));
});
Related
Using AngularJs 1.x, I have a datepicker which should pick today when you press t. And I have ng-typeahead which should scroll down the options when keydown is pressed.
They both work fine when placed outside the ui-grid but when they are inside a cell of the grid. The datepicker's t stops working and if when using typeahead and pressing down it moves to the next row instead of scrolling through the options.
It seems that the grid is catching keyboard key events and messing up some directives. Is there a way to disable ui-grid event handlers when typing inside some cells?
My fellow colleague told me to write directives to handle those stuff but isn't there a simpler cell option? There should be a simpler way than writing 50 lines of code for that.
If you use Bootstrap Datepicker you can use its option datepicker-append-to-body. Newly created datepicker is appended directly to body element and should not mess with ui-grid's handlers.
I have some buttons in a bottom toolbar of a gridpanel that control adding, and removing records from the row-editing grid.
The handlers are pretty simple: "new" button creates an instance of the model, appends to the grid and then opens a row-editor on the new row; "edit" button just opens the selected row's row-editor; "remove" destroys the record from the store and refreshes the grid view.
For some reason these buttons don't lose the focus class that gives them a border when they have the focus. Here is a picture:
In the picture both the "New" button and the "Remove" button have the focus class, when I press the "Edit" button it also keeps the focus classes even after doing a complete row-edit operation and closing the row-editor.
I did find that when I mousedown on one of these permanently "focused" buttons and then mouseup away from it and then click something else the focus class goes away.
I know that I could put a blur handler for all button components in my respective controllers but I would have thought that this functionality was built in so I am asking to see if there is something I missed somewhere in the docs.
The classes that it won't let go of are these:
x-focus x-btn-focus x-btn-default-toolbar-small-focus
This is with ExtJS 4.1.0 in FF10 on Windows 7. But I did notice similar behavior in ExtJS 4.02 and 4.07, just haven't needed to handle it until now.
I found out what it was:
At some point in the handler chain for each of these buttons the button gets disabled. When a button is disabled in ExtJS it prevents the blur event from firing.
It was necessary to disable the buttons so the solution to simply add button.blur() in the handler was the correct way to do go about it.
Since the ComboBox and FilteringSelect use a 'dijitPopup' whose DOM element gets inserted just before the closing body tag (presumably to help with ensuring it appears above everything else z-index-wise) this means that if the ComboBox is contained in an element that scrolls independent of the window itself and the user opens the dropdown and then scrolls the window (or whatever containing element) using the scroll wheel, that the menu part doesn't move with the control itself.
Is there a straightforward way to ensure that the menu part of the view remains positioned correctly relative to the control itself rather than simply assuming that its starting position is ok?
EDIT: appears to be a known issue (http://bugs.dojotoolkit.org/ticket/5777). I understand why they put the dijit popup just before the closing body tag for z-index stacking and overflow clipping issues, but it seems like it's maybe not the ideal way to do things given the bug in question here and things like:
You can restrict the Dijit theme to only small portions of a page; you
do this by applying the CSS class of the theme to a block-level
element, such as a div. However, keep in mind that any popup-based
widget (or widgets that use popups, such as dijit.form.ComboButton,
dijit.form.DropDownButton, and dijit.form.Select) create and place the
DOM structure for the popup as a direct child of the body
element—which means that your theme will not be applied to the popup.
~ from http://dojotoolkit.org/documentation/tutorials/1.6/themes_buttons_textboxes/
Not sure if this is the very best solution, but here's what I came up with:
Since the widget may be programmatically added/removed, and to avoid coupling a solution with some particular surrounding markup that we can't always count on in all cases, what I did was to hook the _showResultList and _hideResultList methods of ComboBox and when the popup opens, traverse up the DOM till we reach the <html> tag, adding onscroll listeners on each ancestor.
The handler for the onscroll event is simply:
var myPos = dojo.position(this.domNode, true);
this._popupWidget.domNode.parentNode.style.top = '' + (myPos.y + myPos.h) + "px";
where this is the widget in question. I scope the handler to the widget using dojo.hitch. In the close method I remove the listeners. I have to clean up the code a bit before it's presentable, but when it's finalized I'll add it to this answer.
Note: I only show updating the y position here. Part of the cleanup is to add x position updating in case someone scrolls horizontally.
Though its old I just faced this same problem and it looks like a Dojo issue and the fix is available here https://bugs.dojotoolkit.org/changeset/30911/legacy
I've created a Google like SearchBox control in Silverlight. That means, as I type in the box, a DropDownListBox appears just below the SearchBox, showing all the items that match with the text I've typed in searchbox so far (i.e AutoComplete feature), exactly like this:
Now, I want to add a functionality to it : I want to make the DropDownListBox to disappear, as soon as user clicks outside it, or anywhere on the screen. I cannot handle MouseLeftButtonDown (or any such event) in other controls, to accomplish this, because users can click anywhere, including non-silverlight region. Can anybody suggest me what should I do to achieve this?
So my question basically is:
How to know if user has just clicked and the click event occurred outside a particular control?
Please note that AutoCompleteBox doesn't serve my purpose. So I cannot use it.
I have a feeling that working with LostFocus event can solve your problem.
I guess this question is a bit old, but i just stumble upon trying to do the same and finding a solution. This is what i did
Created a Border with All Margins -500, this will cover the full screen essentially.
On Click Behaviour of this Border, the dropdown section of SearchBox
is collapsed.
Adjust z-Index of Border just below the SearchBox and DropDown
section, so clicking on SearchBox or DropDown wouldn't close it.
Set Border Visibility Collapsed, and make it visible when DropDown is Visible.
I hope it helps someone who is looking for the similar problem.
I have 2 logical groups of controls (textboxes,buttons, etc), and I'd like to have an opportunity to change their visibility: for example when the program loads the first group is visible, and after clicking on some button it becomes collapsed and the other group becomes visible. What's the best way to implement this kind of behavior?
Sounds like you want a functionality similar to a TabPanel. You might actually use one and change the style so it doesn't look like a TabPanel but more like a Navigation bar.
Otherwise all would have to implement the functionality by yourself of showing and hiding your areas.
Maybe you should also take a look at the navigation framework: http://www.silverlightshow.net/items/The-Silverlight-3-Navigation-Framework.aspx ... It adds the functionality that view changes are tracked in the URL so that users can also use back/forward buttons in their browsers when navigating through your page.