mIRC Home    About    Download    Register    News    Help

Print Thread
#212045 09/05/09 01:01 AM
Joined: Mar 2006
Posts: 395
T
The_JD Offline OP
Pan-dimensional mouse
OP Offline
Pan-dimensional mouse
T
Joined: Mar 2006
Posts: 395
/editbox -f #channel
It works, But it seems to take the MDIChild (the window) and (Im guessing) minimize and max - The titlebar quickly becomes just "mIRC" and the window resizes a little then resets.
It dosnt take very long to happen (500 ms) but its a mild annoyance.


[02:16] * Titanic has quit IRC (Excess Flood)
The_JD #212048 09/05/09 01:17 AM
Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
It's quite instantaneous here. Can you describe your system? mIRC version, scripts, etc?

The following will help answer some of the above questions:
//echo -a $md5($mircexe,2) $version $os $script(0) $dll(0)

Lastly, are all the windows maximized when you do this? If not, can you describe how your windows are setup? If the window needs to be maximized, you can expect a delay, there's not much mIRC can do about this.


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
argv0 #212076 10/05/09 02:35 PM
Joined: Mar 2006
Posts: 395
T
The_JD Offline OP
Pan-dimensional mouse
OP Offline
Pan-dimensional mouse
T
Joined: Mar 2006
Posts: 395
Originally Posted By: argv0
It's quite instantaneous here. Can you describe your system? mIRC version, scripts, etc?

The following will help answer some of the above questions:
//echo -a $md5($mircexe,2) $version $os $script(0) $dll(0)

Lastly, are all the windows maximized when you do this? If not, can you describe how your windows are setup? If the window needs to be maximized, you can expect a delay, there's not much mIRC can do about this.


2f63a83968f9586fe4fb48134253619c 6.35 Vista 0 0
Official mIRC.exe, version 6.35 without scripts nor DLL's loaded, lol.

The window is maximised in mIRC, and i'm not sure why I should expect a delay as you indicated.
If the window is the active window (which it is in my case) then the inputbox should take the focus.
It appears mIRC is not checking if the window is the active window and tries to change to itself, causing the issue

/editbox -fa
The above produces the same result


[02:16] * Titanic has quit IRC (Excess Flood)
The_JD #212081 10/05/09 05:08 PM
Joined: Jul 2006
Posts: 4,144
W
Hoopy frood
Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 4,144
$script(0) can't return 0, are you trying to hide the real information ?
Anyway, I can see the "delay" you're talking about when using /editbox -fa with maximized window, but it does not appears all the time I'm using the command, sometime I can see it, sometime I can't

Edit : I'm sure it's quite instantaneous for anyone, but since I'm unable to see any delay when the window isn't maximized, It's hard for me to understand that the delay is something normal

Last edited by Wims; 10/05/09 05:17 PM.

#mircscripting @ irc.swiftirc.net == the best mIRC help channel
Wims #212102 11/05/09 12:53 AM
Joined: Mar 2006
Posts: 395
T
The_JD Offline OP
Pan-dimensional mouse
OP Offline
Pan-dimensional mouse
T
Joined: Mar 2006
Posts: 395
Originally Posted By: Wims
$script(0) can't return 0, are you trying to hide the real information ?

Shhhh....

Anyway, I can see the "delay" you're talking about when using /editbox -fa with maximized window, but it does not appears all the time I'm using the command, sometime I can see it, sometime I can't

Edit : I'm sure it's quite instantaneous for anyone, but since I'm unable to see any delay when the window isn't maximized, It's hard for me to understand that the delay is something normal [/quote]

Yeh, as you said, its not normal.
I'm pretty sure that it comes down to mIRC trying to switch the the mdichild, which is allready active.
I would expect this if it wasnt the active window, but since it is, the input should be placed on the editbox, and no window manipulation should be required.


[02:16] * Titanic has quit IRC (Excess Flood)
The_JD #212106 11/05/09 02:38 AM
Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
If by "delay" you're referring to the millisecond (not even close to 500ms) flicker, then I would not call that a delay, and it would still be considered instantaneous.

