Forum

Hi,

I’m a new Prof-UIS user and I’m struggling to understand how I’m meant to deallocate memory with Prof-UIS derived classes, in particular with a CExtPropertyItem derived class.

In all past projects I have worked on the golden rule has been that if I instantiate an object on the heap with operator ’new’ then it is my responsibility to release memory for that object via a destructor call. If an object is instantiated in a third-party library then such an object is normally obtained via a Create() function and released via a Destroy() or Delete() function.

I can find no instructions in the Prof-UIS documentation which tell me which objects are my responsibility to delete, and which objects will be deleted by Prof-UIS. I therefore assumed that I would have to delete any objects I create on the heap via ’new’. However when I study the source of your samples for CExtPropertyGridCtrl I note that you create a CExtPropertyStore object and explicitly make comments in the code that this object should be deleted as its memory was allocated dynamically. You then go on to create many objects derived from the CExtPropertyValue class, and you instantiate these via operator ’new’ but you *don’t* call delete on these. Why not? Nowhere in the docs does it say that the CExtPropertyStore parent of these objects will handle the memory deallocation. How are Prof-UIS users meant to know which objects they should delete?

Also I don’t understand the usage of the CExtPropertyItem.Delete() method. You say that this should be called rather than using the ’delete’ operator, but what if I create a CExtPropertyValue-derived class which makes its own heap allocations? How do I destroy this object? Will CExtPropertyItem.Delete() call my own destructor, or should I first call the Destroy() method to release base class memory, and then destroy my own objects separately?

I apologise if this seems so trivial to the authors of the Prof-UIS library, and I realise I am probably misunderstanding this issue, but due to the dynamic nature of the app I am working on it is extremely important to me that I know exactly how to release memory from the numerous objects I am creating.

Many thanks for your time.

Andrew

Even in MFC some objects are self deleted (e.g. frames and views) while other ones should be deleted from your code directly. We think the most convenient design is provided by GDI wrapper classes like CDC. You can create an HDC handle manually and attach it to a CDC object using the CDC::Attach() method or you can let the CDC object to create a HDC handle using some of CDC::Create***() methods. But a HDC handle is always deleted automatically in the CDC::~CDC() destructor. If you need a HDC handle to be deleted automatically, then you should detach it from the CDC handle using the CDC::Detach() method.

As for the property items (values, categories and stores), there are two options of using the in property grid control:

1) You are using a property grid (the CExtPropertyGridCtrl class) without the combo box bar when the combo box bar is simply not used and hidden or even not created in the property grid control. The CExtPropertyStore* property store is attached to the property grid control using the CExtPropertyGridCtrl::PropertyStoreSet() method and detached using the same method with NULL in its parameter. The CExtPropertyGridCtrl class never deletes the property store pointer and you should delete it in your code,

2) You are using a property grid with the CExtPropertyGridComboBoxBar combo box bar and inserting property store pointers into it as combo box items using the CExtPropertyGridComboBoxBar::PropertyStoreInsert() method. The combo box bar removes all the property stores at shutdown because it is based on the combo box common control which automatically deletes its string collection when the combo box window is destroyed. The combo box bar handles the item selection event in it and attaches the selected property store to the property grid control using the CExtPropertyGridCtrl::PropertyStoreSet() method as it is described in #1 above. The combo box bar does not delete property stores either.

In both cases property stores are not deleted. Why? Property stores describe properties of some objects in your application. It is convenient to create and destroy the property store tree of each of your objects in its constructor and destructor. You know exactly that only you manages property stores and nobody else will ever destroy them.

Each CExtPropertyStore property store contains a tree-like structure of CExtPropertyValue property values and CExtPropertyCategory property categories. All three classes are derived from the CExtPropertyItem class which provides a set of methods for managing the collection of child property items. Your code allocates new property categories/values and insert them into theparent store/category using the CExtPropertyItem::ItemInsert() method. If you delete the property store, then all the child trees of property items become deleted automatically. This is convenient because in a typical task the property store tree structure is initialized once when it needs to be displayed in the property grid control. If you need to change the tree structure of property store’s tree, then you should use the CExtPropertyItem::ItemRemove() method which removes and destroys tree brunches. Then you can insert new brunches. So, you should use C++’s delete operator for property stores only.

The CExtPropertyItem::Delete() virtual method is really needed for internal use in combined property values only. The combined property values in one property store contains pointers to other property values from other property stores. So, child property values should not be deleted by a combined property value. That is why all property items use the CExtPropertyItem::Delete() virtual method instead of C++’s delete operator.