I've put up a [url=http://www.mediamonkey.com/wiki/index.php/Python_event_handling]sample Python script[/url] in the wiki that demonstrates event handling from an external program.

Whoops; my mistake. Python has a "MakePy" utility which builds Python wrappers for COM objects, and I had failed to rebuild it for MM4. So, the MM3 interface was still being used, which of course did not have the support for the event objects.
I've rebuilt it now, and it's working fine. Sorry for the noise!

Yes they work fine with C#, but only in MM4. I have not tried with python. I'm not too familiar with python, using it only when I need a script in EventGhost.

The short Python demo program I provided [url=http://www.mediamonkey.com/forum/viewtopic.php?f=19&t=29201#p298079]uptopic[/url] does not work with MM4 1408.

@jitterjames, have you had any luck getting events to work with MM4?

Since version 4.0 is very close to being released, we probably won't make any 3.x updates. This one doesn't look like a good candidate anyway, since it would require quite some testing in order to rule out regressions.

Jiri

that's wonderful. thanks. Does this mean that there will be no more updates for MM version 3?

If there are future updates, would/could this issue be fixed in MM3?

yes

does this mean that events should now work with version 4.0.0.1384 (Developer build) found here:?

http://www.mediamonkey.com/forum/viewtopic.php?f=6&t=54426&p=300010&hilit=beta#p300010

cool. good news. Thanks!

Thanks all for the feedback, I have reviewed the implementation and fixed the issues with MM server created from external applications - it will be fixed in the next MM 4.0 build.

Jiri

public static void sendMessage(string mymessage, int port)
        {
            UdpClient udp = new UdpClient();
            
            IPEndPoint groupEP = new IPEndPoint(IPAddress.Parse("255.255.255.255"), port);
            
            byte[] sendBytes4 = Encoding.Default.GetBytes(mymessage);
            udp.Send(sendBytes4, sendBytes4.Length, groupEP);
            udp.Close();
        }

I don't know what more I can tell you. It works perfectly with VoxCommando and EventGhost and you have access to the listener code used in both cases.

Here's the code that sends the udp message in c#
[code]
public static void sendMessage(string mymessage, int port)
{
UdpClient udp = new UdpClient();

IPEndPoint groupEP = new IPEndPoint(IPAddress.Parse("255.255.255.255"), port);

byte[] sendBytes4 = Encoding.Default.GetBytes(mymessage);
udp.Send(sendBytes4, sendBytes4.Length, groupEP);
udp.Close();
}[/code]

I'm still not able to get that working. What protocol do you specify when you create your outgoing socket? I selected UDP in my receiver socket.

However, I don't need it. I've created a named-pipe implementation that works pretty well. I'm still bugfixing and polishing, but it's solved my basic problem. I can now write a Python script (or really, any program) that can attach to the pipe and get a string identifying each event as it happens.

The named-pipe is implemented as a COM object (which needs to be registered), also written in Python but it gets loaded in-proc by a VBS; then each event-handler just dumps the string into the pipe. If there's no client on the other end of the pipe, nothing gets written.

WShell.Run("""" & SDB.ApplicationPath & "Scripts\Auto\udpsender.exe"" 33000 " & strEvent),0,1

void udpListenerThread(object sender, DoWorkEventArgs e)
        {                              
            int listenPort = 33000;
            try
            {
                UdpClient listener = new UdpClient(listenPort);
                IPEndPoint groupEP = new IPEndPoint(IPAddress.Any, listenPort);

                while (true)
                {
                    byte[] bytes = listener.Receive(ref groupEP);
                    string rawtext = Encoding.ASCII.GetString(bytes, 0, bytes.Length);

                    udpresult = rawtext;
                    backgroundWorkerUDP.ReportProgress(10);
                }
            }
            catch
            {
                voxLogger.writeLine("error opening UDP listening port.  It may already be in use.");
                return;
            }
        }

it broadcasts to all ip addresses. you should be able to listen on any ip address as long as it belongs to the adapter which is on the same lan. You need to be listening on the correct port though. In the case of my example:
[code]WShell.Run("""" & SDB.ApplicationPath & "Scripts\Auto\udpsender.exe"" 33000 " & strEvent),0,1[/code]

the port is 33000. Of course you can change that to something else if you want.

For example python code look at the broadcaster plugin for eventghost. It works with my MM script and the udpsender.exe

this is my c# code:
[code]
void udpListenerThread(object sender, DoWorkEventArgs e)
{
int listenPort = 33000;
try
{
UdpClient listener = new UdpClient(listenPort);
IPEndPoint groupEP = new IPEndPoint(IPAddress.Any, listenPort);

while (true)
{
byte[] bytes = listener.Receive(ref groupEP);
string rawtext = Encoding.ASCII.GetString(bytes, 0, bytes.Length);

udpresult = rawtext;
backgroundWorkerUDP.ReportProgress(10);
}
}
catch
{
voxLogger.writeLine("error opening UDP listening port. It may already be in use.");
return;
}
}
[/code]

@jitterjames: I'm trying to use your udp scheme, but I'm not getting the messages to my port. I can reach it from another Python program.
What IP addr does udpsender.exe send to? I'm not seeing data come in on 127.0.0.1 nor on my ethernet adapter.

[quote="mcow"]
@melloware, I don't think you're using the term "out-of-proc" correctly. The app code may reside somewhere random, but once MM instantiates the object, it's in-proc—that is, the code is running within the MediaMonkey process.[/quote]

You are correct it is in-process inside the MediaMonkey process which I stated 3 posts above. quoted:

[i]I based my MonkeyTunes plugin on the same architecture (in C# instead of VB) and it works great. It is a lot of trouble to go through but it is the only way to get [u]in-process[/u] calls in your plugin. Since the script instantiates your C# app as a COM object the COM runs [u]in-process[/u] with the main MM process and thus is handed the events from the SDB object already running in the script engine.[/i]