I am developing a touch screen application and allow users to add touch-based markup to an overlay over content using an ink canvas. I have reached a point where the view behind the overlay has an element that needs the user should be allowed to interact with, but events are captured by the InkCanvas and not by the underlying control. Is there a way to display strokes, but still allow controls behind the InkCanvas to capture events?
You can set InkCanvas.IsHitTestVisible = false and it will still display but you will not be able to interact with it and all events will go to elements lower in the z-order, which sounds like exactly what you want.
In my case I'm toggling the InkCanvas. To accomplish this, I also had to set InkCanvas.InkPresenter.InputDeviceTypes = CoreInputDeviceTypes.None to disable it.
Related
Is there a way to move a popup to back, so it does not always display on the front of the application?
I have a canvas that displays many shapes, which are resizable. To get the resize box I am using a popup, because it was suggested that the best way would be to use adorners, but these are not used in UWP, so the alternative are popups. It works quite well, but when I have another element overlaying my canvas and resizing was enabled on a shape, the popup elements (resize thumbs/nodes) are displayed on top of the element that should be overlaying the canvas. Is there a way to tell the popup that it should not display on a "higher level" than my canvas?
A Popup control is intended to be displayed on top of all other content so it seems you're not using an appropriate control for what you are trying to achieve.
Without seeing more of your code and having a clearer idea of what you're doing (repro?) it's hard to suggest what you should do. However, I'd avoid resizing control that aren't on top of the viewable area or having multiple items in a resizable mode (or just with adorners displayed) at a time. Both of these should avoid what you're reporting.
How can i prevent scrolling up the background image of the page? The rest content should scrolling like always
You can handle the InputPane.Showing and InputPane.Hiding events to override the content scrolling as you'd like. By default, the InputPane will apply a translation to the entire page to keep the focused control in view, but you can handle this yourself for custom behaviour.
For your case, you can find the space the InputPane will take from the OccludedRect property, do the math to figure out how far (if at all) you need to move the page to keep the focused control visible, and apply a transform to a control container rather than to the entire page. Set the EnsuredFocusedElementInView property to indicate that you did the sliding so the InputPane doesn't do its own.
Another option would be to handle Showing and apply an inverse transform just to the image, but it will be trickier to figure out how far the InputPane moved things than it will be to just move them yourself.
When a form loads, I'd like it to show a loading image (within a Picture Box) and a standard Windows label with some text. However, all I see are white boxes, or sometimes I see another form underneath. How do I get the image and label to display properly.
I've tried setting AllowTransparency to false when the form loads, and also setting the Transparency Key of the form to some other colour, but nothing has worked.
The project is C# .Net v3.5 (also tried v4 and v4.5).
Any ideas?
First, you can't display an image, busy-wait, and then change the image - this will never redraw anything, leading to the symptoms you describe. To "wait" you will need to return control to your main application loop so it can continue to process messages (e.g. to handle redraw requests for your window). One way to do what you want is to display your initial state (splash screen) and then use a timer to call you back later to change the display to your second state.
The next problem you face is using forms controls with transparency. Most controls treat "transparent" as "fill your background with your parent controls color", which is not what you want. An easy way around this is to implement a Paint handler and draw the image and text for yourself - this gives you much more control of how your display looks, and will also allow you to get a cleaner redraw (no flicker or other problems caused by the display being built up but by bit in several controls)
Lastly, consider implementing your splash screen display as a separate control/form that you show above your main form during loading, as that makes it easy to "overlay" on your main form without having to change its design at all.
Just write formObjectName.Refresh() after formObjectName.Show()
I'm having tons of issues trying to integrate Microsoft's WebView in my WinRT application and one of them is the following. I want to display the WebView and its content (which comes from a local offline server but that works like a charm) and I don't want the user to be able to click around ; basically completely disable user input on this WebView.
There is no IsEnabled property on this control so I tried:
Catching the many Pressed-like events and setting the Handled property of the event object to false in each one of the handlers
Catching the GotFocus event of the WebView to set the focus on another control immediately
Putting the WebView in a ContentControl, then set the IsEnabled property of the ContentControl to false
Obviously, none of these workarounds did work so I'm facing a brickwall here. Maybe some of you can help find a solution?
More details if that can help: the web page that is loaded contains an HTML5 canvas where the user can draw things (like in Microsoft Paint). There are also links (ahref). I dont want the user to be able to draw on this canvas, and I don't want them to be able to click on these links as well!
Thanks
Hi you can use a if the content is not animated then you can use a Rectangle instead of the WebView and in the rectangle you use a WebViewBrush, this actually take the webview and render it's content as an image on the rectangle. since it is an image no interaction is available on the rectangle, but if you have animation then you will lose them.
Generally this trick is used to show content onto the webview.
I just wasted my entire evening on something which I thought would be very simple but it seems WPF and Google are letting me down completely.
I need a grid, 6x6 of which I fill every row and column with a custom control. I want to be able to navigate through this grid via the keyboard (I can get those events, no problem) but I cannot seem to find how I can always have the selected grid row/column in the center of my window.
I found some carousel alike implementations, but most of them only work in a single direction and I want two way navigation, yet none seem to support this nor can I extend them to do this.
I essentially want to create a PSP alike grid navigation.
One easy way is to do this:
Create a scrollable form.
Add a 6x6 grid of child controls.
In the GotFocus (or similar) event for all the controls, set the parent form scroll offset to an appropriate position to centre the child.
This is pretty straight-forward thing to implement, with a little bit of maths to work out how to centre the x,y position of a control by setting the scroll offsets (it can be tricky/confusing, but as long as you understand the coordinate systems used for scrolling, not too bad)
Or, another approach that avoids scrolling via the windows APIs and using custom controls:
Create a form
Override OnPaint to draw your grid of 6x6 "controls" as simple graphical shapes or bitmap images centred on the selected "control".
Handle keyboard (KeyDown/Up) and mouse handling (MouseDown/Up) events to make the 36 areas of the graphic respond to user inputs in the way you desire. You'll have to track the selected item and force the window to redraw its graphics to show the new state. Enable double buffering to stop it flickering.
The first approach gives you a lot of windows-based handling for free (tabbing between controls, remembering where the input focus is, and directing events to separate classes for each "control", for example). The second approach strips away all this "help" but gives you complete control over everything, which can often help avoid unintended behaviours (e.g. it won't move the input focus when the user presses Tab unless you specifically write the code to make it do that).