- UID
- 5280
- 积分
- 9466
- 精华
- 贡献
-
- 威望
-
- 活跃度
-
- D豆
-
- 在线时间
- 小时
- 注册时间
- 2002-5-18
- 最后登录
- 1970-1-1
|
马上注册,结交更多好友,享用更多功能,让你轻松玩转社区。
您需要 登录 才可以下载或查看,没有账号?立即注册
×
AcDb: deriving from AcDbPolyline
问题:
Deriving from AcDbPolyline works correctly, however, it seems DWG files
containing instances of my custom entity derived from AcDbPolyline do not
contain proxy graphic information for them. Why?
解答:
AutoCAD does not save the proxy graphic information for classes derived from
AcDbPolyline. The reason for this is that the 'saveAs()' method is implemented
as follows:
-
- void AcDbPolyline::saveAs(AcGiWorldDraw* mode, AcDb::SaveType st) {
- assertReadEnabled();
- if ( st == AcDb::kR12Save )
- // ... do something to convert into AcDb2dPolyline
- }
Whereas it should be as follows:
- void AcDbPolyline::saveAs(AcGiWorldDraw* mode, AcDb::SaveType st) {
- assertReadEnabled();
- if ( st == AcDb::kR12Save )
- // ... do something to convert into AcDb2dPolyline
- else
- worldDraw (mode) ;
- }
As a result, proxy graphic data is never saved, which causes your derived
AcDbPolyline entity to be invisible if your DBX-object enabler application is
not loaded. Although this is not ideal, it does not affect any other behavior or
functionality of your custom entity.
A simple override of the 'saveAs()' method can solve this problem as follows:
-
- void AcDbMyPolyline::saveAs(AcGiWorldDraw* mode, AcDb::SaveType st) {
- assertReadEnabled();
- if ( st == AcDb::kR12Save )
- AcDbPolyline::saveAs (mode, st) ;
- else
- worldDraw (mode) ;
- }
This would be the correct solution, however there is another known problem in
AutoCAD that prevents the 'saveAs()' method from being called for proxy graphic
generation. This second problem is more serious because it prevents 'saveAs()'
method being called. The reason for this is that AutoCAD makes an exception in
the case of an AcDbPolyline entity. Instead of asking 'are you an AcDbPolyline
class?', AutoCAD asks 'Are you a "kind of" AcDbPolyline?' This also includes any
of your derived classes from AcDbPolyline.
The only solution is to pretend your custom AcDbPolyline entity is not an
AcDbPolyline class, even if it really is. This will cause AutoCAD to properly
call the 'saveAs()' method and then your implementation of the 'worldDraw()'
method for your custom entity. In order to pretend that it is not an
AcDbPolyline entity, just implement the 'ACRX_DXF_DEFINE_MEMBERS' ARX macro as
follows:
-
- ACRX_DXF_DEFINE_MEMBERS(AcDbMyPolyline, AcDbCurve,
- AcDb::kDHL_CURRENT, AcDb::kMReleaseCurrent,
- AcDbProxyEntity::kNoOperation,
- ACDBMYPOLYLINE, ACDBMYAPP
- );
-
There are other requirements in the implemention of the 'worldDraw()' method:
you should not call AcDbPolyline::worldDraw() when called from the 'saveAs()'
method because this would cause the same problem that was outlined previously.
(AutoCAD filters out all AcDbPolyline calls in that context). An 'unhandled
exception error' will occur as a result. (rememeber we are pretending not to be
an AcDbPolyline entity). To solve the problem, you need to modify the 'saveAs()'
method like this:
- bool mbDrawWithExplode = false ;
- void AcDbMyPolyline::saveAs(AcGiWorldDraw* mode, AcDb::SaveType st) {
- assertReadEnabled();
- if ( st == AcDb::kR12Save ) {
- AcDbPolyline::saveAs (mode, st) ;
- } else {
- mbDrawWithExplode = true ;
- worldDraw (mode) ;
- mbDrawWithExplode = false ;
- }
- }
- Implement your 'worldDraw()' method like this:
- Adesk::Boolean AsdkOPLine::worldDraw(AcGiWorldDraw* mode)
- {
- assertReadEnabled();
- if ( !mbDrawWithExplode ) {
- bPEdit =true ;
- if ( AcDbPolyline::worldDraw (mode) != Adesk::kTrue ) {
- bPEdit =false ;
- return (Adesk::kFalse) ;
- }
- bPEdit =false ;
- } else {
- AcDbVoidPtrArray ents ;
- AcDbPolyline::explode (ents) ;
- for ( int j =ents.length () - 1 ; j >= 0 ; j-- ) {
- ((AcDbEntity *)ents.at (j))->worldDraw (mode) ;
- delete (AcDbEntity *)ents.at (j) ;
- }
- ents.setLogicalLength (0) ;
- }
- return (Adesk::kTrue) ;
- }
If you pretend it is not an AcDbPolyline, the AutoCAD "_PEDIT" command will not
work for your custom entity anymore. If you do not intend to support "_PEDIT",
then it is not a problem. However, if you intend to support "_PEDIT" then you
need to pretend that it is an AcDbPolyline only for the "_PEDIT" command. To
support "_PEDIT" for a special class requires a considerable amount of work.
First, you need to rewrite the 'ACRX_DXF_DEFINE_MEMBERS' ARX macro like this:
- bool bPEdit =false ;
- void set_bPEdit (bool flag) {
- bPEdit =flag ;
- }
- //------------------------------------------
- #define MY_ACRX_DEFINE_MEMBERS(CLASS_NAME) \
- AcRxClass* CLASS_NAME::desc() \
- { \
- return (AcRxClass*)((AcRxDictionary*)acrxSysRegistry() \
- ->at(ACRX_CLASS_DICTIONARY))->at(bPEdit ? "AcDbPolyline" :
- "AcDbMyPolyline"); \
- } \
- AcRxClass* CLASS_NAME::isA() const \
- { \
- return (AcRxClass*)((AcRxDictionary*)acrxSysRegistry() \
- ->at(ACRX_CLASS_DICTIONARY))->at(bPEdit ? "AcDbPolyline" :
- "AcDbMyPolyline"); \
- } \
- AcRxClass* CLASS_NAME::gpDesc = NULL
- //----------------------------------------------------------------------
- #define MY_ACRX_DXF_DEFINE_MEMBERS(CLASS_NAME,PARENT_CLASS,DWG_VERSION,\
- MAINTENANCE_VERSION,PROXY_FLAGS,DXF_NAME,APP) \
- MY_ACRX_DEFINE_MEMBERS(CLASS_NAME); \
- static AcRxObject * make##CLASS_NAME() { return new CLASS_NAME(); } \
- void CLASS_NAME::rxInit() { \
- if (CLASS_NAME::gpDesc != NULL) \
- return; \
- CLASS_NAME::gpDesc = newAcRxClass(#CLASS_NAME, #PARENT_CLASS, \
- DWG_VERSION,MAINTENANCE_VERSION,PROXY_FLAGS, \
- &make##CLASS_NAME, #DXF_NAME, #APP); \
- }
- Replace the 'ACRX_DXF_DEFINE_MEMBERS' ARX macro with the following definition:
- MY_ACRX_DXF_DEFINE_MEMBERS(AcDbMyPolyline, AcDbCurve,
- AcDb::kDHL_CURRENT, AcDb::kMReleaseCurrent,
- AcDbProxyEntity::kNoOperation,
- ACDBMYPOLYLINE, ACDBMYAPP
- );
- The last item you need to implement is an AcEditorReactor to detect when the
- "_PEDIT" command is executed and set the pPEdit flag to True as follows:
- void AsdkEdReactor::commandWillStart(const TCHAR* cmdStr)
- {
- if ( _tcsicmp (cmdStr, _T("PEDIT")) == 0 )
- set_bPEdit (true) ;
- }
- void AsdkEdReactor::commandEnded(const TCHAR* cmdStr)
- {
- if ( _tcsicmp (cmdStr, _T("PEDIT")) == 0 )
- set_bPEdit (false) ;
- }
- void AsdkEdReactor::commandCancelled(const TCHAR* cmdStr)
- {
- if ( _tcsicmp (cmdStr, _T("PEDIT")) == 0 )
- set_bPEdit (false) ;
- }
- void AsdkEdReactor::commandFailed(const TCHAR* cmdStr)
- {
- if ( _tcsicmp (cmdStr, _T("PEDIT")) == 0 )
- set_bPEdit (false) ;
- }
When the "_PEDIT" command starts, the AsdkEdReactor::commandWillStart() reactor
callback is called and the bPEdit Boolean is set to True. Then AutoCAD verifies
that the entity selected is "kind of" an AcDbPolyline. To do this AutoCAD calls
the AcRxObject::isKindOf() method, this in turn calls the class descriptor of
the entity (AcDbMyPloyline::desc()), which returns the AutoCAD AcDbPolyline
class descriptor. In all other situations, it returns a real custom entity class
descriptor (child of AcDbCurve).
Forward Compatibility Issues
The two problems will be fixed in a later release of AutoCAD, it should be asked
if the custom entity derived from AcDbPolyline will continue to work. Although a
custom entity derived from AcDbPolyline will continue to work, you will also be
allowed to remove the workarounds in this solution without any problems,
including reloading files from one implementation to another.
|
|