Hello,

The SendMessage Windows API can be used to send alerts from a second application to mIRC, with a memory-mapped file examined for the contents of a message.

mIRC should also be able to generate SendMessage requests, in order to alert other applications to the presence of new content in the memory-mapped file.

Is there some way to write to the mapped file and call SendMessage using the Windows DLL's? A custom DLL to accomplish it would not be difficult, but it does make sharing scripts more difficult.

The implementation might require a dedicated thread, in order to properly acquire the lock on the file for synchronization purposes, but the WaitForMultipleObjects API might be sufficient.

Other alternatives would be setting a Windows Event object to the signaled state, but the mapped file still needs to be written to. Named pipes offer another alternative.

Sorry, but your reasoning makes little sense to me. You are describing a situation where an external application has been programmed to communicate with mIRC, using an entirely mIRC-specific communication method. In that case, why couldn't the application itself just come with a DLL for use by the corresponding mIRC script?

DLL's are less trustworthy than other methods. In fact, DLL's are untrustworthy if they're compiled already. And while all your users have Windows, and C compilers are free, not everyone has one, needs one, or knows how to use one; so DLL's are less useful if they're not compiled. Therefore it's difficult to share DLL's.

Trustworthy methods would be any IPC mechanism in a scripting language. It's not rare to find sockets in a scripting language library, but perhaps the ability to enter a GetMessage loop directly would be rare. So perhaps it might not be that widely applicable, but it doesn't seem that complicated either. Perhaps there are some hidden snarls in the source, and of course you can't just go adding every old thing.

DDE might seem more generic, but so long as the mIRC-side interface included the message number required by the other application, the difference is small and SendMessage is simpler for programming. Plus I was informed in a #mIRC channel that DDE is deprecated.

I'm not sure, but ISTM that SendMessage is a rather innovative mechanism. IIRC I haven't seen another application use it for IPC, and it would be nice if the capability were symmetrical for developing new applications.

Just out of curiosity, why must the contents file be memory mapped, and not use simple file read/write mechanisms?

So, to summarize, you don't have an actual use case for this, you just want this feature for the sake of "symmetry"?

And yes, you can always just use localhost-bound sockets to achieve what you want instead.

Not exactly, Mr. Sat.

I hadn't divulged my use case but I'll take you to have asked in your message.

I'm making use of a number of features of the Python language which I'm not sure exist in other languages, in particular the 'mmap' module, line 100, and the 'ctypes.windll' object on lines 107 and 115: http://home.comcast.net/~castironpi-misc/irc-0041%20mdi%20arrange%20mirc%20py.py

The script queries the specified window handle (line 92) of mIRC for currently open channel and query windows on the current connection and their state, and arranges them in a grid with the number of rows specified via the '/window' command, also filling in empty squares. Screenshot: http://home.comcast.net/~castironpi-misc/irc-0042%20mirc%20layout.png

I don't know other languages enough to know if the same functionality can be accomplished in them.

The next step would be to create a basic message loop to receive incoming SendMessage events from mIRC, in order to maintain state information in the program and not respawn a new instance every time. The message loop in Python is very similar to the window creation process in C using 'ctypes', as demonstrated here: http://home.comcast.net/~castironpi-misc/gui%2001a.py

The message loop could take a number of other forms, including sockets, named pipes, DDE, and COM, but SendMessage would seem to be simplest, if only mIRC could use it too.

Thanks for the opportunity to digress into mIRC applications in other languages than MSL. Python has a regular syntax and an extensive standard library. The language designers omitted any GUI package since a GUI library is such an enormous undertaking on its own, and concentrated on the language itself, and IMHO have done an outstanding job so far. MSL and Python each have features that the other doesn't; and IPC can offer the best of both.

Alright, I now see that this is indeed something you could want in this particular case. Then again, in this particular instance, can your goal not be achieved entirely in a mIRC script - thus not even requiring users of your script to install python?

Actually, sockets would be the simplest, since there is native support for this in mIRC and it doesn't rely on any Win32 specific extensions on the other end. You get lucky in python with a Win32 API library in the stdlib, but not every language has this. Sockets are the common denominator here-- they are also widely used and supported, so it should be super easy to get started with a socket connection to your python code.

Also, it sounds like you just want Python in mIRC. That exists as a dll, ironically enough. It's called Python4mIRC.

Or if you want to avoid a 3rd party dll, you could access a Windows Scripting Component that contains your Python code with COM.

You people have missed the OP's point entirely.

The OP's point was that mIRC is missing the ability to call the SendMessage API using a previously created memory mapped file. There are lots of implementation problems with this (mIRC would have to automatically keep track of the memmapped files for the response sendmessage-- this would actually be impossible without introducing a new event that contained such a context), but let's forget the implementation details completely:

- SendMessage is not a good arbitrary data transfer protocol. The receiving end needs to have a GetMessage runloop, which most languages don't easily support (.NET does away with GetMessage loops, hacking it in is painful; other languages like Python would require extra library code). SendMessage works for sending commands to mIRC because it is built with a message loop; it's easy to send stuff to mIRC, not as easy to get stuff from mIRC.

- Using a memory mapped file or named pipe directly would be better but still not ideal because it requires polling on the file/pipe to detect when something was sent. Ultimately you would need to create 2 pipes, one for stdin/out, and poll/write. mIRC probably doesn't need to expend these resources.

- Sockets require polling but you can easily detect when a new message was received (as opposed to simply seeing new data being written to a named pipe as part of a long message, or having to delete data in a named pipe to send a new message).

In short, adding the ability for mIRC to respond to SendMessages just wouldn't be a useful solution to the problem. As pointed out above, it requires the external program to know and handle message loops, which is uncommon nowadays. There are better ways to do this in general, namely, sockets, or even COM. Also, there is often a case-by-case solution; in this case, if the problem is that Python RPC is complicated, the solution is to use something like Python4mIRC or a Python specific IPC mechanism. If this were a .NET question, the answer would be COM.

FYI this was all pointed in the thread, which means nobody missed the point.

Ooops. Nevermind. I'm the one who missed the point.

BTW, what is the OP trying to do. Those links to source code lack any comments.

The "OP's point" was that SendMessage is just as useful for other applications as it is for mIRC; therefore the ability to emit messages is perfectly appropriate.