if i have a dialog open and i have say an F4 alias and i press the F4 button whilst the dialog is open and the active window the alias will not execute. it should be fixed

It's not a bug, rather a features request, nice idea

Hi

Why is it not a bug? mIRC is the active application and the alias should run when i call it. For some reason when a dialog is open the alias does not run, but it will run when a window is opened using /window @window. I call that inconsistency.

I wanted to use it so i could switch through dialogs, i don't have mIRC installed but here is one example i would have used it for, please forgive code errors as i do not have the help file handy, but the message should be clear



My point is i can access all my dialogs with one press of a key and scroll through them at ease. But i cannot as i cannot call an alias using an F key when a dialog is the active window.

"mIRC is the active application and the alias should run when i call it."

To me, it seems like the open dialog is the active window.. (despite what mIRC's identifiers return).

As was mentioned, this would be a good feature suggestion. Maybe an addition to the onDIALOG event would be better than using the existing ALIAS F4 syntax. That way dialog designers could have complete control over F* buttons within their dialogs without having existing F* aliases interfering. Possible syntax:

on *:DIALOG:test:FKEY:F4: echo -s F4 pressed
on *:DIALOG:test:FKEY:sF4:echo -s Shift+F4 pressed
on *:DIALOG:test:FKEY:cF4:echo -s Ctrl+F4 pressed

Each dialog has its own set of onDIALOG events, so each dialog could have its own F* key actions. And if no F* event is specified for the active dialog, maybe the default F* aliases could be used instead.

-genius_at_work

That's a great idea.

You can call it inconsistent but that doesn't really make it a bug in itself. There are tons of inconsistencies in mIRC, but done so knowingly, sometimes intentionally, for purpose. In this case, the reason it's not a bug is not incorrect implementation but rather the lack thereof. mIRC doesn't handle fkeys in dialog windows-- no one ever requested such a functionality (you should), so this can't be "fixed" without being implemented in the first place.

Anyway, technicalities aside, there are dlls that can do this easily for the time being. I wrote one called "keyhook.dll" which allows you to make global hotkeys from mIRC. It took all of 10 minutes and I can post the source if you're interested because I noticed it isn't packaged with the DLL.

Naw, thats def a bug, like the op said if it was a @window would you say its not a bug? like @window a dialog should run when called in mirc and a dialog is in mirc just like @window is ;-)

A dialog is a separate window than mIRC. @windows are within the mIRC main window.

-genius_at_work

Minimize your mIRC, and you'll see the @windows float on top, just like dialogs.

----

@windows are in fact, a type of a dialog.
the fact it doesn't look like a "regular" dialog, doesn't mean it's not.

See, they also have the minimize and exit buttons, and a titlebar, just like all dialogs.

They're just a big dialog, with one big list, and an edit box in them.

No, they are not dialogs. Just because you can make it look similar to a dialog doesn't make it a dialog. A channel also has "minimize and exit buttons, and a titlebar, just like all dialogs". That doesn't make channels dialogs, does it?

A custom window is just that... a custom window. It is treated as any other window within mIRC (even if it's a desktop window). A dialog is not treated as a window, but as a dialog. That is where the difference is.

As was already mentioned, this is not a bug, but a feature request.

technically, it's a dialog.

mIRC may not consider it as a dialog, but according to the windows operating system, that window is a dialog.

notice how window themes effect it?

Channel windows are dialogs also.

This is totally off-topic now but no, that's simply not true. If anything it's the other way around, mIRC's dialogs are actually windows, as are all controls in the Windows API. But that's completely irrelevant, the concept of two distinct types of frames -- dialogs and windows -- is prevalent throughout GUI design and it's pointless saying that they're fundamentally the same underneath.

But trying to put this thread back on topic: Does it matter if dialogs are different from custom windows? No. Does it matter whether it's a bug or a feature request? Again, no. The crux of the matter is it would be nice if there was some way to use F-keys in dialogs.