The "delay" is quite normal. mIRC is activating the window (probably by redeclaring it as the foreground child window) which is expected behaviour when dealing with MDI windows. This is normal because you told it to do so by executing the command.

This bug report seems to have changed from /editbox -f to the special case of /editbox -fa, which is quite a different story. You seem to be saying that mIRC can avoid a (insignificant) flicker by checking if the current active window is the one you're switching to. Perhaps.. but so can you:

Code:
if (%window != $active) editbox -f %window


I on the other hand would expect that mIRC insistently and noticably refresh the window when typing /editbox -fa the way it would with any window, otherwise I would be wondering if it did anything at all. Addendum: if I type/execute /editbox -fa (or even editbox -f <window> where window == $active) I expect mIRC to do something noticeable, otherwise I wouldn't type/execute it. In this sense, the flicker seems normal to me.

Again, I'll harp on this point, but if I didn't want the flicker I would make sure I was not activating an already active window. Note that this is the exact same behaviour as /window -a $active, which you are basically saying is also a "bug" by association. I would not agree.



- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
argv0 #212139 12/05/09 12:34 AM
Joined: Mar 2006
Posts: 395
T
The_JD Offline OP
Pan-dimensional mouse
OP Offline
Pan-dimensional mouse
T
Joined: Mar 2006
Posts: 395
I'm not at all trying to say "/window -a $active" would be a bug - That command does EXACTLY what I would expect!

Here's my scenario:
I'm using a version of nHTMLn.dll, and as you're probably aware, it doesn't return focus to the editbox, so I have an "on click" event in javascript to return the focus to the editbox.

So, whilst I can return focus to the editbox, it's trying to activate the already activated window, then showing the editbox.

This sort of scenario is the probable reason as to why the "-a" switch was added to the editbox.

Does this make sense?

Your comment about "/editbox -fa" needing to refresh the window or else you would wonder about anything happening at all, is a bit odd imho, I would expect mIRC to... "set the focus to the editbox... specifically the active window" as it implies in the mIRC help file

I'm not trying to turn this into an argument, but I would expect it to do what the help file says, not "/window -a $active"

As for your snippet:
Code:
if (%window != $active) editbox -f %window

That would work fine, if the window wasn't the active window.
What if (this is my issue) the window is the active window, and you want to set the focus to the editbox?

Last edited by The_JD; 12/05/09 12:36 AM.

[02:16] * Titanic has quit IRC (Excess Flood)
The_JD #212144 12/05/09 02:19 AM
Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
We're talking about an edge-case scenario then, the interaction of a DLL with mIRC. This is really something that nHTMLn.dll should handle (I'm aware of, but not familiar with this dll), but I'm guessing modifying it could be difficult.

An easy workaround would be: /sendkeys {TAB} (using the standard sendkeys alias floating around the forums).

The real solution might be slightly more complicated, but this is a good starting point.

/editbox -af does what it's expected to do under normal usage conditions of mIRC. Since you agree /window -a $active is not a bug, /editbox -af can't be one either (they do the same thing with the extra action of forcing focus on the editbox in the latter command). Your issue can't occur unless the UI was fundamentally changed. If a DLL heavily modifies the UI to the point where commands no longer behave sanely, it's the DLLs responsibility to mitigate that, not mIRC's.


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
argv0 #212147 12/05/09 09:17 AM
Joined: Mar 2006
Posts: 395
T
The_JD Offline OP
Pan-dimensional mouse
OP Offline
Pan-dimensional mouse
T
Joined: Mar 2006
Posts: 395
So you think that a command, designed to switch the focus to the editbox, should work exactly the same as a command designed to change the window? C'mon, Seriously? If so, why do you think we'd have both and neither be deprecated?

As for needing to change the UI extensively, it also works in the same way that it would if the nicklist was selected, as that would grab focus, rather than the editbox.

Do you seriously have an issue with mIRC's "/editbox -fa" just setting focus to the editbox?

Also, the /sendkeys TAB wouldn't work, since there can be any amount of tabstops on the one page.

