Drag and drop with missing firmware blocks everything until firmware window is closed

[Masterjun3]

Drag and drop a ROM that triggers the No BIOS found window into BizHawk.
After this, the "blocking" already starts and is only fixed by clicking No, or clicking Yes and closing the firmware window.

What I mean by "blocking" is being unable to bring the explorer window (source of the drag and drop) to the front, or even doing anything with it.
Other side effects are, for example, being unable to initiate a drag and drop from a 7-Zip window (it errors with "Unspecified error").

[YoshiRulz]

Reproducible with 2.3.1 on Win10. Only the mouse is unable to give focus to Explorer, Alt+TAB works, but it is still unresponsive in that case.

edit: For the record, not even MS can get this right—VS 2019 does the same with a "would you like to save" dialog.

[Asnivor]

Sounds like this should be easy enough to fix.

Although drag-n-drop from a 7zip window - i'd be interested to see a windows application that doesn't complain about this...

[zeromus]

this is how windows works. Everything blocks til the drag is done. If this issue was only about 'no' then I would close this issue right now as "will never, ever fix".
With the firmware dialog opening, the expectations are a little different. I could see this getting fixed.

I don't see how the 7z drag is related at all. It should get blocked same as windows. If it errors, that's a separate bug.

[Masterjun3]

The 7-Zip window was just an example to show that blocking is indeed going on. I'm not dragging anything out of the 7-Zip window into anything like how @Asnivor assumed. I just click on an item in the archive, and as soon as I move my mouse one pixel, it errors (obviously, because drag and drop is blocked).

The problem here is how the whole program flow is linked to that one event that was called
DragDrop -> FormDragDrop -> FormDragDrop_Internal -> _FormDragDrop_internal -> _LoadRom -> LoadRom -> ... -> DoLoadErrorCallback -> OnLoadError -> ShowLoadError -> MessageBox.Show -> FirmwaresMenuItem_Click

[zeromus]

that's not a problem, that's normal. If youve got drag and drop blocked and meanwhile 7zip malfunctions, I don't care. Blocked drag and drop, and whatever consequences, are not our problem. I still say the only consideration here that's important is the firmware manager--if the user chooses that, it needs to be launched by posting a message to the mainform and canceling the drag

[Masterjun3]

This issue isn't about 7-Zip anyways. I never said it was. I never said 7-Zip shouldn't error.

My issue is not being able to properly organize my firmwares when the firmware window blocks my drag and drops.

[vadosnaprimer]

I found this: https://stackoverflow.com/a/480997/2792852

We seem to need to handle QueryContinueDrag and if firmwware manager gets opened, we should force dragdrop to end using DragAction.Cancel. Does that sound right? ROM reload button of the firmware manager doesn't seem to need dragdrop to continue.

[zeromus]

no. we need to launch the firmware manager by posting a message to the mainform and immediately return from the drag event

[vadosnaprimer]

In any case, the workaround that I personally use is selecting No in the dialog that suggests to open firmware manager, and then pointing to firmware folder in Paths config. Then all the firmwares get fetched automatically.