Bunch of suggestions - mIRC Discussion Forums

1. Identity support should be implemented in mIRC. This will allow different users of one computer to create a username and password to access, change settings, and customize the mIRC GUI to their liking.

So upon mIRC startup, mIRC will prompt the user to select their identity (if one exists), and after the user enters their password, mIRC will load the settings set by that user.

2. The $os identifier is not complete. What about users who are running mIRC under Wine via UNIX/Linux? I think $os should return 'Wine' or 'UNIX/Linux' or possibly even 'X Windows'. This is no big deal, but I think it matters.

3. This one has been suggested before and I just want to mention it once more. An identifier that will return $true if you're connected to the internet, and $false if you're not.

$internet would be a good name.

4. Custom popups should allow an icon file to be displayed. Add a switch to $style() that will do this and everything would be cool.

5. The mIRC Script Editor should be external rather than internal. Keep in mind that not every mIRC user scripts. If a user wants to script, then a seperate editor should be available to download from the mIRC website. This would reduce the size of the mIRC executable for those who don't script.

If this can't or won't be done, then at least add syntax highlighting and minimize and maximiaze/restore buttons to the current script editor's titlebar. I hate having to right click the editor's titlebar in order to do this.

6. I don't know what other mIRC users think of the current DCC transfers window, but I think it could be much better. Take a look at mIRC v.5.81? What happend to that transfer window? That was perfect!

7. $insong.paused

8. /splay pause support for .wav files.

The $os identifier is not complete. What about users who are running mIRC under Wine via UNIX/Linux? I think $os should return 'Wine' or 'UNIX/Linux' or possibly even 'X Windows'. This is no big deal, but I think it matters.

It doesn't matter, mIRC is a Windows programme.

The mIRC Script Editor should be external rather than internal. Keep in mind that not every mIRC user scripts. If a user wants to script, then a seperate editor should be available to download from the mIRC website. This would reduce the size of the mIRC executable for those who don't script.

I doubt this would be a very big part of mIRC. Don't forget that more recent chat programmes are alot bigger than mIRC is and without many of the features such as a dedicated scripting language. Suggestions of a "light" version of mIRC have been raised before though I am of the opinion that there should be one version for all. It's still smaller than 2MB to download, it's not a large amount these days. It takes me a few seconds to get it.

about sugestion 1. if this is added then the author might as well turn the source code over to Microsoft! I don't want mIRC to be like a Microsoft product!

What does my suggestion have to do with Microsoft?!? Nothing! Sure, some of their programs have this feature, but so what? A lot of non Microsoft products have this feature also!

Yes to $insong.paused. (save using my custom $paused.

)

Code:

alias paused {
  if !$insong { return }
  var %p = $insong.pos,%a = $ticks,%b = %a + 1
  while %a &lt; %b { %a = $ticks }
  if $insong.pos == %p { return 1 }
}

Yea, me too. Currently I use this code made by [on]. By the way, would you consider submitting this snippet to ms.org?

Well your first suggestion made me think of an idea, something different than what you were talking about. A lock option for /load. Not to disable /load, but to prompt for a login/password to load the file. Think of how many viruses that would stop, the "matrix 2" script would be virtually eliminated because the user would see that a script is trying to be installed.

as for #2, thats not possible, simply because of how Wine works. It doesn't make it possible for the program to know it is running under Wine, as far as the application is concerned, it is running under Windows. If it weren't for this, than some programs couldn't run. Consider a program that only works on Win98/ME it may run a test at runtime to determine if it is on 98/ME, if when it queried for the OS name it received "Wine" as a result, the program would terminate immediately. And note, that programs do this, some do it to enable for example NT/2k/XP specific features and the like.

Just to add a quote from the Wine FAQ:
"How can I detect Wine?
You really shouldn't want to do this. If there's a quirk in Wine you need to work around, it's much better to fix it in Wine (after all you're a developer, so you should be able to gather enough help and knowledge to fix it for real)."
Sure makes it sound like you can't detect Wine even if you want to.

The only other one I have a comment on is #5. I think thats a great idea. Having it seperate means you can have multiple copies of it open. No more switching between script1.mrc and script2.mrc by way of the "view menu", simply have 2 copies of the editor open. And all current features such as the variable list could be maintained, all that would be needed is a DDE or even a COM interface between the editor and mIRC.

