Noob question.
I have an activate handler in a child List, but it doesn't fire. The activate event on the parent Panel does fire. I tried several other events, and none of them propagate down down the hierarchy. Is this really the intended behavior? If so, how can I ensure that nested widgets initialize properly?
Thanks.
I don't know if its intended behavior but you could add activate listeners on all members of the hierarchy and iterate through the child elements to initialize.
The intended events surely fire for each of the components. For your case, are you adding the activate event in controller? Check if your reference is proper or put that listener in the list component itself and test.
Related
In a C++/winrt app I am able to handle a click in a stackpanel and respond by changing the background of the panel. But if I call the same method from the KeyDown event handler for the main page the appearance of the panel does not change. Both calls to the panel's background change are happening on one of the SHCore.dll threads, and I wonder why they are not on the "Main Thread." Using the dispatcher as follows still leaves me on the SHCore thread:
Window::Current().Dispatcher().RunAsync(Windows::UI::Core::CoreDispatcherPriority::High, [this, theKey,&handled]
{
handled = PressLetterKey(theKey);
});
As there is no visible effect from triggering the change within the keydown handler I begin to wonder if this is a thread issue. Yet the thread does appear to the same one in both the functional and the non-functional cases, and both the clickhandler and the keydown handler are calling the same method on the stackpanel - Could the thread here be the problem, or is there some other reason why the panel does not show its change in appearance when triggered by a keydown?
The triggering doesn't have to be a keydown, of course - I'm really just asking if the stackpanel's appearance can be toggled programmatically...for instance if one wanted to blink a button.
OK, once again I've just made a dumb error, but what can be salvaged here is an answer to the threading question. Yes, the SHCore thread is the UIThread, at least here. The "Main Thread" is something else. Any click event or keydown event arrives on the UI thread ready for action, there's no need to call dispatcher. In my case, I was triggering changes in one of a large series of stack panels and - the one I thought I was triggering was actually not the correct one; the triggered item was simply offscreen... so there you have it!
I'm experience some event handling issues when attempting to use arrow keys without modifiers as key equivalents for menu items in the main menu bar. The problem I'm experiencing is that the main menu bar is handling the key down event as a key equivalent event before a tableView is able to. When the tableView is the first responder, the up/down arrow keys do not change the tableView's selection but rather trigger the key equivalent in the main menu bar.
The reason for this is that the incoming keyDown event for an arrow key is first passed to performKeyEquivalent on the target window, which in turns passes that event down the chain. NSTableView does not respond to this so the event bubbles back up to the application where it next dispatches it to the main menu, via performKeyEquivalent, and thus the event is consumed.
If the main menu does not have a key equivalent, then the event goes back to the window and down the chain via keyDown, which the tableView does respond to and correctly handles.
This is documented by Apple (more or less) in their Event Handling Guide.
Is there a proper way to handle key equivalents like arrow keys without modifiers such that they both appear in the menu item when it's being displayed, but are also properly consumed by any subviews that might handle them?
I've tried various tricks, but each one has numerous pros-and-cons:
NSMenu delegate
One can implement menuHasKeyEquivalent but it appears that you have to implement that for the entire main menu. While you could easily filter out the arrow keys, you also have to validate every other key equivalent, which isn't very practical.
Subclass NSApplication
You can override sendEvent: in NSApplication but the logic for keeping track of where you are in the event handling chain gets a bit hairy.
NSEvent tap
Similar to subclassing NSApplication. Things are a bit cleaner here because I can cheat and have the event tap a bit closer to the tableView, but you're still left with a lot of logic to determine when the tap should consume the event and "force-feed" it to the tableView versus when you should let the event be handled normally.
I'm curious if anyone has any suggestions on how best to implement an arrow key as a key equivalent when no modifiers are present and a tableView might be present.
(macOS 10.11+)
This is a very simple issue that I know I've encountered before, but for the life of me, I can neither remember the solution nor find a page describing it:
I have an NSTableView bound to a content array. When I click on rows with the cursor, the table sends an action that I can handle. When I navigate within the table with the up/down arrow keys, it doesn't send the action.
I've verified that "Column Select" is disabled (this is the equivalent of the old "Full Row Select" option, right?) and have tried setting the NSTableView to Continuous... no luck.
Help pls? Thanks...
I can't find documentation that explains exactly when an NSTableView calls the action that belongs to its target, but from what you say it seems to be specifically linked to a mouse-down event in the table. By thinking of it as a 'selected-row' action you may be generalizing more than is justified. Instead, perhaps you should think of it as a 'mouse-down-in-table' action in which case it's behaving exactly as it should - the action fires only when you mouse down. Such an event will often result in a selection change, but not always - and as you're finding out the selection can change independently of mouse-down events.
Instead of using the table's action to catch selection changes, it's much more common to use the various NSTableView delegate methods. Is there a reason you aren't using these?
These provide more detailed information about how the selection is changing, and they'll catch changes triggered by any kind of event (mouse, keyboard, or programmatic)
I have a form built in interface builder.
Now I want to receive a notification when any element that is a child of a particular view is changed (be it text, or the select element, or a checkbox, etc).
Basically I want to know whether or not the form is "dirty" (changed).
How can I accomplish this?
One simple answer is to connect those UI elements which might change the value of the data model to an IBAction in the parent view controller. In that IBAction you can decide if you want to save the data, present a dialog, etc.
I am currently using a UINavigationController based flow:
Events +-> Event Input
|
+-> People -> People Input
The model underlying Events and People fires notifications when the collection changes. I'm hooking up the observers in viewWillAppear:animated: and unhooking them in viewWillDisappear. This all seems fine, but what I really want is for the observer for people to be hooked up when I transition from Events to People and stay hooked up until I transition back to Events. That way, even when People Input hides People, the notification will be handled so I can update my list.
Note: I am not using segues.
Where are the best places to hook up the observers and unhook them?
Then you can enlarge the time scope from viewDidLoad for observing to dealloc for unobserving. Then you can update your content at the sole condition that the view actually exists.
The way I chose to fix this was to compare the current controller to the navigationController collection of viewControllers. If it is not contained in this collection, then I know the view was popped and I can unobserve events. I make this test in viewDidDisappear.