(SOLVED) Object Inspector and subcomponents

[minesadorada]

see the attached screenshots...

In the Object Inspector, a subcomponent's 'Name' property is displayed as an editable list with 2 entries:

• maincomponentname.subcomponentname
  
• (none)

If you edit it in any way, you get an "Invalid Property Value' error dialog.

If you click it and set it to (none) then the maincomponentname.subcomponentname is lost forever; any attempt to type the previous value back in causes an "Invalid Property Value' error dialog.

An empty value doesn't cause a compile error for the containing app.

Is all this behaviour by design, or is it a bug?

It seems sensible to have the subcomponent's 'Name' property readonly in the Object Inspector, but perhaps I'm missing something.

[howardpc]

This probably indicates that the subcomponent in question is not a common type (string, boolean, enum, integer, font etc).
The OI has numerous property editors registered which deal with all commonly encountered types, but any programmer can declare a new type of property and publish it. If the programmer does not register a property editor for that new type, then the OI will not be able to handle it.

[jdlinke]

Looks like it's looking for an object of type TThreadDownload (or its descendants). So only objects of that type will be allowed in the property editor (or the value None). Sort of the same way that if you put a DataSource component on your form, the DataSet property of that DataSource will populate with all TDataSet and TDataSet descendants (Including things like SqlQuery components). If you type in the name of an object that is not a TThreadDownload or descendant, then you're trying to apply the wrong type of object, and Lazarus won't be happy.

As for why it's not readonly, that all depends on what Property Attributes the component author sets in the property's GetAttributes procedure (check Lazarus' propedits.pas for details on the available options).

[minesadorada]

Thanks for the replies, however perhaps I didn't make the situation clear enough.

TThreadDownload is a custom class based on TComponent.

The property editor is registered as a TClassPropertyEditor type in the Register proc.
  RegisterPropertyEditor(TypeInfo(TThreadedDownload),
    TLazAutoUpdate, 'ThreadDownloader', TClassPropertyEditor);


In the ancestor's Create (private member fThreadDownload  declared as type TThreadDownload)
  inherited Create(AOwner); // TComponent method;
  fThreadDownload := TThreadedDownload.Create(Self);
  fThreadDownload.SetSubComponent(true);  // Tell the IDE to store the modified properties
  fThreadDownload.Name:='ThreadDownloader'; // Name in Object inspector


Does this particular code make the Object Inspector act in the way I described?

Or to be constructive: How can I change the behaviour of the subcomponent's 'Name' property?  A casual scan coudn't find it in the propedits unit.  It's not a member of TclassPropertyEditor nor its ancestor TPropertyEditor.

[howardpc]

How can I change the behaviour of the subcomponent's 'Name' property?  A casual scan coudn't find it in the propedits unit.

In addition to registering the correct type of propertyeditor descendant, you have to customise it for your particular class-to-be-edited by overriding two TClassPropertyEditor virtual functions (GetAttributes, GetValue) and one TClassPropertyEditor procedure (GetProperties).
For examples of the sort of code you have to write look at the implementation details of one of the existing Lazarus class property editors.

[minesadorada]

How can I change the behaviour of the subcomponent's 'Name' property?  A casual scan coudn't find it in the propedits unit.

In addition to registering the correct type of propertyeditor descendant, you have to customise it for your particular class-to-be-edited by overriding two TClassPropertyEditor virtual functions (GetAttributes, GetValue) and one TClassPropertyEditor procedure (GetProperties).
For examples of the sort of code you have to write look at the implementation details of one of the existing Lazarus class property editors.

OK Thanks.

[jdlinke]

This Page in the wiki talks a bit about property editors at the end, and if you search the web for "Delphi Property Editors" you can find some relevent tidbits of info, but it's surprisingly difficult to find any resource that breaks the concepts down and explains things well for new Lazarus component authors or those who simply want to make modifications to a component. I'm slowly working on building a detailed tutorial and a set of demonstration projects to fully describe property editors, their attributes, how to extend existing editors, and some of the really cool tricks available. I'll let you know once I've got a workable version.

[minesadorada]

The TClassPropertyEditor does everything nicely 'out-of-the-box' for a generic homebrew subcomponent class but for the annoying behaviour of the 'Name' property.  I just wondered if there was a designed reason for it - it seems not.

It's nice to be able to simply have published subproperties visible and editable via TClassPropertyEditor without having to subclass it.

I'll take a look at the fonts subcomponent class code.

[minesadorada]

After looking at this thread, I realise that most comments may be based on a misconception of my question, due to my reference to the 'name' property.

I don't mean the published 'Name' property, but the object inspector's display of the Class Name (look at the screenshots in post #1 so see what I'm talking about).

Sorry for being so unclear.

So in the screenshot, I mean the display of 'LazAutoUpdate1.ThreadDownloader' in the Object Inspector.

I've looked around in all kinds of source files, but can't find it.

[taazz]

So in the screenshot, I mean the display of 'LazAutoUpdate1.ThreadDownloader' in the Object Inspector.

Take a closer look on the Constructor create of the TLazAutoUpdate component. You will see that it creates a TThreadedDownload component with ou giving it a name as a result you see the complete path used to identify the component.

You get none in the drop down list because the default behavior of the classpropertyeditor is to show all teh components that are part of the form the TLazAutoUpdate is on. It is natural to find none as the TThreadedDownload component is not register in the palette and can't be placed on the form although it is component based. Since there is no reason to have the TThreadedDownload as a component as far as I can see that is change the base class from tcomponent to tpersistent and of course to do not register any property editor leaving it to the IDE to use the default property editor for the class. Never define your own editor if you do not have any reason to do so you only create problems for your self for no reason at all.

[minesadorada]

@taazz you are a hero.  Your advice has completely solved the issue - thanks.

I can also see why SetSubcomponent is designed to act the way it does, now.