Also replace integer with bool in Ghost API when only used as boolean,
and uint8* with char* in Ghost API when variable is a string.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D11617
Signed-off-by: Nicholas Rishel <rishel.nick@gmail.com>
In the Win32 platform our setTitle() can properly assign a Unicode
utf-8 window title. Unfortunately our getTitle() will only read regular
8-bit character strings. This means that we can never compare what we
set to what we get. This patch updates getTitle() to use Unicode-aware
GetWindowTextLengthW and GetWindowTextW.
see T88909 for an example of this affecting user experience.
Differential Revision: https://developer.blender.org/D11782
Reviewed by Ray Molenkamp
When using multiple monitors that differ in scale and/or dpi, the
varying sizes of the window titles and borders can cause the placement
of those windows to be out by a small amount. This patch adjusts for
those differences on Windows 10 and newer.
see D10863 for details and examples.
Differential Revision: https://developer.blender.org/D10863
Reviewed by Ray Molenkamp
This is just some cleanup of the Win32 window creation code. After
CreateWindowExW() this patch uses some early exits to replace some
potentially confusing if blocks. No functional changes.
Differential Revision: https://developer.blender.org/D11446
Reviewed by Ray Molenkamp
For 2.93 we bumped the minimum windows requirement
to windows 8.1, but did not do any clean-up of any
win 8/8.1 API usage we dynamically accessed though
LoadLibrary/GetProcAddress.
This patch bumps _WIN32_WINNT to 0x0603 (win 8.1)
and cleans up any API use that was accessed in a
more convoluted way than necessary
Differential Revision: https://developer.blender.org/D11331
Reviewed by: harley, nicholas_rishel
Do not allow a window to be created that has a top position that
can obscure all or part of title bar. Right and Left edges can
still be specified slightly outside of monitor bounds, but top
edge must be clamped to monitor top.
see D11371 for more details.
https://developer.blender.org/D11371
Reviewed by Ray Molenkamp
When creating Win32 windows, the sizes and placements can be out by a
small amount, mostly noticeable near monitor edges. This is because
Windows 10 includes a thin invisible border (typically 7 pixels) when
determining position. Therefore the correct values can sometimes be
just outside the monitor bounds, but we clamp them at those bounds.
This patch fixes this by first clamping the requested values to monitor
bounds, adjusting for window chrome with AdjustWindowRectEx(), and then
using those adjusted values in CreateWindowExW().
see D11314 for more details.
Differential Revision: https://developer.blender.org/D11314
Reviewed by Ray Molenkamp
Changing window state using taskbar system menu could result in a titleless window.
Differential Revision: https://developer.blender.org/D10812
Reviewed by Ray Molenkamp
If window is maximized when toggling fullscreen, go back to maximized when done.
Differential Revision: https://developer.blender.org/D10813
Reviewed by Harley Acheson
When the window is already maximized allow covering Windows Taskbar when toggling fullscreen.
Differential Revision: https://developer.blender.org/D10811
Reviewed by Harley Acheson
SetWindowPos must be called after SetWindowLongPtr in order to see changes to window frame style.
Differential Revision: https://developer.blender.org/D10756
Reviewed by Ray Molenkamp
Because of D10469 we can now not force child windows onto parent's monitor and allow them to go where they wish.
Differential Revision: https://developer.blender.org/D10593
Reviewed by Ray Molenkamp
Remove the setting of Dialog window styles until we confirm expected behavior between platforms.
Differential Revision: https://developer.blender.org/D10470
Own Code
Improvements to how window states are determined and changed.
Differential Revision: https://developer.blender.org/D10470
Reviewed by Brecht Van Lommel
This revert removes handling of cursor move and button press events
during Wintab's WT_PACKET event, instead storing pressure and tilt
information to be combined with Window's WM_MOUSEMOVE events.
This also reverts dynamic enabling and disabling of Wintab, dependent
on the chosen Tablet API. If the Tablet API is not explictly Windows
Ink during startup, Wintab is loaded and enabled.
Left in place is a fallback to Windows Ink when the Tablet API is set
to Automatic and no Wintab devices are present. This allows devices
with Wintab installed but not active to fallback to Windows Ink.
Using position provided by Wintab was found to have too many
regressions to include in Blender 2.93. The primary source of
regressions was tablets which mapped coordinates incorrectly on multi-
monitor and scaled displays. This resulted in an offset between what
the driver controlled Win32 cursor position and the Wintab reported
position. A special case of this included tablets set to mouse mode,
where Wintab reported absolute position while the system cursor moved
as a relative mouse with mouse acceleration.
Removal of Win32 code that allows background windows to receive raw input.
Differential Revision: https://developer.blender.org/D10408
Reviewed by Brecht Van Lommel
Simplification of Win32 GHOST_WindowWin32 with improved support for owned windows.
Differential Revision: https://developer.blender.org/D9971
Reviewed by Brecht Van Lommel
Multiple Wintab tablets do not send relative button state when
configured to do so. This causes button events to be delayed until
processed as Win32 button events.
This commit fixes the issue by configuring Wintab to use absolute
button state and tracking changes manually.
Previously Wintab packets were added to a local queue to be processed
during Win32 mouse events, in order to correlate Wintab to Win32
mouse buttons. Wintab packets before Win32 mouse down events were
expired on a timer.
This commit drives mouse events during Wintab events when a device is
in range. When a Wintab button is found it is dispatched if an
equivalent event can be popped from the Win32 event queue. If a Win32
mouse button event is not associated with a Wintab event, it falls
through to WM_BUTTON handling. All Wintab packets are handled as they
are received.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D9908
Time is synchronized by the difference between the WT_PACKET receive
time and the last received PACKET's pkTime. This is used to prevent
Wintab packets from being prematurely expired.
the issue with Wintab button events are more significant than simply
setting what buttons should receive button up/down events during context
initialization.
Signed-off-by: Nicholas Rishel <rishel.nick@gmail.com>
handling mouse input. This Wintab to mouse synchronization issues, and
likely prevents queue exhaustion for some Wintab implmenetations.
Signed-off-by: Nicholas Rishel <rishel.nick@gmail.com>
window intitialization can specify whether it will be visible regardless
of whether it is yet visible.
Signed-off-by: Nicholas Rishel <rishel.nick@gmail.com>
Now Wintab is not initialized when starting Blender with the tablet API
preference set to native, since that disables Windows Ink.
Note that changing the tablet API requires restarting Blender for changes
to take effect. This serves as a stopgap to allow use of Windows Ink until
runtime API switching is merged.
Differential Revision: https://developer.blender.org/D9051
This reverts commit 1a3928f33c and 1a3928f3. This is not working stable
with some Wintab implementations, so reverting for now. This leaves only
the Windows Ink changes for 2.83.
Some Wintab drivers report a zero length queue, this causes an unplanned never ending loop.
Differential Revision: https://developer.blender.org/D7392
Reviewed by: Ray Molenkamp
