The docs indicate that wxPropGrid takes ownership of the property once it is appended to the control.
I made the mistake of creating the property outside the grid, storing a reference, then appending it, and later, clearing the page containing the property.
Appending it a second time from the stored reference, crashed Python.
Would it be possible to raise an exception or give an error message?
The TreeViewCtrl offers an "IsOk" method to verify that an item is valid before using it.
I've run into this situation with other controls and they display a warning message that "the C++ portion of the control has been deleted." to let me know that I'm trying to do something illegal.
Thanks for pointing this out. The solution would be to use the wxPython OOR magic to raise wx.PyDeadObjectError as appropriate. This is already used for various wxWindow-derived classes in wxPropertyGrid. For wxPGProperty however, things aren't as simple since it does not inherit from wxEvtHandler, which holds most of the functionality facilitating the OOR awareness.
Anyway, I've just tried to do this somewhat simply and sanely, mimicking what is already done in similar situations (e.g. wxGridCellWorker), but it doesn't work… yet. I'll let you know if or when it does.
The Append method has always been my biggest source of confusion when using the PropertyGrid control.
**pg->Append( new wxFloatProperty(wxT("FloatProperty"), wxPG_LABEL, 12345.678) );**
Just trying to grasp the idea of a function that creates/returns a Property, but takes a Property as its argument; seems weird.
AppendFloat(): appends a new float property and returns True if it succeeded, False if it failed.
AppendString(): appends a new string property and returns True if it succeeded, False if it failed.
Seems more intuitive.
The Append method works perfectly - it's just that I've stubbed my toe on it enough times that I thought I'd mention it.
If Append() has been your biggest confusion with wxPG, then I think congratulations are in order ;)
Anyway, adding property-class specific insertion functions would just needlessly bloat the API. Generic ones will always be needed, and the class-specific ones would not reduce typing effort very much, and if you really need them you should be able to add them via subclassing.
About the Append() return value: the returned property pointer is always exactly the same as the one passed as argument. This is done for convenience, and is a fairly common pattern at least in standard C library. In addition, property insertion functions should never fail, so raising exception (or asserting in C++) makes more sense than returning True/False.
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.