Changed how Spotify is found

[MicahArmantrout]

I realize this is not going to work if it is minimized to systray. I don't have time bandwidth right now to worry about that but I'd love to get to it. Thanks @Nachmore for the suggestion on how to make a better fix. Its not totally fixed yet but getting there

[GenesisFR]

I came up with the same solution myself. However, the original code will work even when Spotify is minimized:

private static IntPtr GetSpotify()
{
    return Win32.FindWindow("Chrome_WidgetWin_0", null);
}

You have to use a VS2017 tool called Spy++ to get the window class name. It changed from "SpotifyMainWindow" to "Chrome_WidgetWin_0" a month ago.

[edit]: my bad, didn't see you originally came up with the same conclusion.

[MicahArmantrout]

Yeah but there could be multiple windows with "Chrome_Widgetwin_0" it's not unique enough

[GenesisFR]

Now that is an interesting problem, matching a process name against a given window class name. I'm gonna code it tonight using EnumWindows().

My only concern would be how to set up a test environment with multiple windows that share the same class name.

[GenesisFR]

https://gist.github.com/GenesisFR/de0ad5710fb5eb221b5a239e819728bf

Usage: List<IntPtr> handles = FindWindow.GetWindowHandles("Spotify", "Chrome_WidgetWin_0");

In the case of Spotify, the correct handle seems to always be the first item in the list. If this were to change, you can just pick a different index. I learnt while coding this that there is no perfect solution to this problem. Also, this method takes around 1 second to execute on my computer, versus <1ms for FindWindow().

[GenesisFR]

Optimized the method, now it takes around 7ms instead of 1 second to execute. It was caused by Process.GetProcessById() (and to a lesser extent process.ProcessName) that was super slow.