Here's my wishlist (some feature suggestions may have been made already, but I couldn't find them. Nor do I need to now that I've posted).

Error Handling:
Global error handling - all errors call an event which you can then handle.

Keyboard:
on keydown/keyup events for all windows.
Supposing the above isn't added; the ability to bind scripts to any key, rather than just F*.
Ability to catch the Alt key with $mouse.key; if ($mouse.key & 8) ...

Interface:
Ability to use html/hex colours locally (mIRC will interpret, but not send the colour codes).

Picture Windows:
/drawgradient - for drawing gradients.
$incircle(x,y,w,h,w,h) - check if you're inside a circle (maybe $inpoly can be used for this? I don't know because the help file seems vague on this topic).

Sounds:
/splay - ability to play audio streams.
$sound() - gets info from more filetypes (aac, midi, mp2, mp3, ogg, wav, wma, etc).
Audio tag editing commands.

Switchbar:
Ability to change the bitmaps on it.

Toolbar:
Ability to change the buttons on it, not just bitmaps.

keydown/keyup event handling for non custom windows would be nice.


I would have to concider this complete overkill and unneccersary bulk, mirc is not a sound editor. Such scripting function are very specific to just one purpose, music players/organisers. I think this should be left to a dll.


Do you mean the buttons on the switchbar? because the background can already be changed.


Probably another thing better left to dll's, of which there are many for this function already.

Nor is it a text editor, but we have /write and /f*.
Nor is it an audio player, but we have /splay.
Nor is it a graphics program, but we have /draw*.

The "mIRC is not a <insert program here>" argument is getting old. mIRC has long been more than just an IRC client.



Dlls are all well and good, but try using 10+ different dlls to get the functionality you need. Your project becomes unmanageable and a task whore.
Any other method to do something like this is very sluggish (/bwrite, for example).



I'm talking about the icons for each type of window (channel, status, query, channel list, notify list, dcc send, dcc get, etc).



