Hi:
I created one class that is very similar to AIS_Shape. But, not AIS_Shape. In OCAF, it can store TopoDS_Shape in it and record a lot of properties. But, my class can't get TopoDS_Shape. Does it possible link my class into OCAF? On the other hand, How about AIS_Trihedron? Can it be in OCAF? Have you had any experience about those? Thanks a lot.
Hi:
That is my concern. I wish MY AIS_Shape can be stored in a TDF_Label. I don't have any ideal to deal with it. Have you tried it? It seems I don't find out to store AIS_Trihedron in a TDF_Label. I will look more careful OCAFSamples later. Thanks.
Hi:
That is my concern. I wish MY AIS_Shape can be stored in a TDF_Label. I don't have any ideal to deal with it. Have you tried it? It seems I don't find out to store AIS_Trihedron in a TDF_Label in SampleOCAF.
We usually need use a third-patry module, or legacy code, in those modules the basic data structure is not manipulated by handle, and not derived from TDF_Attribute.
How can I store these data structure into Data Frawework? More important, I want to store them into a same OCAF file!
Of course, there is one way: convert each field into TDF_Label and associated TDF_Attribute. But this is a bad solution.
I have said TDF_Label is just a `void*' pointer, we lost most of O-O feature provided with C++ when we use TDF_label to describe a data structure. So we must develop a general mechanism to integrate our own class into Data framewrok.
Directly programming with TDF_Label is error prone. When I need to mount two same kinds of attribute under a TDF_Label, I couldn't do this, since these two attributes are with same Standard_GUID, so I must allocate a new child label to deal with it. For example, consider this foo-bar struct:
How can I convert this struct into only one TDF_Label? In other words, How can I store m_strFirst/LastName under same TDF_Label?
So I think we must develop a general mechanism to deal with this problem, or we will back to the ero of ASM programming. I must dynamicly get the required data structure(i.e. TDF_Label), and compiler couldn't provide any compilation-time type check!
Your are right, TDF_Label cannot provide us a type cheching mechanism, and only one same GUID of TAttribute_XXX can hold, if you wanna add same GUID TAttribute_XXX, you must add two sub-label to your main label and add two attributes to the two child labels.
So, we can think that the if we wanna add a TAttribute_XXX object into a label, we'd better add a child label first and then add the attribute.
The same problem is occured in my case. My solution is like followings:
1. I encapsulate a class for every standard general type, like Standard_Integer, Standard_Real, etc. Such object support TDF_Label serialize, which means they have a label to read/write.
2. every "big" object who have data member which are support Label/Serialzied using the object in design 1. And such object has its own label.(the data member's labels are child label of this).
For your legacy codes, I think you should write some adapter to isolate the relationship between them.
Hi,
This is a very simple sample of my idea. for short representation, I cut the .cpp file, wish you can understandard it.
// This is the root class of basic type, inherit from CObject for the type object
// can be dynamic created in runtime.
class CBasicTypeRoot : public CObject
{
DECLARE_DYNCREATE(CBasicTypeRoot);
public:
CBasicTypeRoot();
~CBasicTypeRoot();
CBool, CStr is same as CInteger, of cource, for real working there must be adding more functionity in them.
Thus, very "big" object's label is mother label of data member's, all of the data member has it own label.The tree structure of your data is same as the label's structure.
I have several questions about your design which I am not very clear:
1. How do you serialize your data? Since you don't DECLARE_SERIAL, so you don't use MFC/CArchive mechanism. I guess your CObject derived class are just some `wrappers' ( or by term of `design pattern', `decorator') of TDF_Label tree, so the actual serialization/deserialization is stiil fulfilled by OCAF.
2. By 1, you must need a dynamicaly creation mechanism to create your class architecture from TDF_Label tree. ( Unfortunely, last night I suddently found that I also seems to need a full RTTI add-on for OCAF :-( ).
3. If Assumption 1 holds, i.e. store actual data under associated TDF_Label, didn't you maintain a copy of attribute stored under that TDF_Label? i.e. CInteger has a Standard_Integer member. How do you synchronize it with Data Framework?
Q1:
Yeah, The class CInteger just like a "wrapper" of the Standard OCC data type, but not "decorator", which is dynamic add property into the object. Save/Load is still use the OCC's, save is simple, but load here is Q2 I explain following.
Q2
Your Q2 and Q3 is same, all of your question I think is how to rebuild your own data structure from the raw TDF_Label object. Your are right, the label has not RTTI information at all, I think we can consider the Label as an archive just like in MFC's CArchive, which is stream of data, no RTTI information, and only maintain a file position pointer on which application's data will read/save correctly.
So, first we can imagine the TDF_Label a file stream, if not smart, your "decorate" it in some other class:-), make it look more likely as a file stream. second, how to rebuild our own data structure, such as our class object. Ok, you know your data strucutre before saving where you have already maintain in some of container, and also know their relationships, for my last post I have said every type of data which support serialize has a label, so the tree of your own is same as the label's, thus, when you read back, you rebuild you data in opposite way of your saving.
I have write some code of such structure, they done well.
Fri, 08/30/2002 - 11:18
Hi:
I also need know about this. I have created my own class. It seems that is very very hard to link with OCAF.
Best regards,
Wed, 09/04/2002 - 02:55
Hi:
I created one class that is very similar to AIS_Shape. But, not AIS_Shape. In OCAF, it can store TopoDS_Shape in it and record a lot of properties. But, my class can't get TopoDS_Shape. Does it possible link my class into OCAF? On the other hand, How about AIS_Trihedron? Can it be in OCAF? Have you had any experience about those? Thanks a lot.
Best regards,
Shawn
Wed, 09/04/2002 - 05:00
Hi, Shawn
Is your "AIS_Shape" stored in a TDF_Label? All of AIS_XXX object such as AIS_Trihedron can be store in a TDF_Label, see OCAFSamples for details.
Lugi.C
Wed, 09/04/2002 - 17:37
Hi:
That is my concern. I wish MY AIS_Shape can be stored in a TDF_Label. I don't have any ideal to deal with it. Have you tried it? It seems I don't find out to store AIS_Trihedron in a TDF_Label. I will look more careful OCAFSamples later. Thanks.
Best regards,
Shawn
Wed, 09/04/2002 - 17:45
Hi:
That is my concern. I wish MY AIS_Shape can be stored in a TDF_Label. I don't have any ideal to deal with it. Have you tried it? It seems I don't find out to store AIS_Trihedron in a TDF_Label in SampleOCAF.
Best regards,
Shawn
Wed, 09/04/2002 - 12:38
Hi,
Using TPrsStd_AISPresentation as counterpart of AIS_InteractiveObject in OCAF.
regards,
fhchina
Fri, 08/30/2002 - 12:22
Hi,
Can you explain more details of you questions.
Lugi.C
Sat, 08/31/2002 - 14:35
Hi,
We usually need use a third-patry module, or legacy code, in those modules the basic data structure is not manipulated by handle, and not derived from TDF_Attribute.
How can I store these data structure into Data Frawework? More important, I want to store them into a same OCAF file!
Of course, there is one way: convert each field into TDF_Label and associated TDF_Attribute. But this is a bad solution.
I have said TDF_Label is just a `void*' pointer, we lost most of O-O feature provided with C++ when we use TDF_label to describe a data structure. So we must develop a general mechanism to integrate our own class into Data framewrok.
Directly programming with TDF_Label is error prone. When I need to mount two same kinds of attribute under a TDF_Label, I couldn't do this, since these two attributes are with same Standard_GUID, so I must allocate a new child label to deal with it. For example, consider this foo-bar struct:
struct foobar {
TDataStd_Name m_strFirstName;
TDataStd_Name m_strLastName;
};
How can I convert this struct into only one TDF_Label? In other words, How can I store m_strFirst/LastName under same TDF_Label?
So I think we must develop a general mechanism to deal with this problem, or we will back to the ero of ASM programming. I must dynamicly get the required data structure(i.e. TDF_Label), and compiler couldn't provide any compilation-time type check!
fhchina
Mon, 09/02/2002 - 04:54
hi,
Your are right, TDF_Label cannot provide us a type cheching mechanism, and only one same GUID of TAttribute_XXX can hold, if you wanna add same GUID TAttribute_XXX, you must add two sub-label to your main label and add two attributes to the two child labels.
So, we can think that the if we wanna add a TAttribute_XXX object into a label, we'd better add a child label first and then add the attribute.
The same problem is occured in my case. My solution is like followings:
1. I encapsulate a class for every standard general type, like Standard_Integer, Standard_Real, etc. Such object support TDF_Label serialize, which means they have a label to read/write.
2. every "big" object who have data member which are support Label/Serialzied using the object in design 1. And such object has its own label.(the data member's labels are child label of this).
For your legacy codes, I think you should write some adapter to isolate the relationship between them.
best regards.
Lugi.C
Mon, 09/02/2002 - 12:46
Hi, Lugi.C:
Is your structure like this:
class BigClass {
PrimClass prim1;
PrimClass prim2;
PrimClass2 prim2x;
};
class RrimClass {
TDF_Label aLabel;
// Some access method to get/set attributes of this aLabel?
};
Could you show us an example about how to you `embeded' a `big' object?
Best Regards,
fhchina
Tue, 09/03/2002 - 04:25
Hi,
This is a very simple sample of my idea. for short representation, I cut the .cpp file, wish you can understandard it.
// This is the root class of basic type, inherit from CObject for the type object
// can be dynamic created in runtime.
class CBasicTypeRoot : public CObject
{
DECLARE_DYNCREATE(CBasicTypeRoot);
public:
CBasicTypeRoot();
~CBasicTypeRoot();
protected:
void setLabel(const TDF_Label& label){
m_label = label;
}
protected:
TDF_Label m_label;
};
// This is represent the int basic data type.
class CInteger : public CBasicTypeRoot
{
DECLARE_DYNCREATE(CInteger)
public:
CInteger();
~CInteger();
public:
void setValue(Standard_Integer newValue){
m_int = newValue;
}
Standard_Integer getValue() const{
return m_int;
}
protected:
Standard_Integer m_int;
};
// and so on, same class definition of Standard_Real, Standard_CString, etc.
// Now I can define my "big" object.
class CPeople : public CObject
{
DECLARE_DYNCREATE(CPeople);
public:
CPeople();
~CPeople();
public:
void setAge(const CInteger& age){
m_iAge = age;
}
void setName(const CStr& name){
m_sName = name;
}
void setLabel(const TDF_Label& label){
m_label = label;
}
protected:
CInteger m_iAge;
CStr m_sName;
TDF_Label m_label;
};
class CAMan:public CPeople
{
DECLARE_DYNCREATE(CAMan)
public:
setMarried(const CBool& bMarried){
m_bMarried = bMarried;
}
protected:
CBool m_bMarried;
};
CBool, CStr is same as CInteger, of cource, for real working there must be adding more functionity in them.
Thus, very "big" object's label is mother label of data member's, all of the data member has it own label.The tree structure of your data is same as the label's structure.
Best Regards.
Lugi.C
Tue, 09/03/2002 - 08:42
Hi,
I have several questions about your design which I am not very clear:
1. How do you serialize your data? Since you don't DECLARE_SERIAL, so you don't use MFC/CArchive mechanism. I guess your CObject derived class are just some `wrappers' ( or by term of `design pattern', `decorator') of TDF_Label tree, so the actual serialization/deserialization is stiil fulfilled by OCAF.
2. By 1, you must need a dynamicaly creation mechanism to create your class architecture from TDF_Label tree. ( Unfortunely, last night I suddently found that I also seems to need a full RTTI add-on for OCAF :-( ).
3. If Assumption 1 holds, i.e. store actual data under associated TDF_Label, didn't you maintain a copy of attribute stored under that TDF_Label? i.e. CInteger has a Standard_Integer member. How do you synchronize it with Data Framework?
best regards,
fhchina
Tue, 09/03/2002 - 11:26
Hi,
Q1:
Yeah, The class CInteger just like a "wrapper" of the Standard OCC data type, but not "decorator", which is dynamic add property into the object. Save/Load is still use the OCC's, save is simple, but load here is Q2 I explain following.
Q2
Your Q2 and Q3 is same, all of your question I think is how to rebuild your own data structure from the raw TDF_Label object. Your are right, the label has not RTTI information at all, I think we can consider the Label as an archive just like in MFC's CArchive, which is stream of data, no RTTI information, and only maintain a file position pointer on which application's data will read/save correctly.
So, first we can imagine the TDF_Label a file stream, if not smart, your "decorate" it in some other class:-), make it look more likely as a file stream. second, how to rebuild our own data structure, such as our class object. Ok, you know your data strucutre before saving where you have already maintain in some of container, and also know their relationships, for my last post I have said every type of data which support serialize has a label, so the tree of your own is same as the label's, thus, when you read back, you rebuild you data in opposite way of your saving.
I have write some code of such structure, they done well.
regards.
Lugi.C