mIRC Home    About    Download    Register    News    Help

Print Thread
Joined: Dec 2002
Posts: 252
T
Talon Offline OP
Fjord artisan
OP Offline
Fjord artisan
T
Joined: Dec 2002
Posts: 252
Code:
alias mircbug { editbox -n $active this | editbox -n $active is | editbox -n $active a bug }


in an editbox, I did /mircbug, hit up a couple times and it shows: "a bug" then "/mircbug"

I stumbled upon this trying to intercept paste dumps (multi-line $inpaste) and wanting to colorize some stuff, but not lose my theme by using things like /say or /msg, so what better way than to let on input handle it by forcing an entry into the editbox I thought?

ok so lets look at my example on input...
Code:
on *:input:#: {
  if ($inpaste) { echo -a * Inpaste! $1- | $+(.timer,paste.,#,.,$cid) -m 1 50 d $active | haltdef }
  elseif ($left($1,1) != /) || ($ctrlenter) {
    haltdef
    .msg # $1-
    echo -ti2 # $+(<,$left($nick(#,$nick,a,r).pnick,1),$nick,>) $1-
  }
}


and now lets look at the alias "d"

Code:
d var %x = 0 | while (%x < $cb(0)) { inc %x | editbox -n $1 $cb(%x) }


now lets take this message
Code:
this
is
a bug


and copy it to clipboard and dump with ctrl+v to a channel

Output:
Code:
* Inpaste! this
* Inpaste! is
* Inpaste! a bug
[18:28] <@Tal> a bug



Uparrow buffer: "a bug" "is" "this"

wtf? the editbox history shows it there but mIRC only sends the last one...

now change /editbox -n to /msg in my "d" alias and boom it works like a charm, but now its not themed and is ugly...

This is not entirely what I was doing, it's dumbed down for the sake of just showing the bug, and tested with this minimal amount of code, I figured less was better when it still bugged so you don't haveto attempt to follow what i'm doing so "d" has been simplified, and so has my on input, so yea i realize theres a potential breakage when dumping something where a line might be starting with /, so no flames or comments on that note, just something quick and dirty to show how to reproduce this issue.

Joined: Dec 2002
Posts: 5,411
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,411
Thanks for the bug report. This behaviour is actually by design. The -n switch sends a PostMessage to the editbox control to process any editbox contents. This means that processing only takes place after the script exits.

The reason for this is that the editbox is designed for user input, not scripting, and interacts with a number of GUI features that are global. If the -n switch used SendMessage to force immediate processing, the editbox processing routine would be entered recursively, possibly many times, and there would likely be side-effects (especially as there are both pre and post processing updates to the editbox). So unfortunately this is not possible.

The only solution I can think of is for you to use a /timer for each /editbox call to allow the editbox to work as expected.

Last edited by Khaled; 10/08/12 11:21 AM.

Link Copied to Clipboard