In the vast majority of cases, you’re probably correct. I was just a little surprised, I expected an event to be triggered even when the user selects the choice that is already selected. I don’t know if that’s how other GUI toolkits work, like the Java AWT or Swing toolkits. But I’m sure I can figure out a way to work around it.
I’m using dropdown lists in four places:
- Selecting an “effect” to be loaded into one of the 8 “slots”.
- Selecting a MIDI device.
- Selecting an audio device.
- Selecting an IP address to send OSC messages to.
In the first two cases, “none” is an appropriate option, so I made that the default. In the third case (selecting an audio I/O device), “none” doesn’t really work. Pure Data allows the user to select “none” for a MIDI device if no MIDI device is available or Midi isn’t required by the app, but it always expects an audio device to be selected, "none"isn’t an option. Pure Data was designed specifically for audio processing. I suppose it could be used to develop apps that don’t involve audio at all, but I’ve never heard of any.
When my program starts up, it polls the other computer (which defaults to “localhost”, 127.0.0.1) to load the audio and MIDI dropdown lists with available devices. This seems appropriate as a default choice for the OSC destination. It’s the third case, selecting an audio device, that’s a bit problematic. I don’t want to make “none” the default, or even include it in the list at all, since Pure Data won’t accept it. So I have to arbitrarily choose one of the devices returned by Pure Data as the default audio device. When the user chooses an audio (or MIDI) device, I send an OSC message to Pure Data to tell it that this device has been chosen. It appears in my testing that the first device in the list sent back by Pure Data is also the default device in Pure Data, but I don’t know that this is always the case. So I wanted to send an OSC message to Pure Data, even if the user chooses the device that has already been chosen. This is only an issue when the program first starts up, because if the first device in the list, the default device, isn’t in fact the device that was chosen by Pure Data at startup, the user is liable to think that the default device is being used by Pure Data, when in fact some other device is being used, which could be confusing (Pure Data won’t complain, but no sound will be heard).
I hope all this makes sense. I’m not asking you to change the behaviour, I just wanted confirmation that this is the way your library was designed to work. I think I can find a work-around for it.