mirror of
https://github.com/reactos/web-content.git
synced 2025-05-19 13:35:59 +00:00
45d33cf1ba
That way they really work as on our old website, otherwise it was reactos.org/project-news/node/295 and not reactos.org/node/295
9 lines
3.6 KiB
HTML
9 lines
3.6 KiB
HTML
---
|
||
title: "Menus, menus"
|
||
author: "gigaherz"
|
||
date: 2014-03-16
|
||
aliases: [ "/node/795" ]
|
||
---
|
||
|
||
<p>I began the week by fixing the menus, so that they would properly display submenus, and react to clicks. I was stuck for a bit, but I finally managed to find the problem that prevented the menus from working correctly within ReactOS.</p><p>I set the filebrowser aside for a bit after this small success, to revisit some of the old bugs and pending tasks.</p><p>I took a fresher look at the exec issue, where items weren’t clickable unless a submenu had been opened first, and I (painfully) traced the issue to pointless/bogus WM_ACTIVATE messages, with the new HWND being equal to the old HWND. Since the messages were telling the menu it was going to deactivate, but the new windows that was activating in its place was the menu itself, this confused the menu into closing, instead of processing the click.</p><p>While fixing the issue is beyond my current knowledge of the ReactOS internals, I placed a small workaround that ignores those bogus messages. Items now work as expected, regardless of the submenus having been opened.</p><p>I dedicated some time to installing a working Linux virtual machine, based on Xubuntu, so that I could apply some changes to the Wine source, and send patches to the Wine project. After spending quite a lot more time than I wanted trying to convince Linux to do what I wanted, I managed to get Wine to compile with nearly all of the requested packages installed, and I managed to run the test programs for the involved components, before and after my patches. The resulting changes were sent to Wine, and were accepted later in the week.</p><p>I went back to fixing outstanding bugs, and took a new look at the issue where icons did not draw the first time the menu was shown. I traced the issue to SHGetImageList, which was wrongly duplicating the system ImageList before returning the pointer to the application. Because the icons were added AFTER the code that requested the ImageList, this resulted in the first instance of the ImageList not having the icons included. Removing the duplication and returning the raw pointer to the system image list fixed the issue. The tests confirmed that Windows does return the same pointer in SHGetImageList as in Shell_GetImageLists, which is known to return the global, unsafe, image list pointers.</p><p>I continued by adding some tweaks and fixes to the start menu and the filebrowser menu, but then I went back to another outstanding bug: the keyboard navigation. I already had the suspicion that it was related to the focus manager, but I did not know how. I finally deduced that the issue was caused by the fact that the parent menu wasn’t aware of when the child menu was opening/closing, only when it was created.</p><p>I refactored the menu and the focus manager to fix the issue, and while I was at it, I also improved the behaviour of hot-tracking across different level menus. This required adding a new feature to the focus manager, where it also Captures the input, so that using the keyboard would prevent the mouse from resetting the hot item, while still allowing mouse movements from resuming the mouse-based hot-tracking. This new Capture-based tracking has added some issues to the filebrowser menus, which I plan on fixing this coming week.</p><p>I know you all love screenshots, but sadly there isn't much to show, since the progress has been mostly in the "feel" side of the look&feel goal. It's not much, but this is what I have right now:</p><p><img alt="Image" class="imgp_img" src="/sites/default/files/imagepicker/2924/ReactOS-2014-03-11-11-31-22.png" style="width: 1024px; height: 819px;"></p>
|