Suggestion
I experimented with windows-reactor to try and rebuild my photo pipeline app with the Windows look and feel.
The first step in my pipeline is having the user select the directories and files to be the inputs.
To make this holistic, I wanted to add drag-and-drop functionality from windows explorer to my app.
This was ultimately possible through intrusive modifications to the reactor code which I vendored into my project.
It would be great if the upstream reactor development made this a bit easier.
Apologies if this has been added in the past few days, I may have been working on a stale version.
Earlier version: drag and drop worked but no visual response and cursor had wrong appearance
Later version: the app and cursor clearly communicate drag and drop enthusiasm
Here is my source code and an agent summary in case it helps.
https://github.com/TeamDman/cm/tree/8782b1ebb4f857176ebc0a9e9e2608c2149b3407/vendor
https://github.com/TeamDman/cm/tree/8782b1ebb4f857176ebc0a9e9e2608c2149b3407/src/reactor
We got Explorer file drag/drop working, but it required host/runtime changes rather than just app code.
The main issue was that wiring a simple drop callback was not enough: the top-level window, child HWNDs, and WinUI content all needed to agree that the client area was a valid drop target. Until we handled that, drag feedback would work on window chrome / edges but fall back to “no drop” over the actual app body.
What we ended up needing:
- host-level drop and hover callbacks
WM_DROPFILES / DragAcceptFiles- OLE
RegisterDragDrop with an IDropTarget implementation
- registration across the root HWND and child HWNDs
- propagating
AllowDrop onto WinUI UIElements, including newly created controls
IDropTargetHelper for proper Explorer drag image / drop effect behavior- a small delayed hover clear to smooth flicker between child HWND handoffs
Once that existed, the app-side integration was small: install handlers, merge dropped paths into the current set, and update hover UI.
So the short version is: file drag/drop seems like it really wants to be a first-class upstream Reactor feature, because getting it to feel correct required coordinated changes in the Win32 host, OLE drag/drop layer, and WinUI backend.
Some more AI conversation in case it helps
Teamy:
The drop effect is still not working when we're hovering the content area of the window. It works when I'm at the edge of the window, as if I wanted to resize it, and it works when I'm in the title area of the window, like the decorations for minimize, maximize, and the text, but it does not work when I'm in like the burger menu, like when I'm hovering the burger menu or the light or dark mode button or the content area of the app, so like when I'm in the body area. So we still need to fix that, but I do like the big text that shows up indicating that I can drop there, so we still have something to fix for meaning.
GPT5.4:
I pushed the next fix in vendor/windows-reactor/src/winui/host.rs: file-drop registration is no longer limited to the top-level window. The host now enumerates the root HWND plus its child HWNDs and applies DragAcceptFiles, the subclass hook, and OLE RegisterDragDrop across that whole tree. That matches the symptom you described much better, because the body area and custom title-bar controls are very likely living on child window handles.
Please close the running app, relaunch with run.bat, and retest the drag-over cursor specifically in the burger button, theme button, and content body. If it’s still wrong after this, the next step is the heavier one: explicit routed WinUI DragEnter / DragOver handlers inside the vendored bindings.
Teamy:
Okay, that's much better. It now does properly show the hover effect when I have the files dragging over the window. However, there is a flicker where for a frame transitioning between the edge area and like the window chrome area into the body area, that there's one frame where it thinks there's no hover, so it does a flicker because as you drag the file, you transition past the border of the window, so it shows the hover effect when you get to the border area. Then as you transition to the content area, there's a flicker of no hover. So it's very flickery, so if we could find and fix the root cause of that, that would be great. Otherwise, we could probably do a timing thing where for 50 milliseconds or whatever, the hover effect won't expire even if it thinks it's not being hovered or whatever, just to quick hack it, but it would be much better to fix the root cause to avoid that one frame of not working.
GPT5.4:
I smoothed the hover transition in the shared drop host at vendor/windows-reactor/src/winui/host.rs.
What’s happening is that moving between registered child HWNDs can produce a DragLeave on one handle just before the DragEnter on the next. Rather than letting that false handoff clear the app hover state immediately, the host now delays hover-clear by 50ms and cancels it as soon as the next valid drag-over arrives. So the real registration fix stays in place, and only the one-frame handoff blip gets absorbed.
As an aside, there was sometimes the feeling of the scrolling in the list view being a bit laggy where it felt like there was a delay between the scroll event and the apps response, once it was moving it was good until it came to rest then the next movement would have a bit of a delay. I don't have enough evidence or reproducibility to make its own issue for it, but I figured I'd mention it.
Suggestion
I experimented with windows-reactor to try and rebuild my photo pipeline app with the Windows look and feel.
The first step in my pipeline is having the user select the directories and files to be the inputs.
To make this holistic, I wanted to add drag-and-drop functionality from windows explorer to my app.
This was ultimately possible through intrusive modifications to the reactor code which I vendored into my project.
It would be great if the upstream reactor development made this a bit easier.
Apologies if this has been added in the past few days, I may have been working on a stale version.
Earlier version: drag and drop worked but no visual response and cursor had wrong appearance
Later version: the app and cursor clearly communicate drag and drop enthusiasm
Here is my source code and an agent summary in case it helps.
https://github.com/TeamDman/cm/tree/8782b1ebb4f857176ebc0a9e9e2608c2149b3407/vendor
https://github.com/TeamDman/cm/tree/8782b1ebb4f857176ebc0a9e9e2608c2149b3407/src/reactor
We got Explorer file drag/drop working, but it required host/runtime changes rather than just app code.
The main issue was that wiring a simple drop callback was not enough: the top-level window, child HWNDs, and WinUI content all needed to agree that the client area was a valid drop target. Until we handled that, drag feedback would work on window chrome / edges but fall back to “no drop” over the actual app body.
What we ended up needing:
WM_DROPFILES/DragAcceptFilesRegisterDragDropwith anIDropTargetimplementationAllowDroponto WinUIUIElements, including newly created controlsIDropTargetHelperfor proper Explorer drag image / drop effect behaviorOnce that existed, the app-side integration was small: install handlers, merge dropped paths into the current set, and update hover UI.
So the short version is: file drag/drop seems like it really wants to be a first-class upstream Reactor feature, because getting it to feel correct required coordinated changes in the Win32 host, OLE drag/drop layer, and WinUI backend.
Some more AI conversation in case it helps
Teamy:
The drop effect is still not working when we're hovering the content area of the window. It works when I'm at the edge of the window, as if I wanted to resize it, and it works when I'm in the title area of the window, like the decorations for minimize, maximize, and the text, but it does not work when I'm in like the burger menu, like when I'm hovering the burger menu or the light or dark mode button or the content area of the app, so like when I'm in the body area. So we still need to fix that, but I do like the big text that shows up indicating that I can drop there, so we still have something to fix for meaning.
GPT5.4:
I pushed the next fix in vendor/windows-reactor/src/winui/host.rs: file-drop registration is no longer limited to the top-level window. The host now enumerates the root HWND plus its child HWNDs and applies
DragAcceptFiles, the subclass hook, and OLERegisterDragDropacross that whole tree. That matches the symptom you described much better, because the body area and custom title-bar controls are very likely living on child window handles.Please close the running app, relaunch with run.bat, and retest the drag-over cursor specifically in the burger button, theme button, and content body. If it’s still wrong after this, the next step is the heavier one: explicit routed WinUI
DragEnter/DragOverhandlers inside the vendored bindings.Teamy:
Okay, that's much better. It now does properly show the hover effect when I have the files dragging over the window. However, there is a flicker where for a frame transitioning between the edge area and like the window chrome area into the body area, that there's one frame where it thinks there's no hover, so it does a flicker because as you drag the file, you transition past the border of the window, so it shows the hover effect when you get to the border area. Then as you transition to the content area, there's a flicker of no hover. So it's very flickery, so if we could find and fix the root cause of that, that would be great. Otherwise, we could probably do a timing thing where for 50 milliseconds or whatever, the hover effect won't expire even if it thinks it's not being hovered or whatever, just to quick hack it, but it would be much better to fix the root cause to avoid that one frame of not working.
GPT5.4:
I smoothed the hover transition in the shared drop host at vendor/windows-reactor/src/winui/host.rs.
What’s happening is that moving between registered child HWNDs can produce a
DragLeaveon one handle just before theDragEnteron the next. Rather than letting that false handoff clear the app hover state immediately, the host now delays hover-clear by50msand cancels it as soon as the next valid drag-over arrives. So the real registration fix stays in place, and only the one-frame handoff blip gets absorbed.As an aside, there was sometimes the feeling of the scrolling in the list view being a bit laggy where it felt like there was a delay between the scroll event and the apps response, once it was moving it was good until it came to rest then the next movement would have a bit of a delay. I don't have enough evidence or reproducibility to make its own issue for it, but I figured I'd mention it.