Inheriting

#1

it’s been a while since i’ve had my programming head on…

i just made an ‘enhanced’ colourselector component, but the only way i could think of getting it to work was to make a component to hold the colourselector and the other part (the palette) together side by side.

it occured to me afterwards to have inherited the colourselector class instead… but as quickly as i’d started trying that out i realised that i can’t just add to the colourselector’s required functions (such as resized() etc…) from the inherited versions as they’re not virtual functions…

am i right in thinking this?

i don’t want to change the JUCE code i have, because that’s rarely a good idea in my book, but i think the most sensible approach here is to simply copy the JUCE ColourSelector code and make directly a new version with my enhancements built in. does this sound like a good approach?

#2

I’d say the best approach would juce be to stick to having a parent component that holds both components - that’s by far the cleanest way to do it…

#3

wipes sweat from forehead

phew! :slight_smile:

i was just having a hack away at a copy of the juce colourselector code, when i decided that what i’d already done wasn’t a bad way… compared to slicing open the arteries of existing classes… :shudder: at least this way it’s really easy to align the various sub components around each other.

thanks for your views on the matter :slight_smile:

#4

no, it’s never wise to hack or copy stuff like that. If you find there’s something you just can’t do without changing the colour selector class, try to think of the most generic way of adding what you need to it, then ask me and maybe I’ll add it (e.g. if you need extra callbacks when the user does something to the selector, etc)

#5

:lol:

Fuck thats a crap laugh emoticon is it? What’s the ETA for the official forum anyway?

Yeah, I only ever inherit from Component, then add Components to that. At the end of the day you’ve still got a Component. I always consider inheritance, but unless it’s a glaring necessity, don’t bother.

Ahh. JUCE::Component. Luxury. Joy to use.
Got to write an MFC app for work (they don’t want me using juce app framework, only core classes: cunts) and I’m baffled as to how and WHERE to add a component and I’m not even sure what components ARE. Nightmare. :shock:

Yo! Jules. If it’s possible, how could I go about using juce Graphics stuff to draw into client area of, say, an ActiveX (EEEEEEEEEEVAAAL!! :evil: ) control?

I’ve done a rather nifty interactive guitar fretboard Component that needs to be redone as AciveX.
Good grief, what a bind. :shock: :frowning:

klf

#6

Nah. I’m speaking shite. Need juce application stuff to do juce drawing. Bugger. Win32 drawing is a bitch.

#7

just tell your bosses to stop wasting their lives and buy a JUCE commercial license!!

#8

You could use the Graphics class to draw on an Image, then blit that onto your MFC window, if that’s what you’re after.

Or create a Component, use addToDesktop to give it a HWND, then stick that inside your window…

#9

You could use the Graphics class to draw on an Image, then blit that onto your MFC window, if that’s what you’re after.

Or create a Component, use addToDesktop to give it a HWND, then stick that inside your window…[/quote]

Nifty!

That’ll save me having to figure out how to do all the nice antialiased stuff.

Haydxn, we are getting a juce license. We’re not releasing anything for a while though so theres not a huge rush as all stuff is inhouse at the minute.
I might do a juce (graphics and all) version on the sly then show them the MFC one and the juce one and see what one they like.
They don’t like the fact juce is relativly unknown and a one man operation with no official support. But they liked me getting an audio system done and dusted in no time. But no to juce GUI and app framework allowed?!?!? I’m just grasshopper so do whit am telt.

k

#10