I've got a problem nesting two directives.
This code with one directive works as expected: http://plnkr.co/edit/nq1DD0
But when I wrap this directive into another one with transclusion the access to the controller scope breaks: http://plnkr.co/edit/zaWDQxqeFe9aYIBPnpJ3
What's wrong with it?
Thanks in advance for the help!
Ksenia
I've fixed your plunker, see my fork here: http://plnkr.co/edit/ul4HcAoopJjdcj7dXFYt?p=preview
There were few problems with your implementation:
In the autocomplete you were chaning the selection object and not its properties
scope.$watch was not well defined in the emptyverifier
In overall you should avoid using the same names for value/attributes/properties etc, the "selection" keyword is used all over the place so it quite a challenge to understand the code;) I've only fixed the bindings and selection part... haven't touched the logic that should show the "empty message" - you should try to handle "change" event of the autocomplete plugin.
Related
What is CollapsingToolbarLayout's toolbarId for? I can't find any description in Google and my AppBarLayout/CollapsingToolbarLayout works properly without it.
I figured it out myself by looking into the source code of CollapsingToolbarLayout (CTBL).
CTBL in fact doesn't need a toolbarId set explicitly because it searches for a toolbar in its child views if no id is set. However, by setting a toolbarId we can optimize our code because then the CTBL doesn't have to search itself (which happens repeatedly).
https://github.com/material-components/material-components-android/blob/master/lib/java/com/google/android/material/appbar/CollapsingToolbarLayout.java
I'm working on an app that'll have a range of images and the collectionview is not showing up at all. I was following this article, which I translated to C#.
here is an example app I made to show a minimal example of what I'm trying to do.
When I run through the code, GetCell in the collection source isn't firing which I know is the problem, but I don't know why it's not firing and I'm simply at a lost on what I'm missing.
I test it again today and I can make sure that the problem is caused by the MosaicCollectionLayout.
What I did today is that I removed your collectionView and add a new collectionView, then I add Constrains to it with a fixed height and width(to make sure it appears even if there is no data), then I change the layout to FlowLayout, it works, here is the screenshot:
After that, I changed the layout back to MosaicCollectionLayout, I get an exception in the line _cachedAttributes.Reverse(lastIndex.Row, firstMatchIndex.Value); inside the method LayoutAttributesForElementsInRect.
I checked the article and did not find a solution yet. Maybe there is some mistakes in the codes translated from swift to C#. So the problem is not related to the xib, please check the code in the method LayoutAttributesForElementsInRect.You can also try add Constrains to your collectionView. Hope these information helps you.
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.
The whole day I am trying to solve this simple issue, but without any success.
I found a lot of hints in internet, but seems, that none of them is valid for my problem.
My issue is quite simple: I want to change the caption of a menue item while runtime
But it seems, that all solutions I found are very specific.
My requirements are this:
- it is a MFC application (VS2010)
- It is a SDI application, not MDI
- I want to change the caption of a main menu item (like "File"), not an entry of a submenue.
Because of main entry item, there is no ID for the menu item. Therefore solutions with ON_UPDATE_COMMAND_UI will not work!
My problems are:
- either the code I tried, is generating an assertion or exception
- or the function call returns with false
- or the function seems to work well, but I do not see any result (the caption is still unchanged)
Maybe I am using the wrong functions, or the wrong place for calling the functions.
Has anybody an example, which would work within my application pre-conditions?
Many, many thanks!
Richard
Windows cleverly hides the function to modify a menu under the arcane name of ModifyMenu. I hate it when they do things like that. Really makes me wish for Linux/Unix, with nice clear names like shmdt and mvwaddchnstr. Anyway, getting off my soap box for the moment, you'd call it something like this:
GetParentFrame()->GetMenu()->ModifyMenuW(1, MF_BYPOSITION, 0, L"New Item");
GetParentFrame()->Invalidate();
I have a core data document based cocoa app that is working well except for one slightly odd problem.
For some reason, if I make a change to any of my fields the menu/window don't seem to recognize it - ie. the red close button doesn't get the black 'dirty' indicator and the File/Save menu item isn't enabled. However, if I attempt to close the application (via command-Q), I do get the popup asking me if I want to save my changes.
It seems that the document's dirty flag is being set, but the window/menu items aren't reacting to it. I am curious as to where I might look to see why this might be the case. I suspect that it may have something to do with my window not knowing about my ManagedObjectContext...
The only slightly atypical behaviour is that my document's makeWindowControllers method has been overridden and I am adding my window controllers using a call to my document's [self addWindowController:xxx] method. My window controllers subclass from NSWindowController so I had to add my own instance variable to each window controller to hold the ManagedObjectContext, but I suspect that this isn't getting passed to the window/menu. Not sure what the normal pattern is here...
Anyway, any thoughts would be much appreciated. Thanks
From the description it sounds like your UI elements are not actually bound to the document itself. If so, then the UI elements are not observing the document and are not reacting to changes in the document. Check the bindings.
Thanks in part to TechZen, and also re-reading my own question (in particular, where I said "I suspect that it may have something to do with my window not knowing about my ManagedObjectContext") I started to look at the bindings for my WindowController subclass.
As it turned out, I hadn't bound the window outlet for the File's Owner to my actual NSWindow. As soon as I did that, the black dirty dot and the window's menus started behaving correctly.