MediaMonkey forum

Posted: **Wed May 18, 2011 2:48 pm**

mcow wrote:Is there a bug filed about the faulty COM implementation?

I don't know if there is or not but you can reference this thread if you are going to file a bug.

http://www.mediamonkey.com/forum/viewto ... 19&t=45676

Or this one...

http://www.mediamonkey.com/forum/viewto ... 19&t=45923

Posted: **Wed May 18, 2011 2:49 pm**

@melloware: I see that I was sent slightly down the wrong path by your post here, where you talked about registering an out-of-proc app (and referred to the MonkeyToys thread). But now I see, it's not really out-of-proc.

Posted: **Wed May 18, 2011 2:52 pm**

mcow wrote:@melloware: I see that I was sent slightly down the wrong path by your post here, where you talked about registering an out-of-proc app (and referred to the MonkeyToys thread). But now I see, it's not really out-of-proc.

Sorry about that. Basically is a COM object registered out of proc by MM. Not the other way around. Typically have your Python App that registers for a COM object like Internet Explorer and can control it. Well since that does not work in MM you have to do the reverse and have MM register your COM object out of proc.

Posted: **Wed May 18, 2011 3:31 pm**

I don't know if an official bug was filed. At least one MM dev. knows about it but it doesn't seem to be a priority.

mcow: If you want to use Python, take a look at what Pako did with the MediaMonkey plugin for eventGhost. If you have any questions about it you could ask him on the EG forum, or he may be on this forum as well...

Posted: **Wed May 18, 2011 3:34 pm**

OK, I submitted this ticket:
http://www.mediamonkey.com/support/inde ... etid=11998
We'll see if it becomes a bug or is updated with an existing one. (Is it just me or is that Ventis bug interface very weak? Searching for stuff there is very difficult. Of course, I don't have an account there...)

@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.

@jitterjames: thanks for the pointer to eventGhost, I will look at it. I may also steal your UDP-broadcast scheme.

Posted: **Thu May 19, 2011 5:50 am**

mcow wrote: @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.

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

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 in-process calls in your plugin. Since the script instantiates your C# app as a COM object the COM runs in-process with the main MM process and thus is handed the events from the SDB object already running in the script engine.

Posted: **Wed May 25, 2011 11:50 pm**

@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.

Posted: **Thu May 26, 2011 6:43 am**

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: Select all

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

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: Select all

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;
            }
        }

Posted: **Fri May 27, 2011 10:30 am**

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.

Posted: **Fri May 27, 2011 11:08 am**

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: Select all

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();
        }

Posted: **Fri Jun 03, 2011 4:42 am**

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

Posted: **Fri Jun 03, 2011 5:52 am**

cool. good news. Thanks!

Posted: **Sun Jun 05, 2011 8:20 am**

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

http://www.mediamonkey.com/forum/viewto ... ta#p300010

Posted: **Sun Jun 05, 2011 1:15 pm**

Posted: **Sun Jun 05, 2011 1:41 pm**

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?

MediaMonkey forum

Events don't work with C#

Re: Events don't work with C#

Re: Events don't work with C#

Re: Events don't work with C#

Re: Events don't work with C#

Re: Events don't work with C#

Re: Events don't work with C#

Re: Events don't work with C#

Re: Events don't work with C#

Re: Events don't work with C#

Re: Events don't work with C#

Re: Events don't work with C#

Re: Events don't work with C#

Re: Events don't work with C#

Re: Events don't work with C#

Re: Events don't work with C#