How to get notified for mouse wheel interaction for MacCatalyst and windows at MAUI platform.
Answer 1: Scrolling.
What do you want to do based on mouse wheel interaction? If you simply want to scroll, or know when scrolling has occurred, then you can rely on ScrollView, and other views that handle scrolling themselves. E.g. ScrollView.Scrolled event.
Answer 2: General use of mouse scroll wheel.
Input functionality for mouse or keyboard has not yet been implemented in MAUI. Nor has a specification been finalized.
Here is one mouse proposal.
You could add a comment to that proposal requesting that mouse wheel support be included.
However, this might not be in the first release of MAUI, as the current emphasis is on stabilizing the functionality that is needed on all platforms (including mobile), some of which don't have mice.
In case anyone is wondering "shouldn't this be specified in .net 6?" (And then MAUI would simply use it.)
There are interactions between what is happening on the display (views or windows) and how mouse/keyboard input should be handled - it makes sense to put that input in the same code base that is displaying to the screen - therefore MAUI is a good place for it.
Especially given that touch is part of MAUI.
Until then, the solution is to make a DependencyService on each platform, to refer to the platform's APIs that you need.
Surprisingly, I'm not finding one that anyone has done for mouse on Windows and Mac.
Other than "implicitly", since a mouse can be used similar to a touch device. And text can be typed on a keyboard. The point is that there is no API specific to functionality that only makes sense if you have a physical mouse (scroll wheel) or a physical keyboard (global keyboard hooks).
TBD I'll look into this further.
Basic approach would be to look at what WinUI 3 uses as input APIs.
On Windows Desktop app, forward to those input APIs. Write an adapter on other platforms (Mac, Linux).
I'll see if Uno Platform or Avalonia have taken this approach.
Windows 8.1 introduced the ability to have different DPI settings for different monitors. This feature is known as "per-monitor high-DPI support." It persists and has been further refined in Windows 10.
If an application does not opt in (i.e., is either DPI-unaware or high-DPI aware), it will be automatically scaled up by DWM to the proper DPI. Most applications fall into one of these two categories, including most of the utilities bundled with Windows (e.g., Notepad). On my test system, the high-DPI monitor is set to 150% scale (144 DPI), while the normal monitor is set to the system DPI (100% scale, 96 DPI). Therefore, when you open one of these applications on the high-DPI screen (or drag it over there), virtualization kicks in, magnifying everything, but also making it incredibly blurry.
On the other hand, if an application explicitly indicates that it supports per-monitor high-DPI, then no virtualization is performed and the developer is responsible for scaling. Microsoft has a fairly comprehensive explanation here*, but for the benefit of a self-contained question, I'll summarize. First, you indicate support by setting <dpiAware>True/PM</dpiAware> in the manifest. This opts you into receiving WM_DPICHANGED messages, which tells you both the new DPI setting as well as a suggested new size and position for your window. It also allows you to call the GetDpiForMonitor function and obtain the actual DPI, without being lied to for compatibility reasons. Kenny Kerr has also written up a comprehensive tutorial.
I've gotten all of this going successfully in a little C++ test app. It's a lot of boilerplate and mostly project settings, so I don't see much point in posting a full example here. If you want to test it out, either follow Kenny's instructions, this tutorial on MSDN, or download the official SDK sample. Now, the text in the client area looks good (because of my handling of WM_DPICHANGED), but because virtualization is no longer performed, there is no scaling of the non-client area. The result is that the title/caption bar and the menu bar are the wrong size—they do not get larger on the high-DPI screen:
So the question is, how do I get the non-client area of the window to scale to the new DPI?
It doesn't matter whether you create your own window class or use a dialog—they have identical behavior in this respect.
It has been suggested that there is no answer—that your only choice is to custom draw the entire window, including the non-client area. While this is certainly possible, and indeed what UWP apps (those previously known as Metro) do, like the Windows 10 Calculator, it is not a workable option for desktop applications that use many non-client widgets and hope to look native.
Aside from that, it is demonstrably false. Custom-drawn title bars cannot be the only way of getting the correct behavior, since the Windows shell team has done it. The humble Run dialog behaves exactly as expected, properly resizing both the client and non-client areas as you drag it between monitors with different DPIs:
Investigation with Spy++ confirms this is just a bog-standard Win32 dialog—nothing fancy. All of the controls are standard Win32 SDK controls. It is not a UWP app, nor have they custom-drawn the title bar—it still has the WS_CAPTION style. It is launched by the explorer.exe process, which is marked as per-monitor high-DPI aware (verified with Process Explorer and GetProcessDpiAwareness). This blog post confirms that both the Run dialog and the Command Prompt have been rewritten in Windows 10 to scale correctly (see "Command shells et al."). What is the Run dialog doing to resize its title bar?
The Common Item Dialog API, responsible for new-style Open and Save dialogs, also scales correctly when launched from a process that is per-monitor high-DPI aware, as you can see when clicking the "Browse" button from the Run dialog. Same thing for the Task Dialog API, creating the odd situation where an app launches a dialog box with a different-size title bar. (The legacy MessageBox API has not been updated, however, and exhibits the same behavior as my test app.)
If the shell team is doing it, it has to be possible. I just cannot imagine that the team responsible for designing/implementing per-monitor DPI support neglected to provide a reasonable way for developers to produce compatible applications. Features like this require developer support, or they are broken out-of-the-box. Even WPF applications are broken—Microsoft's Per-Monitor Aware WPF Sample project fails to scale the non-client area, resulting in a title bar that is the wrong size. I'm not much for conspiracy theories, but this smells of a marketing move to discourage desktop app development. If so, and there is no official way, I'll accept answers that rely on undocumented behavior.
Speaking of undocumented behavior, logging window messages when the Run dialog is dragged between monitors with different DPI settings shows that it receives an undocumented message, 0x02E1. This is somewhat interesting because this message ID is exactly one greater than the documented WM_DPICHANGED message (0x02E0). My test app never gets this message, though, regardless of its DPI-awareness settings. (Curiously, close inspection does reveal that Windows slightly increases the size of the minimize/maximize/close glyphs on the title bar as the window moves onto the high-DPI monitor. They're still not as big as they are when they are virtualized, but they're slightly bigger than the glyphs that it uses for unscaled system-DPI applications.)
So far, my best idea has been to handle the WM_NCCALCSIZE message to adjust the size of the non-client area. By using the SWP_FRAMECHANGED flag with the SetWindowPos function, I can force the window to resize and redraw its non-client area in response to WM_DPICHANGED. This works fine to reduce the height of the title bar, or even remove it altogether, but it will never make it any taller. The caption seems to peak out at the height determined by the system DPI. Even if it worked, this wouldn't be the ideal solution, because it wouldn't help with the system-drawn menu bar or scroll bars…but at least it would be a start. Other ideas?
* I know that this article says "Note that the non-client area of a per monitor–DPI aware application is not scaled by Windows, and will appear proportionately smaller on a high DPI display." See above for why that is (1) wrong and (2) unsatisfactory. I'm looking for a workaround other than custom-drawing the non-client area.
In any up-to-date Windows Insider builds (build >= 14342, SDK version# >= 14332) there is an EnableNonClientDpiScaling API (which takes an HWND as its argument) that will enable non-client DPI scaling for top-level HWNDs. This functionality requires that the top-level window be running in per-monitor DPI-awareness mode. This API should be called from the WM_NCCREATE handler for the window. When this API is called on a top-level window, its caption bar, top-level scrollbars, system menu and menubar will DPI scale when the application’s DPI changes (this can happen when the app is moved to a display with a different display scaling value or when the DPI changes for other reasons such as the user making a settings change or when an RDP connection changes the scale factor).
This API does not support scaling non-client area for child windows, such as scroll bars in a child window.
To my knowledge there is no way to have non-client area DPI scale automatically without this API.
Note that this API has not yet been finalized, and it may change prior to being released in the Windows 10 Anniversary update. Keep your eye on MSDN for official documentation when it becomes final.
With Per Monitor V2 DPI awareness in Windows 10 Creators Update (build 15063) you can resolve this easily without the EnableNonClientDpiScaling.
To enable Per Monitor V2 DPI awareness, while still supporting old Per Monitor DPI awareness on older Windows 10 builds and Windows 8.1 and DPI awareness on yet older versions of Windows, make your application manifest like this:
<assembly ...>
<!-- ... --->
<asmv3:application>
<asmv3:windowsSettings xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">
<dpiAware>True/PM</dpiAware>
<dpiAwareness xmlns="http://schemas.microsoft.com/SMI/2016/WindowsSettings">PerMonitorV2,PerMonitor</dpiAwareness>
</asmv3:windowsSettings>
</asmv3:application>
</assembly>
References:
High DPI Improvements for Desktop App Developers in the Windows 10 Creators Update – video (archived)
Application Manifests – reference
High DPI Desktop Application Development on Windows – documentation
Note that in WinForms targeting .NET 4.7 and later, you can achieve the same by adding
<add key="DpiAwareness" value="PerMonitorV2" />
to <System.Windows.Forms.ApplicationConfigurationSection> tag in app.config. I assume that in the end, this change modifies the manifest in the target binary as described above.
I've been working on a DirectX WP8 app that needs to be able to recognize gesture like taps, pinches, and three finger pans. unfortunately, it looks like there is no prebuild gesture recognizer out there [1] (I'm hoping I'm wrong), so I made my own.
The problem is, my custom build gesture recognizer has more bugs than a bag of old flour. My application has been feature complete for a while and ironing out the bugs in my recognizer is the biggest problem keeping me from releasing.
I'm currently working on writing some good functional tests to expose as many bugs as I can, but it would be even better if there was an already made gesture recognizer out there that I could use. It's kind of surprising that there isn't since it seems like a common thing that folks would want.
Thanks for your time; I appreciate any and all leads.
-Nico
[1] However, there is one for big Windows (http://msdn.microsoft.com/en-us/library/windows/apps/windows.ui.input.gesturerecognizer.aspx) but it's not supported for Windows Phone.
Here is a post about gesture in windows phone written by a friend of mine. He is using windows phone toolkit. Despite the blog is written in Indonesian language, there is a quick explanation poster in english about touch gesture and a downloadable sample app code. (Dont worry about the langauage, the writer did not explain much in the blog though)
It doesn't look like there's anything like this.
So I'll open source my gesture recognizer once I polish it up :)
I've been searching a long time ago for a manner to enhance and skin the no-client area in windows, and many people say that there are only two ways, either you make a frame-less window and draw my own buttons or by hooking windows message like WM_PAINT, and I'm interested in the second approach, so is there anyway to achieve that because the big problem is that I'm using Qt, and maybe this photo will help emphasizing the problem.
What you're looking for is Non-client painting. Windows has a number of messages for handling the non-client area. Doing some web searches for 'QT Non-client paint' results in this thread, which gives a brief example of how to do non-client painting in QT.
Adobe Brackets (specifically the CEF wrapper source code, found here: https://github.com/adobe/brackets-shell/) provides source code for non-client painting; Spotify shares this code (see credits). I do not have experience with doing this in Qt; I tinkered with a 64-bit port of brackets-shell but didn't finish as I started playing with Electron. It's Windows specific, so maybe you could use Win32 API directly to wrap the Qt window's WndProc and implement that way?
I'm looking at doing a project that would target Internet Explorer 10 using a touch screen. I don't currently have a touch screen handy, but need to know if Internet Explorer 10 does or will support DOM touch events.
Update: Touch Events are in development in Internet Explorer.
While IE10 will not support the touchstart and touchend type of events, it will support an arguably superior model consisting of Pointers. These generic pointers capture input from pens, mice, and fingers. A great primer was given in the post Touch Input for IE10 and Metro style Apps, dated Sept, 2011.
You should be able to get the older touch model to work well with the MSPointer model with just abit of feature-detection and clever-scripting:
var elm = document.getElementById("#foo"),
evt = window.navigator.msPointerEnabled ? "MSPointerDown" : "touchstart";
elm.addEventListener(evt, handler, false);
More on Pointer and Gesture events can be found here: http://msdn.microsoft.com/en-US/library/ie/hh673557.aspx
Important Developments
The W3C has formed a Working Group based on Microsoft's Pointer model.
Hand.js: a polyfill for supporting pointer events on every browser
It appears IE 10 doesn't support the 'touchstart' family of events used by iOS and other mobile browsers. IE 10 does however support multi-touch events using their own 'MSPointer' events. See http://msdn.microsoft.com/en-us/ie/hh272903#_DOMTouch for details and example sites like http://ie.microsoft.com/testdrive/Graphics/TouchEffects.