Strange 'Control $idx <proc>' behaviour

[Iridium]

I'm trying to write a dcc interface for one of my bots, what I do is the user connects, they are 'controled' by the 'user' proc. If they enter a valid user control moves onto the 'password' proc. If they pass that they are kicked into the 'real interface' proc.

example:

Code: Select all

proc dccaccept {idx data} {
  # blah blah
  set idx [connect $ip $port]
  control $idx myuser
}

proc myuser {idx data} {
  global theusername
  if {$data == ""} { putlog "$idx closed connection" }
  if {[validuser $data]} {
    set username $data
    control $idx mypassword
  }
}

proc mypassword {idx data} {
  global theusername
  if {$data == ""} { putlog "$idx closed connection" }
  if {[passwdok $theusername $data]} {
    control $idx myrealinterface
  }
}

proc myrealinterface {idx data} {
  if {$data == ""} { putlog "$idx closed connection" }
  # blah blah
}

Now, everything works fine and if I enter everything correctly, I reach myrealinterface and it does what it is supposed to.. BUT

Why is it that when I close the connection, I see the putlog three times? if I put a number with each different putlog, I see each different putlog. If there is an error in myrealinterface, instead of the connection terminating I get kicked back to the password proc. Basically, if the connection gets closed in myrealinterface, it gets kicked back to the previous control procedure. This is not what I want

I have tried 'control $idx ""' and 'control $idx' but that means that it just seems to try and call the idx number as a proc (calling '<idx> <data>' instead of '<proc> <idx> <data>'

This is very strange. It would be useful if someone could explain this or tell me how I can perhaps 'clear' the procs behind it. I have tried looking through some of the tcldcc.c and some of the other source, but to no avail

Thanks for your time, and thanks in advance.

[FrEsC]

Hi,
I'am a newbe so please correct me if I'm wrong but I think I can help you.
I've read something about a return value of the control proc. Maybe you have to return 0 if a control isn't used anymore.

Paul Bottin a/k/a FrEsC

[Iridium]

If you return 1, the control proc isn't used any more, but..

if I do

Code: Select all

control $idx myrealinterface
return 1

it kills the myrealinterface control

and I can't do

Code: Select all

return 1
control $idx myrealinterface

because that will kill the current procedure before it gets to the new control.

[stdragon]

Yes it is an unfortunate feature of the way eggdrop does the control command. When you set a new handler, it saves the previous handler in a linked list instead of overwriting it. I had the same problem when I was writing a game with a menu interface. When users quit, it would spit out like 50 "connection lost" messages. I changed my code to use a single handler for all idx's, which would then branch to the correct handler based on a global array idx_state. Something like this:

proc idx_handler {idx data} {
global idx_state
if {[info exists idx_state($idx)]} {
if {[catch {eval $idx_state($idx) [list $idx $data]} err]} {
putlog "error in handler: $err"
}
} else {
putlog "no handler for $idx"
}
return 0
}

Then in all the places you normally say "control $idx blah" just say "set idx_state($idx) blah"

[Iridium]

Heh, thats exactly what I did in the end, thanks anyway