Generic component (bug and feature request)

The Projucer
1

Bug Report:

As I understand it, if the ‘virtual class’ property of a generic Jucer component is used, then in the gerated code the (static) type of the member should be set to this type, but the type used for the constructor call should still be the type of the ‘class’ property. This is not the case in the Jucer v1.11 of Juce v1.45. The type defined with the ‘virtual class’ property is used for both the constructer and the static member type.

Feature Request:

I’m using a FilenameComponent as a generic component. The problem is that the constructor of FilenameComponent needs a lot of information, which I don’t want to write into the ‘constructor params’ property field of Jucer.

An additional property in the generic component, which would disable the implicit creation of the instance, would solve this problem. Then the user would have the duty to instantiate the member in the [UserPreSize] section and the ‘name’ and ‘focus order’ properties would be disabled (otherwise they would call methods on a NULL pointer).

Greetings
Jan

2

My understanding is that the class in the jucer is just to proxy/display, and the virtual class can be anything you want. That way, you can do anything you want with the class and also use an jucer class to represent it. I like it that way. It’s a little extra work, but you have do some anyway, such as your forward declaration in .h and the include in the .cpp files.

Meanwhile, IMHO, the safest place to initialize an object is as it’s created, and nullifying that for a dangerous ‘trust me’ scheme seems very risky, and a recipe for disaster for most users. It will make a dangling pointer for sure, which either makes for a big risk (that no compiler will catch) or needs loads of safety code. Apart from that, you can’t even add and make visible the component - since it won’t exist. I already get in enough trouble having instances pointing to other instances (in their constructors) and the z-order == instantiation order being wrong every now and again.

Maybe you should consider putting a holder component, like a viewport, in Jucer then making and inserting your custom component yourself? That seems a lot cleaner.

My 2c.

Bruce

3

Thanx for the Answer, Bruce.

I Agree with you about my feature request, it would be too fragile.
But with the current behaviour of the Generic Component, the ‘virtual class’ property is completely redundant. There are only two Places, where the class property (and virtual class property) is filled into the generated code:

-In the class declaration:

-In the creation section:

If the virtual class property is not empty, it is allways used and the class property is completely neglected. Otherwise the class property is used allways.

I guess there is a bug in the method ComponentTypeHandler::fillInCreationCode of the Jucer (jucer_ComponentTypeHandler.cpp, line 564):

if (virtualName.isNotEmpty()) s << makeValidCppIdentifier (virtualName, false, false, true); else s << getClassName (component);

I think it should be:

const String actualName (getClassName (component)); if (actualName.isNotEmpty()) s << actualName; else s << makeValidCppIdentifier (virtualName, false, false, true);

With this Fix, I could write e.g. in the [MiscUserDefs] section of the main component .cpp File:

class MyFilenameComponent : public FilenameComponent { public: MyFilenameComponent() : FilenameComponent(T("audiofile"), File::nonexistent, true, false, false, T("*.wav"), String::empty, T("(choose a WAV file to play)")) { } };

Then I could write in the Jucer:

class property: MyFilenameComponent
virtual class property: FilenameComponent

which would generate FilenameComponent for the declaration in the header file, and MyFilenameComponent for the constructor call.
This way I could use the local helper class without forward-declaration in the hpp file. Also the code would be much cleaner, because the class MyFilenameComponent has little importance while reading the code.

Greetings
Jan

4

That would be nice to have, but it’s not the exact feature we have now, which is more flexible, but - you’re right, less useful in 90% of cases, were you do want a sub-class.

So I’ll second that FR then - a sub-class, that gets all the parent classes initialization, as per the jucer norm, but adds features.

Jules: how about a added parameter - that could probably default to true, that specifies this as a sub-class so the jucer can take care of all the appearance still? Maybe if it’s easier, the virtual class could be something like:

and this would tell the jucer to do all the usual init?

Bruce

5

Hi Bruce

If its not a Bug, then I must admitt that I do not understand the meaning of the virtual class property. Because if you write something into the virtual class property, in the generated source code files the ‘class property’-strings will just be replaced with the ‘virtual class property’-strings. This makes no sense to me. Maybe you can give me an example? Thanx.

Greetings
Jan

6

Well, an example is a custom component that sub-classes component somewhere, but not another specific juce class.

Let’s say I make a sub-class just to fake a text editor to enter a password. I might want to use a TextEditor in the jucer to represent it in trivial testing, but write my own class. My understanding is that it just lets you use a juce class as a proxy for size, position, instantiation, etc. That’s quite normal in juce, where sub-classing is used for specific behaviour, as opposed to ‘events’ or signals/slots in other systems.

When I think about it, a subclass system would be a bit more useful.

Bruce