Forums Developers Changing options in mIRC

Hi everybody.

I need to change settings in mirc without opening the Options Window (Alt+O). Is there any way to achieve this?

If not... Does it exist any way to "reload" mirc.ini without restarting mIRC?

Thx in advance

It depends what option you want to change...

Some options are tied into commands, like /timestamp, /proxy, etc.

Others can't be accessed. And no, you can't write to mirc.ini and reload it after the program is running.

If the option is commonly modified by users, or if you can convince Khaled why you need to control this option via script, you can add a feature request to create a command to control it from script, but otherwise you will be stuck with Alt+O.

I know some options are tied into commands, but I needed those options which are not.

Anyway, thanks a lot for your reply argv0!

Feature request command controls for them if you think they deserve such command controls. Otherwise, do you really need commands for configuring their behaviour?

To me it's important. Sometimes there are situations in which you need a setting to be adjusted for something to work. When you have the knowledge to do it, there is no problem, but when other less experienced people or with no knowledge about it has to do it...

That's even more important when a setting needs to be enabled, disabled or its value changed during runtime. If the user has to open the options window, search for the desired option, adjust it, close the window and return chating... I think it's really embarrasing.

With a so highly customizable program as mIRC, with maybe several scripts reacting to the same events, I think changing global options in a transparent way is something that can help to control. I've found this problem when trying to program a protection for the users, but know I'm not the first person who had this problem: I found a thread in a forum (think in mircscripts) dated in 2003 in which someone posted the same question. There is an approach to this using COM, but it's "dirty" and interface-dependant, so I tried to avoid this one. As I didn't know if there are another approaches, I decided asking here.

Of course, this is just a little reflexion and a situation in which I've found myself in an dead end. If there are no commands to adjust the other settings I suppose it's because people don't need it or because it's something that would be useful in just a few situations and don't deserve the effort to develop it.

What specific protection were you trying to achieve? There are a lot of great protection scripts out there that cover just about any contingency and they get by with what's available. Maybe you're going about it the wrong way?

There's also no reason to be "embarrassed" for changing an option. I'm not sure why anyone would be. And it's fairly easy to point out where to change something... Alt-O > Sounds > Enable Sounds for example.

Embarrassing? I think you may have used the wrong word. There's no way changing options can be embarrassing. People adjust options/settings across every program, from MS Word to your web browser. I go into options constantly for firefox, for instance, to adjust proxy settings. I do the same in my mail application, to create new accounts. Why is this embarrassing? I'm certainly not embarrassed about this.

Are you wanting these /commands so that you can use them from the editbox? Or is your goal to ultimately create some custom configuration script (like a dialog or custom option windows)? If your case is the latter, I would have to disagree with your methodology, especially since by your own standard, having to go into an options window would be equally "embarrassing".

If it's just so you can type /foo off in the editbox without opening Alt+O to disable some feature, this seems like a very personal preference. Most users using mIRC aren't really as comfortable using /commands to configure things. This is why mIRC has dialogs for most options, and why, for instance, Khaled even introduced dialogs for features that previously had no such interface (/playctrl for one, channel central, address book, though the last two were created in tandem with the /command control, but still). I think you'd be in the minority of users who are "afraid of" or "embarrassed by" GUI dialogs. In fact, those with "less experience" are more likely to want GUI dialogs instead of /commands, so I don't buy your initial argument.

Perhaps you'd be more comfortable with a client like irssi, which performs all configuration through commands from the get-go. mIRC really isn't meant to be that kind of a client.

Again, it would help to know what specific features you're trying to configure. If your answer is just "everything", then it seems like there's a disconnect of expectation. If you're actually looking to configure something specific, please tell us what it is, maybe there is another way to do what you want-- or support for making it customizable via command.

I think you missunderstood me. I'm not talking about changing an option, in a specific moment, through the options tool is embarrasing. In fact, I use a lot of programs and option windows make it much easier configuring the application. In fact, I've programmed many applications and option windows are a must-have. And I think a right GUI can help, of course, applications where everything is command-controlled... are hard to learn and to configure/use, at least, from my experience

I'll try to explain an example. Let's imagine someone who usually chats in several channels. In most of them, copy-paste is allowed but in one of them it isn't. How could you avoid (or at least, let choose) this user pasting text in this channel but allowing him in the others? And this should be done via an addon,not modifying the existing files which make up his script

