ComboBox PopupMenu setValue being often skipped

Hello everybody!

I have a question about ComboBox source code. In some plug-ins of mine, I still use a synchronisation scheme between the user interface and the parameters which relies on a Timer, to look for parameters that have changed because of DAWs automation and compare the state of some controls such as ComboBoxes and the PluginProcessor parameters. When something is different, a ComboBox for example might have its value updated.

At some point, I observed in some of my plug-ins using ComboBoxes that some user interactions were dismissed. I wanted to click on an item in a ComboBox, such as a preset selector or a component associated to any given AudioProcessor parameter, the click was detected, the PopupMenu diseappearing after the click, but the value being used in the ComboBox was still the same even if I asked for another one.

After some detective work, I realised that one of the reasons for this is that most of the user controls might update their value using sendNotificationSync, while in the ComboBox source file it happens there:

static void comboBoxPopupMenuFinishedCallback (int result, ComboBox* combo)
    if (combo != nullptr)

        if (result != 0)
            combo->setSelectedId (result);

        combo->testing = result;

with the default notification value being sendNotificationAsync.

In a very busy plug-in, in Debug configuration, the whole automation scheme creates the issue previously described quite often. What I discovered is that between the click and the ComboBox::Listener::comboBoxHasChanged call, the Timer might detect a difference between the actual state of the ComboBox and the processor, so instead of updating first the processor as expected, the ComboBox value is put to its previous value instead, and the user action can be randomly dismissed.

And with a hack in the code I was able to trigger a jassertfalse when this happens, which stops the plug-in execution quite often in Debug mode with my DAW attached to Visual Studio 2019. However, if I replace the default sendNotificationAsync with sendNotificationSync, this doesn’t happen anymore.

So here is my question: what is the best course of action to prevent my issue from happening ever again? Is it something that shouldn’t happen ever if I replace this Timer automation scheme with something based on Listeners? Is there any way to make the ComboBox change requests from the user notified synchronously instead of asynchronously?

Thanks in advance!