Forums Bug Reports Drag drop file on channel nick vs. DCC Send focus

If you drag a file onto a nick in a non-maximized channel window's nicklist to DCC Send it, the DCC Send window takes focus, but then the channel window steals focus back. (I.e., if your non-maximized channel window is sized/oriented so as to occupy the same screen area as the new DCC Send window, that DCC Send window will flicker on-screen and then vanish behind your channel window.)

Same bug, different context: if your channel window is maximized, the same drag drop operation causes the DCC window to briefly appear and then vanish. mIRC should probably open DCC Send windows inactive if it detects that the currently active window is maximized.

Thanks, this was by design - making a window inactive above an active window, especially in an MDI environment, results in a number of side-effects that make window handling problematic.

As the drag-drop feature runs a command which could do anything ie. open multiple windows, not only initiate a dcc send, it is not possible for the drag-drop feature to know what it should do in each particular case where a window is opened. Because of this, it probably should not be restoring focus to the drag-drop window after running the command.

I could change it so that it no longer restores focus to the drag-drop window. However, as mIRC has always done this, changing the behaviour now may result in users reporting the change as a bug.

Technically, at the C++ source code level, can an MDI window be given an "OnTop within mdi" attribute? If that is possible, and if you think hardcoding dragdrop windows to no longer restore focus would upset some users, then here's a way both issues could be solved without upsetting anyone:

Change the command-to-perform syntax from this:

filemask:command

To:

switch:filemask:command

Where "switch" would be documented for users as:


Then, under the hood, here's what would technically happen:


This would solve both reported issues:

n: means dragdrop window lets other windows take focus (dragdrop window becomes neither active nor temporarily ontop_within_mdi)
a: or m: cause the same "restore active" behavior as now, but also with this "dragdrop window temporarily OnTop within MDI" trick, so newly-opened windows won't flicker above the dragdropped window as now

mIRC's installer (for upgrade installations) could add "a:" to existing dragdrop entries to maintain expected behavior for existing users. For new installations, it could add the default entries as m:*.*:/dcc send $1 $2- and a:*.wav:/sound $1 $2-

There is no ontop within MDI setting - such a behaviour would have to be custom coded and managed by mIRC itself. There are no plans to do this as it would very likely create side-effects within MDI which would take many versions to resolve.

I rarely makes changes to an existing format, especially one that has been in use for so long, unless there are compelling reasons to do so. The issue of focus is not important enough to change this format for all existing installations of mIRC, especially since the new format will render it incompatible with all older versions of mIRC.

I think it would be better to leave the behaviour of the drag-drop feature as it is for now.

Yeah, this isn't important enough to justify a hand-made OnTopInMDI customization, and all the side-effects it could cause. My suggestion was based on the assumption (hope) that the possibility already existed.

Anyway, if it will help anyone who finds this thread later while researching the issue, I've solved the "vanishing/flickering DCC window" issues for myself thusly:

*.*:/dcc send $iif($window($active).state == maximized,-m) $1 $2- | if ($window($active).state != maximized) && ($send(0) != 0) .timerdccsendfocus -om 1 1 window -a $+(@,$send($send(0)).wid)