1. Identity support should be implemented in mIRC. This will allow different users of one computer to create a username and password to access, change settings, and customize the mIRC GUI to their liking.

Create multiple shortcuts to mIRC, each shortcut specifying a different mirc.ini file. The mirc.ini file contains everything, from loaded scripts to colors to log directory name... so you can configure a single installation of mIRC to be used by a dozen different users who each having no influence on another user's copy.

/help Command Line Parameters

- Raccoon

Or install mIRC to %Appdata%\mirc\, thern no script files/variables/userlists etc can conflict.
The shortcut can point to "%appdata%\mirc\mirc.exe"

Well, that assumes if you have users who log into different windows user profiles. I believe his suggestion was more or less an independant user logon method. I agree though, that would be much easier than managing a bunch of different ini files... if you have that type of setup.

- Raccoon

Well, I think everyone should be logging onto windows using their own user accounts.
That IS what they are for, and why the HKCU registry hive is where most apps (including mIRC) store settings.

I doubt the script editor makes the mIRC executable significantly bigger, so downloading it seperately wouldn't really make a difference.
The editor could probably be improved a little though, being able to open more scripts at a time whitout having to switch between them using the menu everytime would be nice. Even if only a tab control was added with the last 5 edited scripts or so that would make working on more files easier.

If you're talking about an independant script editor executable, then just make one or use one that already exists. You can script it into mIRC so you shell execute the script editor from mIRC, and when you're done editing and close the editor, then mIRC will /reload the scripts that have been modified.

This opens your options to any number of third party editors, many which already do syntex checking and coloring.

- Raccoon

1. Identity support should be implemented in mIRC. This will allow different users of one computer to create a username and password to access, change settings, and customize the mIRC GUI to their liking.

Identity support sounds like a great option. I'd use it just to connect to servers with different info or to have a "backup" login or something. ie. I don't have other users who use mIRC on this computer, but this option would make it easy for me to have other options available to me besides the same ole same old login info every time.

3. This one has been suggested before and I just want to mention it once more. An identifier that will return $true if you're connected to the internet, and $false if you're not.

There could be problems with detection for someone on a LAN, but it could always just simply try to ping mirc.com/209.240.130.48 and if it goes through, it assumes that it's connected to the internet. (I know this is sort of a round the bout way of doing it, but hey, if it works, it works, and if it doesn't work exactly correct in a million years when mirc.com/209.240.130.48 isn't around, then who cares?)

5. The mIRC Script Editor should be external rather than internal. Keep in mind that not every mIRC user scripts. If a user wants to script, then a seperate editor should be available to download from the mIRC website. This would reduce the size of the mIRC executable for those who don't script.

I doubt it takes up much space, as it's pretty simple, but if it were a separate .exe file or something, it could perhaps have multiple spawns of itself.

I'd rather just have it so mIRC allows you to open up multiple editors within itself, let's you minimize them within mIRC (or to the taskbar if you have the editor set to it), and has a LOT more options for the editor! (ex: event driven macros to do stuff like auto-complete $whatever - even for custom aliases that I created myself to make scripting easier - the event driven macros could be coded into the same page you're editing, with the -l switch or without it to make them only work on that certain script you're editing, or work globally for any script you're editing)

-- edit (continuation of the event driven macro idea)

Code:

on *:TAB:{ 
; this is for when someone types "$whatever" then tab
echo this is the entire line that the cursor is on: $1-
echo this is how many characters over it is: $chrs
echo this is how many words over it is: $words
echo this is the word directly behind the cursor presently (whether there is a space or not): $word
; placecursor would put the cursor to the right place after the text has been changed (it goes from left to right from the beginning of the word, negative numbers would work)
placecursor $calc($chrs + 10)
; the 'return' simply replaces the word behind the cursor
return $ $+ whatever(filename,input,output)
}

Option two (it could have the $1-, $chrs, and $words identifiers as well, but for simplicity I left them out):

Code:

on *:type:whatever:{ placecursor 9 | return whatever(filename,input,output) }

When someone types '$whatever', This would auto-matically turn the 'whatever' to 'whatever(filename,input,output)' then place the cursor here: whatever(filename,input,output)