I am working on the touch screen application which is running on Windows XP Standard. With current hardware to invoke a right click user has to click and hold for couple of seconds, but this might interfere with other actions like holding a repeat button in the scrollviewer, so I have decide to disable a right click.
I would ideally wan't to disable a right click on the application level, but if it is not possible, disable right click on windows level would also work for me.
The OnPreviewMouseRightButtonDown/Up approach did not work for me.
There is a property Stylus.IsPressAndHoldEnabled on UIElement however. Set that to false to get rid of the press and hold right click behavior. I tested this on Windows 7 with .NET 4.0, but the property is available from .NET 3.0.
<RepeatButton Stylus.IsPressAndHoldEnabled="false" ... />
There is also a blogpost here that provides a code sample for a similar disabling of press and hold at window level. But with this in place, the PreviewTouchDown and TouchDown events will not be raised as soon as the finger touches the screen (which would be necessary for a RepeatButton I guess), only later. Read the 'Remarks' on this msdn page.
You can override the OnPreviewMouseRightButtonDown on the Window and set Handled to true. You also need to handle OnPreviewMouseRightButtonUp (thanks to Vitalij for pointing this out)
That should do the trick.
Related
We have a WinForms control (inherits Systems.Windows.Forms.Control) with a custom designer attached to it (inherits ControlDesigner). We need to process some mouse events like clicks in a special area inside our control at design time. To indicate that mouse click is available in that area, we need to change the default 4-arrow cursor to something else - at least, to the standard arrow, but we could not find a way to do that.
We redefined the ControlDesigner.GetHitTest method to return true for that special click rectangle, but the cursor simply flashes when it is over the area. It is changed to the default arrow for some milliseconds, and then back to the 4-arrow cursor which implies the whole control can be selected and moved on the form. Overriding ControlDesigner.OnSetCursor does not have any effect as it seems this virtual method is called only when the cursor is changed to the default 4-arrow cursor. Games with WndProc (trying to intercept WM_MOUSE* events) did not get us any positive results too.
Even when we try to implement samples from related books (like the SimpleLineControl from Eric White's "GDI+ Programming-Creating Custom Controls Using C#"), we have the same behavior.
Our dev env is VS2010/.NET 4.0 which is the minimal requirement. How to make it work in this and later environments?
I´ve been working for some time on a good OSK solution for my WPF apps, that are running on a tablet. But it´s hard working with the OSK.exe and tabtip.exe, because of several bugs, strange behaviour and no standardized solution to this ordinary problem.
What I (probably) need is a custom textbox control, which inherits from System.Windows.Controls.TextBox, and overrides some methods.
The simple requirements for this textbox should be:
1. When a user clicks in a textfield, the tabtip.exe (or alike) keyboard should pop up at the bottom of the screen (default).
2. If the keyboard pops up on top of the textbox, the contentframe should scroll so that the textbox is visible.
3. When the textbox loses focus, the keyboard should close automatically, except if the user clicks on another textbox.
This seems like pretty standard behaviour right? Well I´ve looked a long time for solutions (there is no standard microsoft way which is kind of weird), and as said I´ve tried making my own but with no luck. For example, sometimes when I try to kill the process, it fails. When I click the close button in the upperright corner on the keyboard, like 5-6-7 times, it closes. The behaviour from PC to tablet is not consistent. The ScrollViewer.ScrollToVerticalOffset(x); sometimes doesent work on a tablet, and so on.
So does any of you know a good solution to this common problem?
We have a very strange behaviour of a WPF application. Sometimes (not very ofen), some parts of the user interface are simply not painted.
Just recently the save button and a text box on the configuration view didn't show up. Even more strange is that after a relogin, what results in a new view instance, the problem is still present.
Sometimes it helps to hover the mouse over the position where the missing controls usually are to get them visible. But switching the tab page and then back to the original one with the missing controls they are all missing again. Other controls won't show up by hoovering the mouse over them.
Another problem is that dialogs are sometimes screwed up. Parts of the dialog are displaced vertically. But when e.g. a text box inside the dialog gets the focus, it is painted correctly while the rest of the dialog stays displaced.
I don't have the slightest clue what causes this problem. Any idea is welcome.
[Edit 1] So far we have seen this always on Windows XP. Windows 7 seems to be Ok. Also switching to Software-Rendering seems to fix the problem on Windows XP but I'm not sure on this.
The problem was solved by switching the RenderMode to SoftwareOnly. It seems to be a .NET 4 issue when running on Windows XP:
public class MyWindow : Window
{
protected void SetSoftwareRendering()
{
System.Windows.Interop.HwndSource hwndSource = PresentationSource.FromVisual( this ) as System.Windows.Interop.HwndSource;
System.Windows.Interop.HwndTarget hwndTarget = hwndSource.CompositionTarget;
hwndTarget.RenderMode = System.Windows.Interop.RenderMode.SoftwareOnly;
}
}
Alternatively one can write
System.Windows.Media.RenderOptions.ProcessRenderMode = System.Windows.Interop.RenderMode.SoftwareOnly;
All windows are inherited from MyWindow and can decide wether or not they want the software rendering. Currently we don't use this flexibility and have it enabled on all instances.
If this happens in other WPF applications too it might be your hardware, driver, OS or .NET software.
If not, the only option is to try and reproduce in a minimal case and on several machines.
Are you able to make a minimal version that has the problem en post the code?
On Windows XP, it was possible to disable the Start button with the following code:
hTray = FindWindow (TEXT("Shell_TrayWnd"), NULL);
if (hTray)
{
hStartButton = FindWindowEx(hTray, NULL, TEXT("Button"), NULL);
if (hStartButton) ShowWindow(hStartButton, FALSE);
}
For a public-access computer configuration, I need to be able to do this on Windows 7. The Start button must be disabled (not just hidden), and the remainder of the Taskbar must still be visible and usable. Hiding the Taskbar along with the Start button is not an option. Running full-screen is not an option. Using "Start Killer" won't work because it doesn't actually disable the Start button, just hides it (users can still use hotkeys to pull up the Start menu).
I have already tried the method that uses FindWindowEx with 0xC017 as its third parameter and then tries to disable that window. It doesn't work. That method only works if the whole Taskbar is disabled first. What I need is a method that only disables the Start menu, just like the code I reproduced above does in XP.
Any help is greatly appreciated.
The "correct" version for Windows 7 is as shown below:
HWND hStartBtn = FindWindowEx(NULL, NULL, MAKEINTATOM(0xC017), TEXT("Start"));
if (hStartBtn != NULL)
{
ShowWindow(hStartBtn, FALSE);
}
However, this only disables the button, meaning you won't get the glow or other effects by hovering your mouse cursor over it. You can still click the button region on the taskbar to open the menu. Apparently, the click handler is now implemented in the taskbar window itself, not as part of the separate Start button. That's why you have to disable the entire taskbar first, and consequently why most of the solutions you've found online do precisely that.
However, it looks like the "Start Killer" application now has functions to disable the most common hotkeys that trigger the Start menu, namely Ctrl+Esc and the key. You'll find those options by launching the software, right-clicking on its icon in the taskbar, and selecting "Options" from the menu. You can also edit the Registry to disable the Windows key, as described in this knowledge base article. If you wanted to implement this same functionality yourself through code, the only solution would be a low-level keyboard hook that trapped the keypress events that are responsible and discarded them.
Undocumented hacks like this one are given to breaking with newer versions of Windows. I imagine that Raymond Chen would chuckle and say something like "I told you so". Hacking the Windows interface is a fool's errand. Or, as you say several times in the question, "is not an option".
IS there anything in particular about the start menu you need to disable? You may be able to do the same via policy settings or various other file permissions.
Use one of the available group policies listed here.
You did not mention why you want to disable the start button. If you think about what exactly it is that you don't want your users to do instead of telling us the solution you picked for it (i.e., "disable the start button"), you might come up with a much better solution.
For example, if you want to prevent users from changing certain settings, block that, not the start button!
Or if you don't want them to see all the installed apps, hide those apps instead of the start button!
Or...
(I hope you see my point here).
I'm improving standart WPF TabControl. I want to add undocking functionality to it:
user drags the page just outside the TabControl and this page undocks in the window.
I want two events in this control - PageDragStart (raises when the page dragged outside) and PageDragEnd (raises when the page dropped outside)
I've got no problem with the first event.
But the second... OnDrop doesn't call, because the item dropped outside the tabcontol container. How can I know that it was dropped?
P.S. I want a universal control (so, undocking functionality shouldn't be connected and hardcoded with the window tabcontrol is placed or something like this)
Why use DoDragDrop at all? As I was reading your description, using Mouse.Capture by itself seemed the obvious solution:
Handle OnMouseLeftButtonDown on the tab and start capture
Handle OnMouseMove on the tab and update the cursor based on hit testing
Handle OnMouseLeftButtonUp on the tab, and stop the capture and make the appropriate change
The reasons you might ever consider DoDragDrop over simple mouse capture are:
Integration with Windows' OLE drag and drop so you can drag and drop between applications and technologies
Modal nature of DoDragDrop call (which actually seems to be more of a disadvantage to me)
Automated hit testing of targets
Standardized "drop operation" API to allow unrelated applications to handle copy vs move, etc.
You apparently don't need the OLE integration or multi-application support and you want to customize the hit testing, so it seems that DoDragDrop has no advantages over directly handling the mouse capture.
I solved the problem - in rather brutal and unsafe way. But for it's gonna work as the temporary solution.
Well, when I'm raising PageDragStart event, I call Mouse.Capture(this, CaptureMode.SubTree);
When the page is dropped somewhere - DoDragDrop throws different exceptions (COMException, NullReference (I couldn't find which object is null) and some others I don't remember).
I catch exception and call PageDragEnd event (if the property IsPageDraggingOut set to true).
As far as you can see this solution is really dirty and bad. But it works.
So, any other ideas (or some ideas how to work with Mouse.Capture properly)?