gen_tray should be fixed

[Darkain]

i was randomly looking at the gen_tray example in the SDK, and i cam accross this:

int init()
{
config_read();
lpWndProcOld = (WNDPROC)SetWindowLong(plugin.hwndParent,GWL_WNDPROC,(LONG)WndProc);
do_icons();
return 0;
}

and then i looked in the quit function, and the subclassing wasnt released.

void quit()
{
config_write();
config_enabled=0;
do_icons();
}

i found this when working with an application other than winamp that loads winamp's gen plugins. in their implentation, the plugins are unloaded before the window is destroyed, but since the window is still technically subclassed after the plugin is unloaded and before the window is destroyed, any messages sent to the window at this point are trying to be sent to this unloaded plugin, and therefor crashes.

if we delete the window before unloading the plugins, i asumed this could cause other issues, such as a plugin that may save the current state of the player. that, and also, this prevents plugins from being loaded and unloaded on the fly.

i can fix the plugin in the local copy, but it would be nice to see the SDK updated as well.

[Darkain]

here is teh fix0r

void quit()
{
config_write();
config_enabled=0;
do_icons();
SetWindowLong(plugin.hwndParent, GWL_WNDPROC, (LONG)lpWndProcOld);
}

[shaneh]

I remember a sample from the SDK a while back which actually had comments along the lines that it wasn't necessary to unsubclass the window. Or perhaps it wasn't an official sample or I just imagined it?

In any case, this has become a problem with WA5.03. When gen_ff is unloaded, and the winamp windows are desktop docked, naturally it attempts to restore the desktop state.

However in doing so, it sends a DISPLAYCHANGE to the various windows. Depending on the order in which gen_ff is unloaded, this can have unfortuanate consequences for any windows that have been subclassed but the module already unloaded (ie crash). (Ive managed to fix it by renaming gen_ff to gen_zff). gen_ml (the media library) actually makes this mistake, it doesnt unsubclass the playlist window.

As you mention, the sdk/docs need to be clear that subclassed windows MUST be unsubclassed on quit. Ive made that mistake myself a few times because I didnt realise the importance of it.

[DrO]

Originally posted by shaneh
As you mention, the sdk/docs need to be clear that subclassed windows MUST be unsubclassed on quit. Ive made that mistake myself a few times because I didnt realise the importance of it.

unsublclassing should be done *always* and i believe it's mentioned in the ms docs about subclassing that it needs to be removed. i'll make a note of this and add it into the docs i'm trying to do for the sdk (along with everything else )

i guess people can be sloppy (i've done it at times but that's unsubclassing the wrong window )

-daz

[shaneh]

It should be done, if the window is sticking around. I'm sure I saw an gen_ example once that had comments saying it wasnt really necessary - but it could have come from anywhere i guess.

But I think its easy to assume that because the 'quit' API is being called, the message loop may have ended because winamp is about to exit. Obviously this isn't the case however.

[DrO]

Originally posted by shaneh
But I think its easy to assume that because the 'quit' API is being called, the message loop may have ended because winamp is about to exit. Obviously this isn't the case however.

i agree it is an easy one to forget to do at times, done it many times when i first started subclassing.

anyway the issue has been reported and should hopefully be fixed in the official version (updating my copy in a bit)

-daz