Ok, I understand what you're trying to do. You're trying to hook into mIRC's processing system and change global state prior to that global state being checked.
The short answer is: you should not be doing that. That is extremely messy. Even *if* mIRC had some /command to disable/enable the confirmation dialog, it would be bad form to use this from within an on input event. You shouldn't be changing global state just to manage one channel. First of all there isn't even a guarantee that changing the confirmation dialog option from ON INPUT would be early enough for mIRC to even register-- so this behaviour could change from version to version. Secondly, if mIRC were to ever allow multiple events to fire "at once", your modification of global state would create a threading issue. This is less likely, but still something to consider. Basically, changing global state to deal with "per-channel" behaviour should be considered a hack no matter if mIRC supported it or not. It would be akin to changing /timestamp from within an ON TEXT even to customize the timestamp format for a single channel. Messy. Bad form. Don't do it.
If you want to make a channel specific paste setting, you should create a separate script that does NOT make use of the global switch at all. Make your own option in your own script that toggles this setting per channel, use your own configuration to manage this, and create your own input confirmation dialog box. Your separate configuration dialog that says "Avoid pasting in these channels" should just check against those channels, and you don't need to check the global confirmation setting. The global setting in mIRC should still control the global state-- in other words, if users want channel specific confirmation, they should disable the global confirmation box. You can tell users that they need to disable the global confirmation to use your script, or you can do it for them by restarting mIRC (and making the mirc.ini change) in your ON LOAD event. Since this only happens once, it's not that intrusive. The need to restart a program when installing a new script/plugin is not uncommon. Firefox still adopts this methodology. I don't see having such a requirement as unreasonable-- and you wouldn't always need to restart (you could check that it is already disabled).
