I'm working on a Windows Phone 8 app. This app will allow a user to flick a panel up. I want this to work very similarly to the way the lock screen works. When the user 'flicks' the panel up, I want it to automatically, move up accordingly. Does anyone know how to do this? Currently, I have the following:
<Grid x:Name="myGrid" Background="Peru" VerticalAlignment="Stretch">
<toolkit:GestureService.GestureListener>
<toolkit:GestureListener x:Name="myGridGestureListener" DragStarted="myGridGestureListener_DragStarted" DragDelta="myGridGestureListener_DragDelta" DragCompleted="myGridGestureListener_DragCompleted" Flick="myGridGestureListener_Flick" />
</toolkit:GestureService.GestureListener>
<Grid.RenderTransform>
<TranslateTransform x:Name="bannerGridTransform" Y="5000" />
</Grid.RenderTransform>
</Grid>
private void myGridGestureListener_Flick(object sender, FlickGestureEventArgs e)
{
if (e.Direction == System.Windows.Controls.Orientation.Vertical)
{
}
}
For the life of me, I can't figure out how to get myGrid to smoothly react to the flick gesture accordingly. I figured someone would have already implemented this, however, apparently, I'm wrong.
Thank you!
Gesture Listener is deprecated in Windows Phone 8. When you download the latest toolkit source. It contains a sample toolkit app for window phone 8. When you click the gestures, it throws a dialog which says
The GestureListener is now obsolete in windows phone 8, as the built
in manipulation and gesture events now have functional parity with it.
This sample and the sample code demonstrated how to use the
manipulation and gesture events for purposes for which one previously
would have used the GestureListener
If someone need to implement gestures in Windows Phone 8 - look at this https://github.com/PedroLamas/WPtoolkit/blob/master/PhoneToolkitSample8/Samples/GestureSample.xaml.cs
Unfortunately this isn't as trivial as a couple of lines of code on SO since you have to account for the pan while you are holding down the screen and the flick which needs to seamlessly continue on from the pan when the user lifts their finger. A great example of this is actually a darts game since you want the dart to move while you are dragging and then fly off when you release (the flick).
You can find a great example with source code at http://windowsphone7developerguide.blograby.com/darts-gesture-listener-flick-gesture/
You dont need to use toolkit gesture listener anymore. You can use in built manipulation events. Here is the sample:-
http://phone.codeplex.com/SourceControl/latest#PhoneToolkitSample8/Samples/GestureSample.xaml.cs
Related
I'm currently working on a window that focuses on some elements on screen while blurring the rest of the area.
Using common methods like the WindowCompositionAttribute and the others are not suitable for this situation as there are limitations to it and it doesn't meet the standards regarding the intensity of the blur, contrast and colors which should be strict.
What i have managed to solve my problem was building an image stream with a light image encoder to enhance performance but then that wasn't enough. So, i thought of writing a motion detection algorithm to only steam when there's motion, but it still didn't change the performance drops.
What i need is something like those of the native OSX windows and Windows 10 Start Menu, so how are they created and run efficiently without any heavy load on the performance?
To create a new Window from scratch you have to set WindowsStyle to none (AllowTransparency="True" can be set only along with WindowsStyle="None") and from there build the style of the window.
However, you will face several issues if you follow this approach:
-no buttons (minimize, close)
-no support for fullscreen (taskbar issues)
I would suggest you to have a base view and include the other views inside the main view(which has the blur effect).
The blur effect could be obtained easily by doing something like below:
<Grid>
<Grid Margin="5" Background="#FF3782DC">
<!--<Grid.Background>
<Image Source="test.png"></Image>
</Grid.Background>-->
<Grid.Effect>
<BlurEffect Radius="100" />
</Grid.Effect>
</Grid>
<TextBlock
x:Name="textBlock"
Height="61"
Margin="136,82,211,0"
VerticalAlignment="Top"
Text="test"
TextWrapping="Wrap" />
</Grid>
I've set a color for the background, but you could set an image as background and by default it would be blurred (here you should set a binding and every time the view changes, you have to take a snapshot of the screen and set the source of the Image). However you will probably have some performance issues, but with a good encoder (JPEGencoder) it will be fast enough.
Hope that helps you!
I am very very beginner of C# programming.
The previous program that I made can get touch input as a click event on the Surface Pro.
So, It cannot get multi-touch input.
How can I get the multi-touch inputs(positions on the screen) on the Windows Surface Pro when writing the application in c#?
I heard that I can use touch class, but I never know how to use it ....
I am struggling with this for 2 weeks, but could not make any progress.
Anyone who can explain how to use touch class specifically?
Or any other suggestions to get touch input values from the Surface pro touch panel?
Assuming you are programming WPF.
Register UIElement.TouchDown event, for example, in you MainWindow's constructor, add
this.TouchDown += MainWindow_TouchDown;
If multiple fingers are touching screen at the same time, the TouchDown event is fired for each finger.
You can get the position of the touch (relative to screen) from the TouchEventArgs which is passed as an argument to the event handler.
void MainWindow_TouchDown(object sender, TouchEventArgs e)
{
TouchPoint pointFromWindow = e.GetTouchPoint(this); //relative to Top-Left corner of Window
Point locationFromScreen = this.PointToScreen(new Point(pointFromWindow.Position.X, pointFromWindow.Position.Y)); //translate to coordinates relative to Top-Left corner of Screen
}
Note: .NET 4.0 is required, Windows 8 shipped with .NET 4.0 pre-installed. If you are running on Windows 7, you have to ensure it is installed.
Currently, when tested using Media capture using capture device sample, I realize the camera is not something I want. I wish it to be in mirroring mode. Currently, it is not.
For a camera preview to be in mirroring mode, may I know is it hardware dependent or hardware independent. Possible that if I run the same code with different hardware, the camera preview will be in mirroring mode? If it is hardware dependent, how can I check whether my camera preview is in mirroring/non-mirroring mode?
To make it in mirroring mode, I try to follow this thread. I try MediaCapture.SetPreviewMirroring(true). No effect as all. The camera preview is still in non-mirroring mode.
I try captureElement.RenderTransform = new ScaleTransform() { ScaleX = -1 };. The whole camera preview become plain grey color.
The last approach I would like to try, is try to perform flipping in C++ code through MediaCapture.AddEffectAsync(). However, that need to go back to my first question. Can I just simply perform flipping, or do I first need to check whether the incoming buffer is in mirroring/non-mirroring mode? If yes, how do I check?
For those looking for a more updated answer since this question was asked, the proper way on UWP and WinUI is to set the FlowDirection="RightToLeft" on the CaptureElement.
<CaptureElement x:Name="previewElement" FlowDirection="RightToLeft"/>
Use
<CaptureElement x:Name="previewElement" Margin="0" Stretch="UniformToFill" RenderTransformOrigin="0.5,0.5">
<CaptureElement.RenderTransform>
<CompositeTransform ScaleX="-1"/>
</CaptureElement.RenderTransform>
</CaptureElement>
The key lied on RenderTransformOrigin="0.5,0.5". We need to flip from center of preview.
Is it possible to manualy lock the phone orientation in Windows phone 7 ?
Because I'm using the accelerometer to handle buttons' rotation with a fixed UI.
I've tried that :
In the XAML
SupportedOrientations="Landscape" Orientation="LandscapeLeft"
OrientationChanged="PhoneApplicationPage_OrientationChanged"
And in the code behind :
private void PhoneApplicationPage_OrientationChanged(object sender, OrientationChangedEventArgs e)
{
//Orientation locking
//Do nothing
}
But the UI is still shifting between landscape left and landscape right...
Thanks.
There is no way to prevent the shifting between LandscapeLeft and LandScapeRight. This is by design.
As a work around, you can manually rotate/transform your UIElements in the OnOrientationChanged so that the user doesn't see a difference.
I've used this technique to keep a "background" image from appearing to rotate regardless of orientation but then having a separate control which appears like a popup but which does respond to orientation changes show on top of the image.
Hi I found a solution by overriding OnOrientationChanged method. It works for me. That do not affect system tray and application menu, but page stay in the selected orientation.
protected override void OnOrientationChanged(OrientationChangedEventArgs e)
{
if (e.Orientation == PageOrientation.LandscapeLeft)
base.OnOrientationChanged(e);
}
add this this.SupportedOrientations = SupportedPageOrientation.Portrait; after InitializeComponent(); in MainPage() constructor to lock the orientation in Portrait mode. It works fine for me.
I have a very simple WPF user control that is mixed in with a windows forms app. It has a list box that renders its scroll bar without the thumb (image below). I narrowed it down to a plugin in my app that uses Managed DirectX (MDX). If I remove the plugin, the scroll bar is just fine. I know MDX is deprecated, but I don't think today is the day to consider an upgrade. Has anyone ever seen their scroll bar get messed up, or has any idea what I should do?
And I should add, that this control also lives in a plugin. There is no way for the 2 plugins to reference each other.
<UserControl x:Class="MAAD.Plugins.Experiment.Visual.TestEditor"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" Height="403" Width="377">
<ListBox Margin="12" Name="listBox1" />
</UserControl>
Update: You can read about the solution below.
As it turns out, I stumbled on the solution today while working with a client. If you add the CreateFlags.FpuPreserve flag to your device creation, the scrollbar should go back to normal.
I've seen this bug too. It is not a SlimDX issue per se, but rather due to DirectX using 32-bit math on the x87 FP stack.
Use the FpuPreserve flag when initializing your device and the problem should go away.
My suggestion is to get rid of your MDX plugin.
I've used both WPF and MDX, though not in the same project. Both libraries talk to DirectX and ultimately will store state at the native level, which can cause problems. With WPF I've had rendering issues related to my video drivers and the fix was to upgrade the video driver to a newer version.
Initializing DirectX can affect the ways DirectX (and your CPU!) performs for your whole application . For example, when you initialize MDX by default it will set the CPU to do all floating point calculations in single precision, for the whole process, regardless of how you declare your original value. As you might imagine this lead to a lot of head scratching for a long time as to why we were getting different results in the application and our unit tests.
I suspect that when MDX is initializing it is enabling, or disabling some feature or setting in your graphics card (or possibly some software setting) that is affecting the WPF pipeline somehow.
I wish I could be more helpful. Good Luck.
I had this problem as well. As mpg found, adding the D3DCREATE_FPU_PRESERVE flag to the device creation will fix it. if anyone is wondering what the code looks like:
d3d->CreateDevice(
D3DADAPTER_DEFAULT,
D3DDEVTYPE_HAL,
(HWND)this->Handle.ToPointer(),
D3DCREATE_HARDWARE_VERTEXPROCESSING|D3DCREATE_FPU_PRESERVE,
&d3dpp,
p);
Have you tried SlimDX instead of MDX? SlimDX is a newer wrapper around DX and is actively under development. Perhaps you could do in SlimDX the same thing you use your MDX-Plugin for and the scrollbar functions normally again.
Peter is right about the interaction of WPF and MDX. WPF uses DirectX internally. So changing settings in MDX (or SlimDX) can change how WPF behaves. You could also try to take a look at the code of the WPF scrollbar (for example with the .NET Reflector, IDA, whatever you need) and check the settings the Scrollbar relies on.
Are you on Vista? We've seen a lot of SlimDX/WPF simply vanish by creating a Direct3D9Ex device instead of a normal one when running under Vista targets.
I took everyone's advice and ported my app to SlimDX. It wasn't too bad (almost every class/method/field is named exactly the same in SlimDX as MDX). Unfortunately, I still had the same issue. I was able to simplify Both SlimDX and MDX down to the following app:
public partial class MainForm : Form
{
Direct3D Direct3D = new Direct3D();
Panel slimPanel = new Panel();
public MainForm()
{
InitializeComponent();
CreateDevice();
BuildWindows();
}
void BuildWindows()
{
var listBox = new System.Windows.Controls.ListBox();
listBox.ItemsSource = Enumerable.Range(0, 100);
var elementHost = new ElementHost();
elementHost.Child = listBox;
elementHost.Dock = DockStyle.Fill;
Controls.Add(elementHost);
slimPanel.Dock = DockStyle.Left;
Controls.Add(slimPanel);
}
void CreateDevice()
{
PresentParameters presentParams = new PresentParameters();
presentParams.BackBufferHeight = slimPanel.ClientRectangle.Height;
presentParams.BackBufferWidth = slimPanel.ClientRectangle.Width;
presentParams.DeviceWindowHandle = slimPanel.Handle;
var device = new Device(Direct3D, 0, DeviceType.Hardware, slimPanel.Handle, CreateFlags.HardwareVertexProcessing, presentParams);
}
}
The scroll bar won't show. I was able to get the scrollbar to show if I made sure the listbox got to paint before the Device was created.
The final solution was to add a WPF ListBox to my form in the constructor then delete it after the form finishes loading. I'm not sure if this is a bug in WPF or DirectX, I might try submitting a bug with Microsoft.
BTW, I can't get XNA to cause this issue.
I'd second the reservations of the previous posters regarding MDX in the context of WPF. One shot into the dark though:
Have you tried targeting your control for .NET Framework 3.5 SP1 already? There has been significant work regarding DirectX/Direct3D interoperability and performance, see for example:
Paragraph 'Graphics Enhancements' in What's New in .NET Framework 3.5 Service Pack 1
Paragraph 'WPF Interoperability with Direct3D' in What's New in .NET Framework 3.5 Service Pack 1
Some of those enhancements might eventually yield positive side effects regarding your problem.