iTunes complains that "one or more applications are using the scripting interface" when you quit

[ben-xo]

Expected:

• iTunes quits straight away

Actual:

• iTunes does an error message

Is it a major performance drain to open the interface once per second rather than at load?

[VorTechS]

Sorry, mis-understanding. Possibly not. I can check that out.

[VorTechS]

Whilst there's no performance drain on the iTunes COM library, even connecting once a second means that the time between clicking 'X' on itunes and the Scrobbler checking for new content is going to result in the message appearing. Conceivably we could increase the time dealy for each media check, however there will always be the potential for this message to appear, and potentially that increase of timing could cause other problems (ie up to 'x' second delay noticing a track change').

The ONLY guaranteed way to solve this is if iTunes re-implements the event driven model. Aside from that, I think you're stuck with the message appearing, and it should be documented as a 'know side effect' of using the application.

[ben-xo]

I wonder if this is also contributing to #24 though…

[VorTechS]

There's a chance it might be. I've moved some code around inside the plugin to see if it helps. If not, perhaps when the COMException is thrown I could modify the timer interval for an initial [x] second delay to give the COM process a chance to close. It might solve both problems at the same time!

[VorTechS]

I've been experimenting early doors this morning, and whilst I can use the low-level window susb-sytem to scan the iTunes process for its windows / controls, not a lot useful comes back. I wrote an app. that returned a list of the handles and simulated a left mouse-click to see if I could activate the 'Close' button remotely. It was a long shot because the minimize / maximize / close buttons don't look like 'real' Windows menu control functions.

Anyway none of the controls returned by the window sub-system scan responded to a click by closing the form. (I could activate the mini-player, activate the search box / dropdow menu, and stop an itam from playing though). To confirm my hypothesis on the 'Close' button not bering real, I used the ControlMenu API to see if I could disable it - if the close button was real, it would work.

Surprise, surprise, it doesn't.

So. Moving on I decided to see if I could inject a button into the Ui, and managed to at least do that.

What does this mean? Well, we could hijack the buttons in the top right corner by sticking our own controls over the top, simulating what the buttons do and responding appropriately. This means when the user clicks on our 'Close' button, we can terminate the iTunes scrobbler plugin cleanly, and then close the iTunes windows.

However. This will be a learning curve, and whilst I've managed to stick the button on the iTunes window, I'm going to have to learn to 'skin' it, or inject a different control so that it looks and behaves like the existing buttons. (In my testing, I couldn't get a button to render 24 pixels by 24 pixels for example)

TL;DR - this is going to take time, IF, and that's as big if, you want to do this.

[ben-xo]

That's no use if you close iTunes using the "Exit" command in the menu, or right clicking on the task bar - i don't think that's the right approach.

We might be better off just polling iTunes less frequently (e.g. 5s to 7s)

[VorTechS]

I've updated the poll rate and reduced it to 5 seconds. It's still entirely possible to repeat the same behaviour if the poll timer is about to fire and you close the window. And on my slow laptop, this happens more often now! Hopefully faster machines won't suffer from the problem as much.