Here is my problem; I want to display a context menu, with items created on the fly in the code behind, when a D&D operation has finished.
What I can't do is
Insert an item that will cancel cancel the drop operation, if selected
I can't find a way to keep the menu open when I click anywhere outside of the menu
How can I do these two things?
Displaying the context menu will not block the D&D operation from completing, so it won't wait until the user addresses the context menu. You would have to somehow save the D&D action (capture what is being dropped and hold on to it) and wait to complete the action until after the context menu has been addressed.
A context menu will automatically close when it loses focus. However there is a StaysOpen property that overrides this behavior. If you set StaysOpen to true, it will remain open until you explicitly close it (by settings IsOpen to false).
Related
I have a menu that is implemented in a way that when a menu item is pressed, a popup containing it's sub-items is open.
When running with touch screen, occasionally user touches 2 menu items at the same time with his fingers - and this leads to one of the menuitems have a touch capture which is not released until another window gets focus, making the app seem stuck.
How can I prevent such a case?
thanks
You could use a queue that contains delegates:
When triggering a command, add the delegate to the queue.
Then grab the first delegate of the queue and flush it afterwards.
Now you only have 1 "command".
I found the cause for the problem: the popup used to display submenu items had StaysOpen set to false.
This causes the Popup to capture input so it can know when to close itself once a click was made outside its boundaries.
Setting its StaysOpen property to True fixed the issue.
so, I have this ListView in grid mode. I am dynamically updating it using a CollectionView. now, the problem I have is that when I open a context menu by right clicking on an item in my grid the context menu closes after the item updates--now, it is not a new item but it is the same item. Does anyone have any ideas on how I can make the contet menu stay open after the item updates?
[Edit]
The grid is part of a public safety application that updates in near real-time. so the items are periodically added, removed, and updated. If we right-click on an item to open the context menu and an update occurs before I can close it--even if the particular item does not change in any way--the context menu closes. The desired behavior is for the context menu to remain open.
If you could supply your XAML that would help, but my guess is that you have defined the context menu on the ListViewItem element and that the menu closes because the whole ListViewItem is regenerated or replaced by WPF.
Perhaps you can define the context menu on the ListView instead? You will have to update your commands and get the selected item from the list when executing, since the context will no longer be a specific item.
I have a top-level menu item which is responsible for refreshing a datagrid in the same window. My current control flow is:
User clicks on refresh
In the click event handler, I:
Disable the menuitem, by setting oMenuItem.IsEnabled = false.
Dispatch an action to refresh the grid and in that action, I re-enable the menuitem, by setting IsEnabled = true
The problem is that the user can click refresh even when it's disabled and it's as if the clicks get queued up. When the action returns it goes on to process the remaining, "queued-up" clicks. What I expect is: all clicks while the menuitem is disabled are ignored and only when it's enabled, the clicks are acknowledged.
The weird thing is that if I just disable it and never enable it it stays that way, i.e., it is disabled.wpf,
"Dispatch an action" you mean by calling Dispatcher.BeginInvoke() or some other kind of async opetation?
Anyway, in both cases you can get a "handle" to the operation (DispatcherOperation or IAsyncResult) and store it as a field when you dispatch your operation. When it completes - set this field to null.
In the click event handler of the menu-item check this field. If it's null it means it is safe to start the operation. If it is not null - return immediately and do nothing.
And something not related to your question but important - why not use Commands? That way you don't need to play with event handling and enabling/disabling. And of course commands can be invoked by multiple means (for example - the user selected the command from the menu using the keyboard and pressed Enter. No mouse clicks involved, but should do the same as clicking the menu item).
Alex.
I'm having a problem when the Silverlight toolkit's ContextMenu is clicked while it is over a UIElement that has registered a Tap event GestureListener. The context menu click propagates to the underlying element and fires its tap event.
For instance, say I have a ListBox and each ListBoxItem within it has registered both a ContextMenu and a Tap GestureListener. Assume that clicking context menu item2 is supposed to take you to Page1.xaml, while tapping on any of ListBox items themselves is supposed to take you to Page2.xaml.
If I open the context menu on item1 in the ListBox, then context menu item2 is on top of ListBox item2. When I click on context menu item2 I get weird behavior where the app navigates to Page1.xaml and then immediately to Page2.xaml because the click event also triggered the Tap gesture for ListBox item2.
I've verified in the debugger that it is always the context menu that receives the click event first. How do I cancel the context menu item click's routed event propagation so it doesn't reach ListBox item2?
Thanks for your help!
You can get around the problem by doing the following:
In the context menu's Opened handler set LayoutRoot.IsHitTestVisible (LayoutRoot is the default name for the root UIElement) to false
In the context menu's Closed handler set LayoutRoot.IsHitTestVisible back to true
You could try adding a rectangle with a transparent background (important) over the effected area/page when showing the context menu.
I had a very similar issue, but I am using the ManipulationCompleted event as a "tap" detector as the object the ContentMenu applies to is a custom control.
LayoutRoot.IsHitTestVisible didn't work for me, perhaps because it does not apply to Manipulation events. However, it set me on the right path. I just implemented my own simple equivalent of it - I created a boolean variable bCancelManipulation in the page's scope.
In the ContentMenu's Opened event set it to True.
In the ContentMenu's Closed event set it to False.
In the ManipulationCompleted function, the first thing I do is check
if(bCancelManipulation==true) { return; }
It's kind of a hack, but it works great and is quite simple to code - it can easily be adapted to a Tap event too.
I have a button which launches a "modal dialog" - it just creates a transparent grid covering everything, with the "dialog" created on top of that.
However I have a strange issue - if I double/triple click the button really fast (or add some delay in the event code), the button click event is executed multiple times, creating multiple overlapping modal dialogs. If the first action in my event is to disable the button (IsEnabled=false) it seems to prevent this.
My guess is that Silverlight is being multithreaded with input - it is not only recording the second click in another thread (while the button's click event is running), but it is jumping the gun by evaluating which control should be the target before the previous event has finished executing. Even though that event alters what control is at those mouse coordinates, it doesn't matter.
Does anyone know anything about this behavoir, or a way around it? If I have something like a save window, where the user clicks a save button, a blocking grid ("Saving...") is placed up while it saves, and then the whole "window" is closed, I'd like to avoid the user being able to queue up multiple save event clicks (this could lead to unpredictable program behavoir).
If you've ever worked with WinForms or WPF, this is expected behavior. Your button is broadcasting its Click event until your modal dialog covers it up. Unfortunately, there is some amount of time between your first click and when the modal dialog covers the button which allows multiple clicks to the original button.
You have two solution choices:
Disable the button after the first click and then re-enable after the modal dialog returns. You've already mentioned that this works.
Write code in the Event Handler of the button to determine if a modal dialog is already being displayed. This way, you're putting the responsibility in one location rather than splitting it up (disabling and re-enabling the button). This would be my preferred solution.
I think what you're seeing is the behaviour of Silverlight's routed events.
You can set the Handled property of the event arguments to true to prevent the event from bubbling.