It seems that you are trying harder to communicate yourself being right, than taking into consideration what the command should/could do.
I personally think that mIRC self checking on this one occasion would be a smart idea, and have no impact on any other scenario - that's why I filed it as a bug.

Can you give me one example of where mIRC would be negatively impacted if this bug was corrected?

Regards
Joshua D


[02:16] * Titanic has quit IRC (Excess Flood)
The_JD #213457 28/06/09 07:38 AM
Joined: Mar 2006
Posts: 395
T
The_JD Offline OP
Pan-dimensional mouse
OP Offline
Pan-dimensional mouse
T
Joined: Mar 2006
Posts: 395
Still having issues with this, Could Khaled please comment, a small check to see if the active window is the one to get focus, then skip moving to that window, and go directly to setting focus to the editbox?

Thanks,
The_JD

Edit: Oh, and before you mention nHTMLn again argv0, I'm not using that now.

Last edited by The_JD; 28/06/09 07:40 AM.

[02:16] * Titanic has quit IRC (Excess Flood)
The_JD #213466 28/06/09 05:51 PM
Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
What is the issue now, if not related to nHTMLn?


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
argv0 #213483 29/06/09 12:10 AM
Joined: Mar 2006
Posts: 395
T
The_JD Offline OP
Pan-dimensional mouse
OP Offline
Pan-dimensional mouse
T
Joined: Mar 2006
Posts: 395
Getting the editbox to take focus, without popping the window around.

No matter how much you try and pretend its not, it's a mIRC issue.
If the second editbox is highlighted or the nicklist is selected

Last edited by The_JD; 29/06/09 12:11 AM.

[02:16] * Titanic has quit IRC (Excess Flood)
The_JD #213504 29/06/09 05:46 PM
Joined: Jul 2006
Posts: 4,144
W
Hoopy frood
Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 4,144
Only Khaled could state if it's a bug or not...
Actually you're saying that Khaled could check if the window isn't already the active window, so you're supposing it's not already the case, then it become a suggestion.
You're the one that use the script, you're the one complaining about the behavior, I think you're the one that should do the check.


#mircscripting @ irc.swiftirc.net == the best mIRC help channel
Wims #213520 30/06/09 12:23 AM
Joined: Mar 2006
Posts: 395
T
The_JD Offline OP
Pan-dimensional mouse
OP Offline
Pan-dimensional mouse
T
Joined: Mar 2006
Posts: 395
I can check if the window is active, thats not the issue, did you read the post?
The issue is that /editbox -af (which should set the focus to the active editbox), tried to change the active MDI child to the (already) active window, before setting the focus


[02:16] * Titanic has quit IRC (Excess Flood)
The_JD #213544 30/06/09 10:17 AM
Joined: Jul 2006
Posts: 4,144
W
Hoopy frood
Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 4,144
I did.


#mircscripting @ irc.swiftirc.net == the best mIRC help channel
The_JD #214045 14/07/09 09:43 PM
Joined: Dec 2002
Posts: 5,411
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,411
This is in fact what is happening - window focus/activation can be tricky so the set focus routine in mIRC has to take into account a number of situations. The resetting of the window is necessary in this case however it should be quick and barely visible. I'm not sure why it would take 500ms - are you displaying a background picture in the window by any chance?

Khaled #214046 14/07/09 09:53 PM
Joined: Mar 2006
Posts: 395
T
The_JD Offline OP
Pan-dimensional mouse
OP Offline
Pan-dimensional mouse
T
Joined: Mar 2006
Posts: 395
There's no background picture or anything else, even with vanilla mIRC on a clean Windows Vista install, it takes close to a second.

If it's not possible for you to fix this issue, would it be possible to add another command/switch, that will only move the focus to the active editbox, if one exists?

Edit: Maybe my processor isn't as fast as yours? (laptop)
Edit2: It's noticably faster if there is no text on the window (100ms?)

Last edited by The_JD; 14/07/09 09:57 PM.

[02:16] * Titanic has quit IRC (Excess Flood)

Link Copied to Clipboard