mIRC Home    About    Download    Register    News    Help

Print Thread
#186264 20/09/07 02:11 AM
Joined: Jul 2003
Posts: 24
K
Ameglian cow
OP Offline
Ameglian cow
K
Joined: Jul 2003
Posts: 24
I think it would be great if there was an identifier in the on TABCOMP event that would return what text was replaced in the TABCOMP event.

For example, if I typed "Hello Killed[TAB]" and it turned into "Hello KilledInAction", then the identifier (something simple like $tabcomp) would return "Killed", only the part of the line that was replaced.

There could also be a prop that indicated where the replacement occurred. For example, if i typed:
"Killed what are you doing", then went back and tab completed the first word to get "KilledInAction what are you doing", the .pos would return 1. I'm assuming the most reasonable way to indicate the position would be the token number, as the entire line changes when the change is done.

Edit: This is is something else, but it goes along with the same problem. Is it also possible to find out which editbox is currently in use in a window? (ie. if a channel with a dual editbox is open, it is impossible right now to tell which editbox the user is typing in).

Edit2: It also seems that the /haltdef command for me is halting the entire script in the on ^*:TABCOMP event... I don't know why that is

Last edited by KilledInAction; 20/09/07 02:23 AM.
Joined: Dec 2002
Posts: 2,962
S
Hoopy frood
Offline
Hoopy frood
S
Joined: Dec 2002
Posts: 2,962
  • You can use $editbox($target) to get the contents of the editbox (pre-completion).
  • You can use $editbox($target).selstart to get the location of the tab completion "hotspot" (note that mIRC always treats the start of the selection as the hotspot even if a peice of text is selected and the cursor is actually at the rightmost end).
  • $cmdbox will return $true if the tab completion event was triggered from the command-box.


All of this combined leaves you with:
Code:
on *:tabcomp:*:{
  echo -a Original text: $editbox($target, $iif($cmdbox, 1, 0))
  echo -a Completed text: $1-
  echo -a Tab completion hotspot: $editbox($target, $iif($cmdbox, 1, 0)).selstart
}


I can't reproduce your /haltdef problem here, the script carries on processing.


Spelling mistakes, grammatical errors, and stupid comments are intentional.
Joined: Jul 2003
Posts: 24
K
Ameglian cow
OP Offline
Ameglian cow
K
Joined: Jul 2003
Posts: 24
that's really weird... thank you, I'll have to figure out exactly what was going on with my haltdef.

Joined: Jul 2003
Posts: 24
K
Ameglian cow
OP Offline
Ameglian cow
K
Joined: Jul 2003
Posts: 24
Ok I figured out what was going on. I didn't realize that the on ^*:TABCOMP:*: event ONLY triggered when mIRC actually changes the text in the editbox (and there is in fact an event *to* halt), while the on *:TABCOMP:*: event triggered pretty much any time the TAB key is pressed.

So, when I changed my event to a ^ event, nothing was processing because it wasn't something that mIRC thought should have been completed. So, to modify my original post, since as starbucks_mafia explained, all of those identifiers I was looking for are present. Instead, the help file is not very clear in this section as to what triggers each of the events. It could also use some information to point users to key identifiers that would be used here.

Thanks again.

Edit: What's also interesting is the way the ^ event works with the regular event. If there is both a ^ event and a regular event, the ^ event will trigger first, and then the regular event will also trigger, unless haltdef/halt is used in the ^ event.

Last edited by KilledInAction; 20/09/07 05:37 PM.
Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
Originally Posted By: KilledInAction

the ^ event will trigger first, and then the regular event will also trigger, unless haltdef/halt is used in the ^ event.


Hmm, are you saying that halting a ^ event will halt the regular event from being processed as well? Can you reconfirm this? The help file says:

Quote:

The ^ events don't replace your existing events; your normal events are independent and are still processed whether there is a ^ event in a script or not.


That would be a more interesting help file contradiction to look at, and may even be a bug.


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
Joined: Jul 2003
Posts: 24
K
Ameglian cow
OP Offline
Ameglian cow
K
Joined: Jul 2003
Posts: 24
Code:
on ^*:TABCOMP:*:{
  echo -a ^ Event triggered
}

on *:TABCOMP:*: {
  echo -a Regular event triggered
}


Case 1: I type something that will NOT be completed by mIRC:
Regular event triggered

Case 2: I type something that WILL be completed by mIRC:
^ Event triggered
Regular event triggered

Code:
on ^*:TABCOMP:*:{
  echo -a ^ Event triggered
  haltdef
}

on *:TABCOMP:*: {
  echo -a Regular event triggered
}


Case 1: I type something that will NOT be completed by mIRC:
Regular event triggered

Case 2: I type something that WILL be completed by mIRC:
^ Event triggered


Joined: Feb 2007
Posts: 8
B
Nutrimatic drinks dispenser
Offline
Nutrimatic drinks dispenser
B
Joined: Feb 2007
Posts: 8
Code:
on ^*:tabcomp:*:{
  myalias
  haltdef
}

on *:tabcomp:*:{
  myalias
}

alias -l myalias {
  echo -a this code is run everytime a tabcomp is activated, it halts default text and still works if mirc wouldn't complete anything (or give an error)
}


tabcomp bug's that remain:
- If the line is too long, all text after the completed word will be cut off.
- $editbox()/editbox has some issues with spaces (mirc original tabcomp not).
- Things I not remember.

missing: tabcomp in the help-page: halting text


Link Copied to Clipboard