So I should download a dll (most of which are bloated with other stuff I don't need) to add an extra button to the toolbar? That's overkill.
This functionality is also built into the toolbar control itself afaik.

First of all your argument examples are void, what you requested was something VERY specific, and are useless for anything other than editing some audio file. Now look at the examples you gave, they are all things that can be used for a wide range of scripts and are extremely useful functions. This is the basis of my opinion. Furthermore, mirc IS just an irc client. Do not mistake the scriptability for sounds and the draw commands for something they are not. fex /draw* is useful for many things, such as creating fancy picwin dialogs.


You can do as you wish, i have no objection to such an improvement.

Personally, i dont see why people would want such things as tag editing scripts in mirc. Obviously you find this useful, but i doubt there are many others. So why bulk up mirc with something so specific that very few are going to even look at let alone use.

As for dlls: If your frustrated with bulky dll's when all you want is one function, then maybe have a go a writing your own. 10+ bulky dll's? Tag editing script? internet browser? some other non irc related thing? Maybe at this point you should realise it is not an operating system and start treating mirc as the irc client it is.

/splay is useless for anything other than playing some audio file. What's the difference?



No it isn't. It's an IRC client with a fairly powerful scripting language that has gone far beyond existing just to extend/improve your IRC experience. Sockets, COM support, dll support, picture windows ALL have nothing to do with IRC.

Many people use mIRC scripting as their platform of choice for writing hundreds of non-IRC related things, and they do it sucessfully.

/draw* does nothing more than let you create and manipulate windows with shapes and graphics on them. If you want to write a slow GUI using the mouse events picture windows can capture then be my guest.



I know a lot of people that would gladly use them. I'd imagine that anyone that's written an audio player script for mIRC would've liked to add ID3-tag editing to their scripts.
Besides, there are other things in mIRC that aren't used by many people at all, in my 3-4 years of helping on several scripting sites and IRC I can't recall a single question about the voice commands (/help voice commands).



Although I could most likely write my own (in this situation), I use mIRC scripting for its simplicity, as soon as I have to start programming to get things done it stops being fun.

/splay can be very useful for creating various error/warning/etc sounds in scripts. It can be used to create specific notices to you when something happens rather than using only beeps. Etc. Yes, it's used more often for playing music or putting sounds into games and other non-IRC scripts. But, it is still useful for IRC-related scripts.

As for the DLLs... I have to agree that if you need so many and only need a piece of each one, then you really should go and make your own DLL to do those things. It may not be as fun for you, but then you don't have to deal with all those DLLs. That's your choice, though. But, if you choose not to just because it's not fun, you can't really complain that you have too many DLLs.

The ID3 tag editing could be useful... Most ID3's I've seen aren't correct, so it would make editing them much easier. And, it could be easy to script something to download all the appropriate information off the internet and automatically insert it into the tags. But, again, a DLL would probably handle this much more easily than trying to add such a feature to mIRC itself. And, I believe I remember seeing a DLL to do this already.

As a note on your logic... "mIRC has all these extra non-IRC features already, so why not add more?" ... At some point, we have to choose to make a line that isn't crossed. If we use that logic, mIRC will grow into a very bulky program that tries to do everything every other program can do. As far as I'm concerned, new features are wonderful... BUT, we need to add only the features that enhance IRC, make common scripts easier to write, or is needed by, or will be used by, a majority of users. If we start adding features just because we can, then it just ruins the program.

Adding toolbar buttons the the mIRC toolbar could probably be done through a DLL if mIRC doesn't owner draw it himself. If I recall, someone already attempted that and failed to achieve it. The best way has always been to replace mIRC's Toolbar with your own.

Now with the subject of DLLs, the main problem is anybody is able to take the source from someone else to make their own. but when you have many DLLs that touch the same subject, conflicts arise because people that build them for themselves are very narrowminded in thinking that other people won't add over it. A simple example is subclassing windows, most DLLs that do the work don't release windows properly and you see the inevitable "crash" on exit or on unload. The windows API lets multiple subclassing occur and if everyone releases peoperly there shouldn't be a problem. The other problem that arises in subclasing is that it's a chain, the last one sublassing being the first one called. If this DLL blocks the API message from being sent down the chain to the other windows, you have lost some functionality in the other DLLs. It's all a matter of order in this case.

I love extending mIRC's possibilities with DLLs as most of my recent projects involve mIRC DLLs but I can't commit to have all my DLLs be compatible with all the other existing ones especially when those don't respect basic API procedures (and trying to be compatible with every each and one would be a nightmare). I tend to try to make my own compatible to themselves for a start.

I am not a skilled programmer, I only have basic knowledge.. and compiling several dlls into one isn't a wise practice when I don't know how each one was made.

I complain about the amount of dlls I have to use because the effort required to implement the features of certain dlls would be trivial at best for an accomplished programmer such as Khaled.



I don't know if you noticed but none of the suggestions I make are really asking for more features unrelated to IRC, they're asking for the features that exist already to be extended (eg: adding ID3 tag editing would be extending mIRC's existing sound support, as opposed to asking something completely new, like OOP).

I don't know that it really is adding to /splay to have ID3 editing. But that's just me. As I said, I think it would be useful for some people. But, I don't know that it would be added as I think the % of people interested in it who would use it for more than just "to see how it works because it's something new" would be too small to warrant it. So, I'd stick to a DLL. But, who knows... maybe it would be added.

And continuing on the point of DLLs, some are written in C++, others in Delphi and even in the C++ category, some use pure Win32, some use MFC and some use undefineable code style which is really hard to extract what you need to modify except the DLLs where it's a simple API call just taken from the help file and put into a DLL.

Just to clarify the point with /splay, while it is used commonly in audio players and other non-irc related scripts, it was infact implemented for irc-related reasons. Custom alerts on certain events fex. Since i can see no irc-related use for tag editing, this is again the reason behind my opinion not to add it.

mIRC does have a fairly extensive irc-related scripting engine, but it should remain as such and not try to be a programming language. This is why support for com/dll/etc was added, so you can add extended non-irc related functions to scripts.

I don't know if you meant sound support in general rather than /splay so sorry if it seems like I'm being pedantic but... I said adding ID3 tag writing would enhance mIRC's existing sound support ($insong, $sound(), /splay), not just /splay.

How do you know this?
After a quick browse through versions.txt I'm more inclined to believe that /splay was implemented for general purpose sound playing, rather than just IRC-related events.

Before /splay was implemented there was a /wavplay (maybe /playwav) command which only played .wav files, then /splay was added so you could play both .wav and .mid, a couple of versions later mp3 support was added to it along with the on mp3end event and the $mp3() identifier.

Regarding $incircle, you can use this in the meantime:


Syntax is $inellipse(X,Y,x,y,w,h)
Checks whether point X,Y is inside the ellipse (or circle) x,y,w,h. For a more legible and flexible (and less optimized) version of the above, as well as info on how it works and examples, check this out.

Thanks.
I already had an $incircle identifier made by someone called Enigma:



$inroundrect will be very handy though, thanks

Well first of all i said irc-related reasons, for use with things such as events. To create custom alerts and so on. Secondly, thanks, you just proved my point and contradicted yourself, well done.

In any case i wont reply to this thread anymore, because at the end of the day it doesn't matter. While i would prefer that commands, events and identifiers that have absolutely no forseable irc-related use not be implemented; for simple reasons such as they would be used by an incredibly low minority, the useless bulk continued implementation of such functions would add and the fact that the purpose of the mirc scripting language is to allow customisation and enhancement of a users irc experience not try to be a programming language for dummies. When it comes down to it the choice is entirely at the developers discretion, and he will make a decision based on his own opinion.

At this point we are just wasting each others time, so lets just agree to disagree.

A very nice wishlist, all wishes are helpful and you can be sure that a lot of mIRC users would enjoy.
The keyup/keydown is great and I already saw this suggestion.
The $sound is perfect, mIRC needs to improve and not stop in wav and mid. Yes, we are in 2005 not 1995.