While working with the MUS xtra I constantly encounter a slightly
annoying occurrence and I hope to gain a bit more insight about it.

I create an instance of the MUS xtra and assign a reference for it to a
global variable. I then use the WaitForNetConnection, passing a specific
port number that I want to use.

As I am developing, I stop the movie to work on some part of the code. I
then restart the movie, running the script that instantiates the Xtra again.

I then immediately see a "WaitForNetConnection" message come in:

[#errorCode: -2147216214, #recipients: ["Host"], #senderID: "System",
#subject: "WaitForNetConnection", #content: <Void>, #timeStamp: 0]

Typically you only see this message come in when another instance is
trying to connect via ConnectToNetServer, and the #content normally
shows the username, password, and movie string instead of being void.

This only happens after the first time I call WaitForNetCOnnection on
the same port. In a published piece, this would never happen. But as I
am developing it happens a lot. It really doesn't stop anything from
working either. I just want to understand.

Destroying the instance (by setting variable to 0) doesn't change
anything. It seems like once a movie opens a connection on a port, that
port remains open until the movie is closed.

So if I understand, the first time WaitForNetConnection is called, the
Xtra opens the port if the port is not in use. The next time it sees the
port open and passes the message on to the WaitForNetConnection handler
I have set up regardless of where it is coming from. Is this right?

You have to set both the callback handler and the instance to 0. Otherwise,
the instance is not being released.
Assuming gmux is and muxtra instance, and #mucb the single callback handler
assigned to it, try:
gMux.setnetmessagehandler(#mucb, 0)
gMux=0

"Dave C" <no@no.com> wrote in message
news:gbblln$cn5$1@forums.macromedia.com...
> While working with the MUS xtra I constantly encounter a slightly annoying
> occurrence and I hope to gain a bit more insight about it.
>
> I create an instance of the MUS xtra and assign a reference for it to a
> global variable. I then use the WaitForNetConnection, passing a specific
> port number that I want to use.
>
> As I am developing, I stop the movie to work on some part of the code. I
> then restart the movie, running the script that instantiates the Xtra
> again.
>
> I then immediately see a "WaitForNetConnection" message come in:
>
> [#errorCode: -2147216214, #recipients: ["Host"], #senderID: "System",
> #subject: "WaitForNetConnection", #content: <Void>, #timeStamp: 0]
>
> Typically you only see this message come in when another instance is
> trying to connect via ConnectToNetServer, and the #content normally shows
> the username, password, and movie string instead of being void.
>
> This only happens after the first time I call WaitForNetCOnnection on the
> same port. In a published piece, this would never happen. But as I am
> developing it happens a lot. It really doesn't stop anything from working
> either. I just want to understand.
>
> Destroying the instance (by setting variable to 0) doesn't change
> anything. It seems like once a movie opens a connection on a port, that
> port remains open until the movie is closed.
>
> So if I understand, the first time WaitForNetConnection is called, the
> Xtra opens the port if the port is not in use. The next time it sees the
> port open and passes the message on to the WaitForNetConnection handler I
> have set up regardless of where it is coming from. Is this right?

You were of course right. That did the trick. I have never seen that
documented anywhere. How in the heck did you know that?

> How in the heck did you know that?
Case this wasn't a retorical question,
A combination of trying (back in the day) older and newer documented methods
that didn't work, reading between the lines, and quite some experimenting,
from what I can recall.

"Dave C" <no@no.com> wrote in message
news:gbc0ud$p7t$1@forums.macromedia.com...
> You were of course right. That did the trick. I have never seen that
> documented anywhere. How in the heck did you know that?