mIRC Homepage
Forgive me if this has already been suggested. I did a search and found nothing similar.

I generally prefer the method mIRC uses to determine the location of the results of a /whois, however, I cannot seem to easily emulate it using a script. I was attempting to timestamp the "End of /whois" field, but ran into problems. Issues regarding multi-server can be addressed with $activecid, but when using single message windows and displaying /whois in the active window, scripts cannot differentiate between automatic and manual /whois-es, nor their originating location. Anyway, it would be convenient if an additional checkbox could be added beneath "Timestamp Events" to timestamp /whois responses with the timestamp setting (for compatability, I assume defaulting to /whois timestamps would be unwise).

I might have suggested this once before, but in keeping with the timestamp theme, I would like to see the option to pass timestamping to an identifier. A parameter or two could be passed to indicate the type of event being processed and/or raw event number, and the identifier could return different formats based on that type. So, for example, one could set the raw mode of 318 ("End of /whois") to return a timestamp, but return nothing for 319/312/etc. (other /whois items). In addition, a user could make up their own timestamping formula (for example, base conversion) in the event the visual display is irrelevant yet the logs should contain an exact timestamp.

One final item in the display theme: In the IRC option tab, the items under "Show in active" as well as "Events" could be converted to three-state checkboxes or a separate set of checkboxes to indicate to "show in status" as well (or "show in both" for the events dialog). This is hardly imperative, but could be convenient for those who wish an active buffer of what's currently occuring, as well as a status history of certain events in chronological order, regardless of channel.

Thank you for your time and consideration,

Jinx
Use this:

Code:
raw 318:*:{ haltdef | echo -t End of /whois }


That is what you mean right?
I'm afraid not. If you test your code, you'll notice that the /whois does not display in the appropriate window (the window in which the /whois was initiated), which was the point of my first suggestion: there is no way to emulate the behavior of the /whois responses without an excessive on input database--a bit too much for a simple timestamp if you ask me. Thanks for trying, though.

If you were referring to my other suggestion regarding also echoing in the status window, then your code would conceivably work (although it would remove that particular data string from the active /whois response). Of course, it's possible to perform the entire suggestion via script if one wants to re-route every raw into an event that doesn't haltdef. I just thought it might be a fairly small and easy feature to add (one line of code, maybe a few of dialog) to avoid the hassle of intercepting multiple event types.

Again, thanks a bunch for trying to help though, I do appreciate it.
why dont u just customize the /whois command, so when entered it stores its active channel? or am i missing something in what ya doing?
Oh no, that's exactly what I was getting at. That's a possibility: it would just involve making a database of every whois initiated (let's say you're on a client that operates on multiple servers and could whois multiple people simultaneously). Is it a lot of work? Maybe not. It just seems a bit excessive for a silly timestamp. Plus, the benefits of implementing the entire suggestion would be a definite bonus.

Edit: I knew there was something I forgot to add: the scripting method would only work properly for /whoises initiated by the user. If a /whois was initiated by a script, it may not operate properly (for example, one could not simply "default" to the status window if the single message window is open, in which case the target could be either). If it weren't really nebulous, trust me, I'd try to script it. smile
You could use variables with identifiers in them, like var %whois. [ $+ [ $1 ] ] = $active or something. You're right it would be a pain to code it though, with much use of brackets.

Also scripts will use the aliases without anything special. I've set one of my scripts that monitors botnet channels to use the alias.

Personally, I have the /whois echo to active. I find it much more useful that way.

What you;re asking for is doable. Just really painful.
I have no idea what ARcanUSNUMquam is on about LOL. I think hes gone down a different path from what your talking about.

But on looking at how /whois seems to work when echoing, im pretty sure that the whois reply if its set to reply to the active (alt-o/irc/show in active:whois) replies to the $wid when it is invoked, if that window still exists when the whois is returning data.

I tested this by several means , one by...

alias whois { echo -s Doing WHOIS current wid $wid, whois for $1- | whois $1- }
Typing...
//window -e @test
Followed by in @test window typing...
//echo -s @test wid is $wid | .timer 1 60 whois nick

Status window cam back with...
@test wid is 13
Doing WHOIS current wid 13, whois for nick
<whois nick data replied in the @test window>

I then advanced to typing in @find
//echo -s @test wid is $wid | .timer 1 60 whois nick
followed by
//window -c @test | window -e @test
followed by
//echo -s The new @test wid is $wid

Status window cam back with...
@test wid is 13
The new @test wid is 16
Doing WHOIS current wid 13, whois for nick
<whois nick data replied in the STATUS WINDOW>

I did another test where I had this raw
raw 319:*:{ window -c @test | window -e @test }
in @test i then typed /whois nick
Apon the raw going off no other data was displayed in @test, rather it appeared in STATUS WINDOW

OK so whats that all mean, little i guess, besides that maybe an alias something like this (simplified alias here to deal with only $1 but its an example only ok)
Code:
alias whois {
  var %itemname = $+($cid,@,$1)
  hadd -m whois.tracking.table %itemname $hget(whois.tracking.table,%itemname) $wid
  ;^ add $wid to hashtable itemname $cid@$1 (adds to cater for multiple whois's on same user)
  whois $1
}
;
;and with raw 318 $1- = $me nick End of /WHOIS list.
;
raw 318:*:{
  var %itemname = $+($cid,@,$2)
  var %itemdata = $hget(whois.tracking.table,%itemname) 
  var %wid = $gettok(%itemdata,1,32)
  if ($deltok(%itemdata,1,32)) {
    hadd -m whois.tracking.table %itemname $v1
  } | else {
    hdel whois.tracking.table %itemname
  }
  echo -t $window($+(@,%wid)) $3-
}


* this has been writen here so is untested, and of course doesnt have any error cheks for things like non existing wid windows etc, and doesnt cater for whois with multiple nicks, but i felt it was a starting point to acuartely tracking what window a whois came from.

All other raws of the whois could be caught and direct using the similar process, just not removing the hash table entry since it isnt finished with of course.

PS: i think im on the right track here, yell out if i have fallen over board or am driving towards rocks!
Quote:
I have no idea what ARcanUSNUMquam is on about LOL. I think hes gone down a different path from what your talking about.


I was basically allowing for multiple nicks. For every time you whois different nicks, it'll assign a window to it. You can echo to that window contained in that variable, and I think that does what the Jinx was talking about.

ALthough it won't work if you whois the same nick more than once in different windows while your connection is too lagged for the server not to return the information instantaneously.
ok your on the same track i guess then, just i didnt understand what ya were meaning, as i mentioned in my last message, i wouldnt user dynamic vars, rather a hash table idervidualising not just the nick but the $cid your on, and queuing up the WID of each window the whois is from so it cant be used for the reply. Similar but maybe a bit more resilent with multi server users.
© mIRC Discussion Forums