This fixes regression CORE-16289 where we could not longer
move the taskbar at a different than default location,
as WindowSnap would interfere.
Many Thanks to the patches author Doug Lyons.
Eventually the heuristic that we use here to identify the
taskbar via used window-styles could be improved later.
Theoretically possible that it bails out on some other windows.
The regression was introduced by 0.4.12-dev-373-g
7e396787ed
patch is a backport from master 0.4.13-dev-962-g
4193b8d8ac
as the release data is close and we have to manage the risk.
This reverts last commit and all menu related code back to the state of
0.4.12-dev-369-g
007ec0310c
Although Mark Jansen seems to be on a very promising path in master,
we still revert one last time for this release to the more well known
state we had during 0.4.12dev'ing.
This will fix regressions CORE-16298, CORE-16297
and will keep CORE-15863 in fixed state.
Systray and nested desktop popups do work very well like this.
We therefore intentionally and willingly have to accept the broken
partial-offscreen-menus of CORE-15733.
Those are not as important as the other tickets.
Meanwhile we keep on improving master based on the more recent states.
to fix regression CORE-15863
This is the work that Mark jansen committed into master
0.4.13-dev-791-g
a59df3858c
and
0.4.13-dev-792-g
7c45a646e9
and
0.4.13-dev-793-g
b5c6af459c
squashed into one single commit for 0.4.12RC.
It's not perfect yet anymore for positioning the
popup for systray icons if they contain many entries.
And also not perfect when pressing the context menu key
on desktop after a .lnk has been started,
but overall gives a better user-experience for nested popups
on the desktop, which is much more important.
We can build up on top of it later in master.
to protect our latest improvement of showing correct cpl icons in taskswitch
CORE-16086
This reverts commit
0.4.12-dev-437-g
484943d04f
which was done in context of CORE-15672
(without being able to resolve that ticket)
0.4.12-dev-437 contrasts our latest information c.f. Raymond Chen's article:
http://blogs.msdn.com/b/oldnewthing/archive/2007/10/08/5351207.aspx
Eventually we should select the icon instead using that same algorithm.
to the workaround in last commit 0.4.12-RC-19-g
700779e643
Many thanks to reviewer jimtabor for this very prompt review!
I tested, the new state still succeeds in CORE-15477, CORE-14979, CORE-15599, CORE-15600, CORE-15654
Fixes 'multiple apps leaving the taskbar visible erroneously when switching into fullscreen.'
Please note that the problem with taskbar staying visible is only fixed for some, but not all apps
(see CORE-11242 for some still failing examples, e.g: Bound Around).
We now have the same state in 0.4.12RCs, that we just have committed to master in 0.4.13-dev-247-g
0f29b3faa7
Fixes 'multiple apps leaving the taskbar visible erroneously when switching into fullscreen.'
Please note that the problem with taskbar staying visible is only fixed for some, but not all apps (see CORE-11242 for examples).
This partially reverts commit 09ab5ea7ed (SVN r75407)
I applied this interim solution into 0.4.12RCs for the very first time and rls-tests still
have to prove it being free of obvious side-effects.
Theoretically we could still switch to a better solution at any time.
The workaround never was applied to master to date.
https://reactos.org/testman/compare.php?ids=67536,67539
Resizing a themed window does not longer show a flashing rectangle in the title-bar after the fix.
Still this seems to be work-in-progress even after this first commit, but makes me happy for 0.4.12RCs
for now.
See CORE-7166 & CORE-15934.
cherry picked from commit 0.4.13-dev-8-g
cfdf36e442
By applying for the first time clientFix.patch from CORE-15911 contributed by JIRA-user 'I_Kill_Bugs'.
The patch acts as a better replacement for a workaround of DougLyons from CORE-15429
that aimed to hide the issue for our file-browser only.
The new approach gave good results for the testbots
https://reactos.org/testman/compare.php?ids=66723,66729
but wasn't tested much yet. In case it causes any problems during testing-cycle,
I might eventually switch back to our old workaround instead from the last releases.
There is no need to compile our DLLs as shared libraries since we are
managing symbols exports and imports through spec files.
On my system, this reduces the configure-time by a factor of two.
Import Wine commit:
b1b8fb77be
"user32: Add support for navigating a group of radio buttons using a keyboard.
The patch approximates the behaviour observed in the message tests
but still doesn't make the message tests pass without failures.
"
by Dmitry Timoshkov.
See bug report https://bugs.winehq.org/show_bug.cgi?id=16845
CORE-8526
Import Wine commit:
96d0af52eb
"user32: Move the auto radio button group logic from BM_SETCHECK to WM_LBUTTONUP handler.
This patch also changes the logic to get the control style with WM_GETDLGCODE
instead of GetWindowLong to make the message test pass.
"
by Dmitry Timoshkov.
See bug report https://bugs.winehq.org/show_bug.cgi?id=42010
- (ReactOS-only) Fix also the corresponding logic in COMCTL32.
- Bugcheck VIDEO_DRIVER_INIT_FAILURE in case initializing video fails.
- Bugcheck WIN32K_INIT_OR_RIT_FAILURE (Windows-compatible) in case
the USER subsystem version does not match.
Implemented the following actions: stick the window on the left/right or maximize it,
with the following shortcuts:
- Win key + Arrows;
- drag to left/right screen border;
- double-click on top/bottom.
CORE-12845
Previously, we would just stick the menu on the edge of the screen.
We should actually try to flip the menu around the point of origin,
and only when that fails move it to the edge of the screen.
CORE-15001
CORE-9037
- Add a check in co_UserCreateWindowEx() for parentless windows,
that checks the default layout direction; if it's LAYOUT_RTL
add the WS_EX_LAYOUTRTL flag to the extended window styles.
- Make the internal routine accepting also LAYOUT_LTR as a value for SetProcessDefaultLayout().
Limit receiving value to LAYOUT_ORIENTATIONMASK (and not just LAYOUT_RTL)
or LAYOUT_LTR, as per written in:
https://docs.microsoft.com/en-us/windows/desktop/api/winuser/nf-winuser-setprocessdefaultlayout
Now all the applications that call SetProcessDefaultLayout() to mirror the layout get mirrored.
This is based on Wine.
This change is similar to what is done in UserChangeDisplaySettings()
after changing screen video mode.
This allows e.g. having windows to be correctly maximized during
2nd-stage GUI setup. To compare and reproduce during 2nd-stage GUI
setup, open cmd.exe (Shift-F10) and from there a GUI app, e.g.
regedit.exe, and maximize it. Observe the limits used by the window.
[CMDUTILS/AT] Fix missing translation strings in certain files.
[NOTEPAD] Fix SUBLANG code to brazillian.
[RAPPS] Fix missing translation strings in certain files.
[FDEBUG] Fix translation string ID.
[CPL/INPUT] Fix missing translation strings in certain files.
[ACPPAGE] Fix incorrect resource IDs.
[NETSHELL] Fix incorrect resource IDs.
[DEVMGR] Fix missing translation strings in certain files.
[LSASRV] Fix missing translation strings in certain files.
[RASDLG] Fix missing translation strings in certain files.
[SHELL32] Fix missing translation strings and incorrect resource IDs.
[TAPIUI] Fix missing translation strings in certain files.
[WINFILE] Fix incorrect resource IDs.
[NTVDM] Fix missing translation strings in certain files.
[USERSRV] Fix missing translation strings in certain files.
[BROWSEUI] One more missing string.
[FLTMC] Fix missing translation strings in certain files.
Detected using the TransDiffer tool (early alpha).
This doesn't include everything anymore, but I wanted to get the PR out of the way.
This shouldn't be used only for console applications but can potentially be used by any application to receive shutdown notifications.
MSDN provides more information in the documentation for SetConsoleCtrlHandler. Our services.exe also expect to receive shutdown notifications in this way.
UserClientShutdown will never be called for csrss so we don't need to have a check for that. The existing check was broken and wasn't doing anything anyway.
Handle processing winlogon by doing nothing so that consrv won't be bothered about it.
