Where is the per-item painting done for the combobox? + JUCE update

[elanhickler]

Need to customize painting for combobox pop up items. Where do you do it in code? I'll figure out how to edit it.

[elanhickler]

Also related, i need to change the display string of the combo box items without changing the preset format xml stuff. What decides what the xml gets, what decides the display string?

[elanhickler]

I need th popup menu to be bigger than the size of the component:

[RobinSchmidt]

Need to customize painting for combobox pop up items. Where do you do it in code?

it's in RTreeView::paint. the combobox is actually just a subclass of RTextField that can open an RPopUpMenu ...and this popup menu shows an RTreeView. i'm not sure if it will be easy to override the drawing behavior - because i think, it would mean that you can't just subclass RComboBox but rather you'd have to subclass RTreeView....but then my RPopUpMenu would have to use your subclass instead of my framework class. hmmm... in which way do you need to customize it?

[RobinSchmidt]

What decides what the xml gets, what decides the display string?

in the xml goes the string that you give the Parameter by addStringValue. by default, the combobox will just copy these strings for display when you do the assignParameter. but i think, it should be possible to change them later by setItemText. well,, that's the intention at least, but i didn't use this yet (as far as i remember)

[RobinSchmidt]

I need th popup menu to be bigger than the size of the component

hmm..ok - i think i need to add some code to the framework to make that possible....

edit: done: RComboBox::setMinPopUpSize - let me know, if it works

[RobinSchmidt]

i'm not sure if it will be easy to override the drawing behavior

or: i introduce a TreeViewPainter class the same way as i did for the sliders

[elanhickler]

Nevermind that, I'm using Juce PopupMenu, and you should be using that too. Please upgrade RS-MET Juce library which adds std:function in some places, makes all this stuff easier.

[elanhickler]

I updated your JUCE, take my pull request! It builds.

[elanhickler]

also download a new VST3 SDK! Save your old one for now, still trying to figure out how to get the files to be found. One sec.

[elanhickler]

Ok, you have to set your path to the VST3 SDK here:

[RobinSchmidt]

I updated your JUCE, take my pull request! It builds.

whoa! one moment - you say that so casually, as if it were something small! this is major change with lots of ripples. i need to make sure that all my projects (not only ToolChain) build and run and i usually also update the code for the PluginHost and Projucer project with the new code from the juce repo when i update my juce version (and build me a new Projucer).

also download a new VST3 SDK!

download a new vst3sdk? i can't remember having ever downloaded an old vst3sdk. this seemed not to be necessarry with the old version of juce - it used to be self-contained. is this due to a policy change by Steinberg with regard to the vst2sdk as explained here:
https://www.kvraudio.com/forum/viewtopic.php?f=33&t=508845
...this would be quite a major disimprovement :-(

[elanhickler]

just update your JUCE, look at my pull request for some specifics on what you need to do to get your library to build, and use the legacy thing to re-link VST3 SDK.

here's the legacy VST3 SDK I'm using: http://www.elanhickler.com/Soundemote/VST3%20SDK%20(3.6.5).zip

[RobinSchmidt]

as said - updating the juce library is a major step that has to be taken carefully, otherwise many things may break (build-systems, mostly). this is not something like a minor bug-fix. sure, sooner or later it has to be done anyway to not fall behind too much but things like that have to be done thoroughly, not casually. you don't address my specific questions and concerns at all

btw. i'm not saying, i won't do it, i'm just saying, that i won't do it casually and may need some time for that. i may try it, then set everything straight again and commit only when everything works again....

[RobinSchmidt]

damn - yes - it looks like steinberg now really means it to kill off vst2 - that's really sad:

namespace Vst2
{
// If the following files cannot be found then you are probably trying to build
// a VST2 plug-in or a VST2-compatible VST3 plug-in. To do this you must have a
// VST2 SDK in your header search paths or use the "VST (Legacy) SDK Folder"
// field in the Projucer. The VST2 SDK can be obtained from the
// vstsdk3610_11_06_2018_build_37 (or older) VST3 SDK or JUCE version 5.3.2. You
// also need a VST2 license from Steinberg to distribute VST2 plug-ins.
#include "pluginterfaces/vst2.x/aeffect.h"
#include "pluginterfaces/vst2.x/aeffectx.h"
}