Hi
I am porting a mature codebase over to use JUCE and have a limited time frame in which to do it. My intention is, essentially, to treat JUCE as a wrapper around existing code, in a similar manner to that we’ve used with VST, AU, etc. over the last decade and a half.
Using the Projucer I have a lovely VS solution [I am very impressed with this bit of kit!], have brought in my code as sub projects, and got everything set up as it should be.
On the audio side I have processBlock extracting the WritePointers and passing those to my existing process calls. All is well
On the visual side, I have derived a graphics buffer via which I can marshal all my drawing calls and pass my pixels around in a format JUCE approves. All is well
However, now I wish to intercept mouse movements - enter, exit, move, down, etc. I see that Projucer gives me a new class
NewProjectAudioProcessorEditor : public juce::AudioProcessorEditor
and I see that juce::AudioProcessorEditor inherits from juce::Component which in turn inherits from juce::MouseListener.
However, in my NewProjectAudioProcessorEditor if I attempt to override a mouse event, e.g.
class NewProjectAudioProcessorEditor : public juce::AudioProcessorEditor
{
public:
void mouseEnter(const MouseEvent& event) override;
}
I am told in no uncertain terms that “member function declared with ‘override’ does not override a base class member” which surprises me. All the mouseXxx functions are declared virtual and public in MouseListener, and, so far as I can tell, aren’t moved to private in Component or AudioProcessEditor… So why can I not override them in this new class? Is there an alternative method around this?
I have even tried just a very simple class to test:
class bip : public juce::MouseListener
{
public:
void mouseEnter(const MouseEvent& event) override;
};
Same result.
Note - Once the product is released, I intend to revisit and refactor the current internal components and drawing to a more JUCE-centric, but at the moment the existing codebase has been 15-20 internal UI components and there isn’t space within the time frame to take mature, tested code from one format into a new one and test them all, etc.!
While I have been coding for nearly forty years, thirty of them professionally, I’m new to JUCE, tho’ remember Jules talking about it on KvR a couple of decades ago…! I know what I want to do can be done - it’s just finding the way that JUCE does it so I can pass the interactions on to what I currently have. Getting mature codebases to talk to each other is not new ground to me, but could just do with an insight into why things I think ought to work… aren’t!
Maybe I’m just tired. Maybe I need a cup of tea.
Any suggestions about this welcomed!