Of course, I'm maybe wrong and there are another approaches to this, but all snippets and references I've found concerning this (I've searched and tried several things before posting) rely all on INPUT event and all of them say that, if you already have ON INPUT defined in your script/s, it will conflict with the snippet.

Again, it's an example and maybe I chose the hardest path existing another ones which are easier. As ALWAYS there are people who have a deeper knowledge and experience that oneself, I tried posting here

I don't want the user dealing with commands, I want providing them with better tools to chat. It's as simple as that.

I feel like we've just entered another discussion entirely.

What does your example of multiple ON INPUT scripts have to do with the builtin Alt+O options in mIRC? Options tend to have little effect on such scripts.

I'm still not exactly sure what you're trying to do, or why having scriptable access to the options dialogs are necessary. If users do need to change options, they should be doing it from the Alt+O dialog. You shouldn't be making new UI's to configure this-- that just make things *more* confusing.

Maybe I'm just confused about what your goal here is. If you believe that programs where everything is command controlled are difficult to configure, why are you asking for *more* commands to configure the program? This is really confusing. Maybe you should start from the top and try to explain this properly.

It's all related, I'll try to explain again.

Let start from the problem: a user (several users, to be more correct) chat in different channels. In most of them, copy-paste is allowed and in many others it isn't. Sometimes, they mistake an paste text in channels where it's not allowed.

Seeing that scenario, I think it would be great some kind of self-protection to avoid pasting in channels where it's forbidden at the same time it allows pasting in the channels where it is allowed. And all of this, of course, in a transparent way to the user, which would only have to mark a check box in a option window (different from the one provided by mIRC) entitled like "Avoid pasting in these channels" or so.


At the time of developing it, I thought about several options, in this order:
- On INPUT event: discarded from the beggining, as a halt on an ON INPUT in one script doesn't stop ON INPUT in the rest of the scripts.
- Use the confirm Tools->Options->Other->Confirm-> Confirm when pasting x or more lines of text. The idea would be that, when in an allowed channel, this option to be disabled, and when in a forbidden channel, enabled, with automatic switching from one to another setting, I mean, with no user action needed (this is the key point)

At this point, I began looking for a way to enable / disable this confirmation depending on the channel the user is. I follow 3 approaches to this:
1 ) looking for some function in mIRC documentation which allows adjusting this setting. Dead End, at least, what I've seen til now.
2 ) using $readini and writeini to modify mirc.ini, according to the document Mirc Unleashed, which provides the line and position for every option in mIRC, and forcing to reload mirc.ini without restarting mIRC. A "dirty solution", as writeini is suggested not to be used to modify mirc.ini and it's unknown how options may be trated and stored in future versions. Dead End, at least, what I've seen til now.
3 ) using COM to simulate key strokes by the user to open the options window and navigate to enable/disable this option. This solution is even dirtier, as it depends on the order and position of the components in the options window but, til now, is the only one which I see as possible. This approach, which I initially preferred to be discarded, was also suggested by another scripter I exposed the question to.

Hope this explanation shows you why ON INPUT, reloading mirc.ini and a function to change settings in mIRC are related, at least concerning the problem I want to solve.

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).

Regarding use of on INPUT and halting other scripts, you can look into the & event prefix. Of course, that only helps with your own script(s) and not someone else's.

Riamus2, the ON INPUT event was the first thing I thought about and considered the & prefix, but I can't know what scripts have other people loaded in their mIRC, so I had to forget about it. My script can stop its execution when detecting CTRL+V, but won't stop the other ones.

argv0, I know this is not a clean solution. Several considerations here.

- I wouldn't change the state for this confirmation inside ON INPUT event, but ON ACTIVE. When a channel windows is activated, the Global Status, as you called it, would be changed.

- I have created a separate script, an addon which is loaded by the user, with its own option window. That's the way I programmed it, that's the point. You told about toggling this setting by channel... that's what I want to do but I haven't found any way to do it. Consider I disable the confirm in a one-time basis. Ok, on LOAD that's done, perfect, restarting mIRC one time suppose no problem, of course. The question is: How could I activate this for (simplifying) one channel, from a script?. If the confirmation is disabled and I shouldn't change this global setting, the only "path to follow" is working with ON INPUT, but when there are many ON INPUT catchers through several scripts, it doesn't work: my ON INPUT can have a HALT command embedded which avoids the text being sent to the channel (using $inpaste, for example) but the others ON INPUT would continue their execution normally. Many people use ircap as their main script on mIRC, and this addon have to live with it (or any other script)

If there's a way to avoid pasting for a channel, that would be great, because that's exactly what I'm looking for, but I haven't found other way to do it. This addon I'm programming have to cohabit with the rest of present scripts in the user's client.

Concerning modifying global options. I think the same way, local behaviour shouldn't change global behaviour, but as I told you... find no other way to do it. The same thing could be said about commands which allow changing global options in mIRC. The "correction" of having such commands available is another question as, for example, as long as a single script can change the global DCC aception policy in mIRC.