I want the Holding event occur quicker, by default it takes around 2 seconds to occur:
<Grid Holding="Grid_Holding">
</Grid>
Couldn't find a solution in the documentation. I think I need to change states somehow in Blend!
How to decrese the time holding event occurs? thanks.
It doesn't seem you can change this time threshold! It should be, at max, a user setting (not an application setting). According to the Reference here, this is what define the Holding event:
The Tapped, DoubleTapped, and RightTapped events occur only after the touch point is removed. But the initial Holding event occurs while the touch point is still in contact. The event occurs if the touch point remains in approximately the same PointerPoint position for a period of time. The exact timing of what the system interprets as a holding action is adjustable by users through system settings.
http://msdn.microsoft.com/en-US/library/windows/apps/windows.ui.xaml.uielement.holding.aspx
Also, from the same reference:
Tapped and Holding are mutually exclusive. If the action passes the time threshold to be considered a Hold action, it's not considered to be a Tap action also.
Wouldn't you prefer to subscribe to Tap event instead, or maybe both?
So you would monitor when it happens fast and slow.
http://msdn.microsoft.com/en-US/library/windows/apps/windows.ui.xaml.uielement.tapped.aspx
Related
My WPF Custom Control handles dragging shapes across an image on a canvas. Some shapes may be dragged beyond the limits of the image but others should be limited. But the control itself does not know the rules, only clients (i.e. the XAML page that created the control or its View-model) knows what they are.
So I need to give this control a way to let clients know that shapes are about to be dragged so that clients may limit drag for the duration of the drag operation
I had the idea for a RoutedEvent (e.g. ItemDragStarting) that my control could raise when shape dragging begins. I reasoned that we already know that event handlers traditionally set the RoutedEventArgs.Handled property to stop further processing of the event. That seems basically like an "OUT" parameter doesn't it?
So maybe my RoutedEventArgs object of my ItemDragStarting event could expose a "ValidLimitRect" parameter to allow clients to optionally set the valid limits. After the event fired, the control could check this and, if set, limit the drag for this one drag operation.
For example:
// User has started dragging items. Raise the event with no limit rect
var args = new DragStartingEventArgs(itemsBeingDragged, Rect.Empty);
RaiseEvent(args)
// Did any of the clients set the limit rect to anything?
if (!args.LimitRect.IsEmpty)
{
// Save the value to limit dragging
}
But I've never before made event-firing code actually care about the end state of its arguments. Until now they've always been fire-and-forget. So I am wondering if this is even a good idea.
Is this anything resembling standard practice in WPF or is this code-smell? If it is the latter, what's the better way to do this?
I have a complex chart that I'm drawing and the PostPaint event for System.Windows.Forms.DataVisualization.Charting.Chart seems to be firing prematurely. There is no chart on the screen yet.
Does anyone have a better understanding of the behavior of the PostPaint event with large charts? Is there a better event to listen to? Recommended strategies?
I'm not sure posting code would provide any benefit.
ORIGINAL POST:
So it turns out the answer to this (for me anyway), is to create another thread (I'm doing it with a Task) off of the event. This thread's job is to continually compare the region with an empty image and when it is no longer empty, grab the image and save it in the database. Because it's a thread, this frees up the chart to eventually render itself.
FINAL POST:
In the end, I had to put a lock inside the PostPaint event (it was firing multiple times as TaW indicated it would) and make sure the code inside would only execute a single time (I have a Draw button so these controls get reset every time it's clicked). Additionally, it was necessary for me to create a task to actually do the work of capturing the image and storing it in the database. If I didn't do this, I would get a blank image every time. I did not actually have to check point count or sample the image to see if it was blank.
Locking down the event and creating the task inside the event is what made the difference.
According to this question, the answer begins with "The MouseEnter/Leave events are too unreliable to do this." What exactly makes these events unreliable?
The mouse position is only polled every so often. It's very possible that one of those events - the mouse entering, or leaving, could occur between when the polls occur, and the events would not fire correctly.
This also makes a pretty concrete assumption that mouse movement will be continuous, rather than discrete - what if the user has a touch screen monitor? What if the mouse goes directly from inside the control to being way outside it, with no movement in between?
You missed the point entirely. These events are unreliable for the OP question, not in general.
The question was about seeing if the cursor is inside the forms client area. Having many controls the MouseEnter/Leave are unreliable because you will get these events even if you are inside the form's area.
I have a WPF-program that has a grid with two columns. First one has buttons and second one has WindowsFormsHost-element that embeds an ActiveX component. One button hides the WindowsFormsHost-element and shows a SurfaceListBox on the same location on screen in the second column. If I have touched the WindowsFormsHost element just before pressing this button, it takes approximately 8 seconds from the last touch until the SurfaceListBox becomes responsible for touch gestures.
The thread is probably not blocked, because I can use the buttons in another column, and use use the ListBox with mouse.
The ListBox remains unresponsive for touch events forever, if I touch it within the 8 second waiting time. So it seems that somehow the ListBox does not get the touch events.
If I programmatically create another ListBox, it does not work either, for 8 seconds, if it is placed in same are on screen than the WindowsFormsHost was.
I noticed there is a method CaptureTouch() for UIElement, but I cannot get hold of to the TouchDevice that I could pass it as parameter. I have set ManipulationEnabled="true" for every UIElement and no TouchEvent will be fired.
I have also desperately used UpdateLayout() etc with no luck.
So I think the touch gestures are somehow routed wrong and after the waiting time it implicitly fixes the routing, but is there a way I could make the touch gestures work in the ListBox immediately?
The problem disappeared when I removed "focus tracking for launching on-screen keyboard" from my program.
So in case of somebody else struggles with the same problem,
http://www.infragistics.com/community/blogs/blagunas/archive/2013/12/17/showing-the-windows-8-touch-keyboard-in-wpf.aspx and SurfaceListBoxes aren't meant for each other.
I have been trying for some time to create a class/series of classes that, upon detecting a resize in a related object, attempts to halt the resize of the object and create a smooth resize animation for it.
However, I have always had a problem with the objects 'flickering' on the screen for a second at the target size before the animation kicks in.
Long story short, after some serious debugging and self-doubt, I am under the impression that calling Storyboard.Begin() does not affect the target value until the next clock tick. I presume that this has something to do with Storyboard.Seek() not occuring until the next clock tick. (See the MSDN Reference). And as such, the object adopts its new height for a single frame before the animation kicks in which pulls it back to the starting height.
I have spent a long time trying to get this working because it's not nearly as simple as it seems. I can't set FrameworkElement.Height to the e.PreviousSize.Height in a FrameworkElement.SizeChanged event handler, because that affects the 'true' height of the object. As an example of why this doesn't work, is if something changes the 'true' height of the object while the animation is playing, then re-setting FrameworkElement.Height to the target height that was collected when the animation began could set it as an incorrect, out-dated value.
There's more things I've tried, and I'm sure they'll come up as answers arrive, but any ideas you have will be very much appreciated.
You'd probably have better luck by creating a layout container that handles the resize of the child objects, something like Robby Ingebretsen's Animated Panel.