A couple of AudioDeviceSelectorComponent problems

General JUCE discussion
1
  1. The “show this device’s control panel” button for the ASIO drivers results in an unhandled exception. As soon as the mouse cursor enters the button, the program crashes. It’s just MouseOver, no clicking is necessary. When debugging, the debugger stops at line 905 ([color=#BF0000]data.shrinkToNoMoreThan (numUsed)[/color]) in “juce_Array.h”:

[code] /** Reduces the amount of storage being used by the array.

    Arrays typically allocate slightly more storage than they need, and after
    removing elements, they may have quite a lot of unused space allocated.
    This method will reduce the amount of allocated storage to a minimum.
*/
void minimiseStorageOverheads()
{
    const ScopedLockType lock (getLock());
    data.shrinkToNoMoreThan (numUsed);
}

[/code]
And it is not just my own program; it happens in the pre-built Juce demo as well. I wouldn’t have thought, that MouseOver does much here. Any idea what is happening?

  1. The Midi In & Out selectors only appear when DirectSound is selected. When I select ASIO they vanish completely - in my own program, not in the Juce demo. I can’t figure out why they appear in the demo and not my own program. Any ideas?

  2. The “show this device’s control panel” button only appears for one of the two SoundBlaster ASIO drivers, not the other SB driver and the generic Creative driver - again only in my own app. and not in the demo, where it appears for all three drivers. Again, any ideas?

  3. “show advanced settings…” always appears, even when hideAdvancedOptionsWithButton=false. Again, the demo behaves differently. Why?

2 & 3 may have the same cause. The lower edge of the one visible “show this device’s control panel” button looks like it has been cut off - possibly by an invisible Midi in selector.

Soundcard is Creative’s SoundBlaster 2 ZS.
Windows is XP SP2.
Juce is v1.51.
Compiler is VS 2008 Express.

[color=#BF4080]EDIT: Never mind 2,3 and 4; I found the cause: a dumb mistake on my part. Sorry![/color]

2

I can’t reproduce that, the button works just fine for me. It sounds like some kind of dangling or null pointer problem, but I can’t see how it could happen… Any more clues from the debugger? Obviously it’s not the Array class that’s the problem, so what’s the stack trace at that point?

3

OK, I’ve also found the culprit of #1. I have a program called Styler running to improve the looks of ugly WinXP. When I close that the button works as intended. It seems StylerHelper.dll has something to do with it, although I don’t know exactly what it is, that happens.
[attachment=0]Call stack.jpg[/attachment]

Styler creates a drop shadow behind windows. I wonder if it is some sort of conflict with Tooltip windows, since they themselves create drop shadows.
[color=#804080]EDIT: Yep, that was it. When I disable Styler’s drop shadows, everything is OK. Double drop shadows are apparently a no-no. Pity - I like the drop shadows :cry: [/color][color=#804000]Strange, though, that double drop shadows are fine with menus and alert windows. No crash here. :?
Hmm, even weirder: tooltips with double drop shadows are OK elsewhere :? :? I don’t get it.[/color]

4

So you link that dll into your app and it adds shadows…? What could possibly go wrong!

5

I don’t link it myself, it is being linked somehow. And what could go wrong? I don’t know, you tell me, you know Juce infinitely better than I do.

In the pre-built Jucedemo’s Widgets demo the “click for a popup menu…” button doesn’t crash the program, whereas the “show this device’s control panel” button of the Audio demo does. Two text buttons, each with a Tooltip. One crashes the program, the other doesn’t. What’s the difference between these two buttons? Again, Styler’s drop shadows seem to be the key to the malady.

6

So your exe is running along, unaware that this hacky DLL is secretly creating new windows and mixing them in with the ones that it expects to be there… I can’t even begin to count the number of convoluted ways that could produce an epic fail!

I’ve no idea why your buttons would behave differently, but since the DLL is crashing there’s not really much point in trying to figure out why - if it’s having internal problems, then you can’t expect its behaviour to be predictable.