I have an idea for mIRC

First: sorry, I am Hungarian, and I have speak english a little bad...

I think so the object-oriented programming is needed for drawing ("make graphic objects then handle it":]), and more for playing sounds. The scripter would make sound-objects, which is differently playing, can be set to repeat mode (which repeats the sound without pause), can queue files to it, can seek, can stop, can pause, etc, etc...

If you creating a script which is drawing (with the /draw commands), and refreshes the image, you need to clear the old image, redraw all the lines, rectangles, and everything, but it very bad for games or animations (or other things) and it very-very slows down mIRC. But if the scripter would make graphic objects (an object, which have a name, maked using /draw commands, and then "groupping" them), can move, resize, delete, etc.:)

Or not ?

I know that you can already do what you are talking about with sounds. My own mp3 script handles all of that easily, though it does not use a generic "object" wrapper as an interface in the classic sense. If you like, you can modify your scripting style to kind of emulate or copy the style used by OOP (Object Oriented Programming) coders. In some respects, mIRC is already object oriented. It has windows you can find out information about its properties ($window(windowname).property). Some of its methods might be blocked from user control (depending on window type) and some might not be blocked at all. Certainly, the remotes are all events that you can code to. With the new Signals we can use, you can emulate RaiseEvent and define your own events. Encapsulation is basically how scripting works anyway; the users don't know about your data structures or access methods, nor do they care. Within limits, you can do inheritance (if you've scripted it for that). With a little imagination, you can do polymorphism (halting an event loaded earlier in the script order and then using on &*:EVENT to halt any following events from firing too). Objects, properties, methods, events, encapsulation, inheritance and polymorphism; that pretty much covers OOP.

Since I have never bothered to code any kind of picture window game, I know little about the /draw* commands. There might even be a slick way to do these.

You forgot constructors, deconstructors, and serialization. All three of which are pretty crucial to OOP IMO.

Although you can surely simulate objects to a wierd extent, you certaintly don't have real ones, nor do you have anyway of offering public/private functions to the class.

True (or even half assed) OOP is about as far fetched in mIRC as a Linux port atleast that's my feelings about it.

I speak about if you play a sound, and then you play another sound, the second sound stops the first. That's a problem.

Example:
You have a full script, with event sounds, and a player. The player actually plays a song, and an event is happening (e.g. a kick), the song is stopping. And if the script writes it out...
My script are opens a little picture window when the player plays a song. The song's title, lenght, position are writed out into the window. And if the event...;) for example, the window:

Playing Eiffel 65 - Blue
(somebody kicks somebody, the text is changing to...)
Playing Kick.mp3

..and the user is thinking "oh, what [censored] is this script! that's buggy!"

That doesn't require mIRC to have objects though, that's just a case of maybe setting a couple of variables and using /splay properly. All those things you mentioned in your first post (queue, pause, stop, seek) are built into /splay, it doesn't require objects to use them - just a filename.

As for the /draw commands, well no mIRC isn't exactly great for making games in. Layering might be a simple way to do what you want (the ability to draw items on different layers and then move that layer independently), I dont use the /draw* commands all that much though so it's possible that something similar (or better) can already be acheived.

Oh, my god )

So...

I known so mirc already object-oriented... but at sounds, only 3 objects have: mp3, wave, and midi. I known so can queue stop pause (etc.), but, I speaking about the /splay command would make different objects, which differently playing, and can differently stop, pause, queue etc. Example:




)

Nice, people are using mIRC integrated scripting feature as a all-purpose scripting language...

mIRC was designed to chat, not play music, or games, etc. The scripting language was added so to allow you to change or add functionality into the program, not to change the goal of the program.

If you want to develp games, mp3 players, etc, why don't you go and learn a real programming language and develop and applications under Windows, not under mIRC ?

I mostly develop in mIRC because it's fast, easy, easy to debug, and a good way to test things, make prototypes, etc...

For instance, I've turned my old computer in to a voice activated MP3 sound system using mIRCs mp3 & voice recognition functions, all without having to learn the issues behind playing mp3s or how to translate sound patterns in to words

I'm probably gonna get flamed for this, but here goes... If mIRC was not designed to play music, why is there /splay, $inwave, etc? How could you be so sure what mIRC was designed to do without the ability of reading khaled's mind?

Was Microsoft Word designed to display multimedia files? No. Can you embed them now? Believe it.

Ever tried to IRC through a Telnet connection or a raw socket? Not impossible, once you get the hang of it. Years and years ago, that's what people actually did. They Telnetted into an IRC server and chatted that way, using:

• PRIVMSG #PartyHouse :Last night's bingo party was fantastic.
  NOTICE Jarrko :No, I don't know where your wife put the eggs. Did you check under the bed?

It looked much the same as chatting would if you chatted from the @Debug window (without all the pretty colors). Along came mIRC for Windows. Now you could make channel text for one channel go into its own little window and PRIVMSGs from one nick would go to their own window. Fantastic, but it'll never catch on - too many little windows all over the place, who could keep track of them all? After all, who could possibly need more than 640K RAM?

• [Fast foward to today]

OK, so I've got my clients database connected to my web page which I can update from anywhere in the world. This includes through mIRC (using $com) while I listen to my favorite MP3s I've downloaded (from wherever *cough*). My mIRC can also automate checking different things I want to keep on top of, like current stock quotes, weather conditions, etc. so I am able to continue chatting up this hot chick from Finland who knows more about Windows API calls than I do!

The point of all this is that mIRC did not start off as the program it has developed into. It is constantly under revision and upgrade. The scripting language has matured along with the basic IRC client interface to allow you to integrate more functionality with your normal IRC experience. (We got While loops not all that long ago; we're still pestering Khaled to add multidimensional arrays, but he's putting up a rather valiant fight on that score.)