How to add Menu bar items (File, View, etc.)

[Roshan-24]

I'm building a native fabric component for adding menu bar items to my app, similar to react-native-menubar-extra

I'm using Win32 APIs to add HMENU items to my HWND. The part I'm stuck on is keyboard shortcuts for the menu items. Win32 docs state that we need to call TranslateAccelerator(hwnd, haccel, &msg) in a message loop before TranslateMessage/DispatchMessage. But I am not sure where to intercept these messages from inside a fabric component.

And for actually listening to the WM_COMMANDs, is it a proper/best approach to subclass WNDPROC and set it for the HWND obtained from the view's ReactContext?

Or am I using the right approach at all (Win32 APIs, etc.) for adding menu items to my react-native-windows app?

[Nickalus12]

The issue is that standard Win32 message loop interception and WNDPROC subclassing are difficult to manage within the Fabric architecture because the main message loop is owned by the Microsoft.ReactNative framework, and manual subclassing can lead to instability if multiple components attempt it.

Recommended Approach

Instead of manually subclassing the HWND or attempting to modify the message loop, you should use the Pre-Translate Message hook provided by the React Native Windows framework. This allows you to handle accelerators and menu commands in a way that is compatible with the framework's own event handling.

1. Handling Accelerators

To handle TranslateAccelerator, you can register a custom IUwpMessageLoopStrategy or hook into the OnPreTranslateMessage event if you are using a XAML-based host. However, for a Fabric component, the most robust way to intercept messages before they are processed is to use the Microsoft.ReactNative.Composition APIs or standard Win32 hooks via SetWindowsHookEx (WH_GETMESSAGE), though the latter should be a last resort.

2. Subclassing for WM_COMMAND

For listening to WM_COMMAND (which is sent when a menu item is clicked), subclassing is the correct Win32 pattern. In React Native Windows, you should use SetWindowSubclass rather than SetWindowLongPtr to ensure you don't break other internal hooks.

#include <commctrl.h>

// Subclass procedure
LRESULT CALLBACK MenuSubclassProc(HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam, UINT_PTR uIdSubclass, DWORD_PTR dwRefData) {
    switch (uMsg) {
        case WM_COMMAND:
            // Check if the command comes from your menu ID
            if (LOWORD(wParam) == ID_MY_MENU_ITEM) {
                // Trigger your React event here
                return 0;
            }
            break;
        case WM_NCDESTROY:
            RemoveWindowSubclass(hWnd, MenuSubclassProc, uIdSubclass);
            break;
    }
    return DefSubclassProc(hWnd, uMsg, wParam, lParam);
}

// Inside your Fabric Component (where you have access to the HWND)
SetWindowSubclass(hwnd, MenuSubclassProc, 1, reinterpret_cast<DWORD_PTR>(this));

Why use SetWindowSubclass?

Traditional SetWindowLongPtr(..., GWLP_WNDPROC, ...) creates a chain where you must manually manage the previous procedure. If multiple native modules do this, any module that fails to call the previous WNDPROC will break the app. SetWindowSubclass (from Comctl32.lib) handles the chaining safely for you and provides a dwRefData slot to pass your C++ instance pointer.

Important

If your app is a UWP or WinUI 3 based React Native app (the default for new projects), the top-level menu bar is typically handled via XAML MenuBar or CommandBar rather than Win32 HMENU. If you use XAML controls, you get keyboard accelerators (via KeyboardAccelerator) and click events for free without subclassing.

Are you targeting a pure Win32 "Desktop" project template, or are you using the default XAML/WinUI 3 host?