View Issue Details

IDProjectCategoryView StatusDate SubmittedLast Update
0023112CommunityOCCT:Application Frameworkpublic2012-04-16 16:392012-11-16 14:52
ReporterPawel Assigned Tomkv 
PrioritynormalSeverityintegration request 
Status closedResolutionno change required 
PlatformWindowsOSVC++ 2005 
Product Version6.5.3 
Target Version6.5.4Fixed in Version6.5.4 
Summary0023112: TNaming_NamedShape with TNaming_REPLACE status
DescriptionThis suggestion is based on: http://www.opencascade.org/org/forum/thread_20745/?forum=3

I have noticed that copying labels having TNaming_NamedShape attribute with TNaming_REPLACE evolution attached fails.

Although the Forum Supervisor cleared it was not recommended to use TNaming_REPLACE evolution I still think it is feasible to handle that evolution type while copying labels (after all this is a member of TNaming_Evolution so why shouldn't it be handled).

Steps To ReproduceTDF_Label target; // has TNaming_NamedShape/TNaming_Evolution (TNaming_REPLACE) attribute
TDF_Label source;

TDocStd_XLinkTool xlinktool;
xlinktool.Copy(target,source);
TagsNo tags attached.
Test case number

Activities

Pawel

2012-04-16 16:52

developer   ~0020398

Corresponding branch (CR23112) has been pushed to the git repository.

szy

2012-04-20 19:26

manager   ~0020425

Last edited: 2012-04-23 12:01

 Dear Pawel,
I would like to confirm that at the moment TNaming_REPLACE evolution is not supported by OCCT at all. More over there is no clear and consistent definition as the specified evolution itself as the expected behavior of supporting naming mechanism till now. You can consider it as a started, but not completed draft of corresponding R&D work, which unfortunately was not removed from integration queue in time. It is our mistake and I hope we will remove this ambiguity at the nearest feature. The made by your patch nothing changes because it introduces 'dead' evolution only without any support.
You may use for the same purpose evolution MODIFY. I hope it will cover all your needs.
Regards

Pawel

2012-04-25 12:39

developer   ~0020444

Yes, you are right. I understand your reasoning and do not insist on integrating it to the distribution.

However, I work on a project for that we have to support legacy data. And the legacy data uses (for some reason) the TNaming_REPLACE (coming from the use of TNaming_Builder::Replace) so it was necessary for me to find a way to handle the case.

szy

2012-04-25 19:00

manager   ~0020446

Last edited: 2012-04-25 19:02

 So, to be clear between us. At the moment there is only one consistent and feasible solution: removing REPLACE evolution from the code. All your cases can be supported by evolution MODIFY.
Another issue is how to support portability of document data mentioned by you above. I guess that REPLACE evolution was used in your application just to identify the fact that some shape (initially created with PRIMITIVE evolution) was modified during its life cycle. I.e. resolving of this kind of shape by OCAF after any modification was not expected.
In such case you may easy to solve this problem by replacing of all attributes (NamedShape) with evolution REPLACE by attributes with evolution MODIFY. It can be don or by developing a standalone Convertor or by developing an alternative driver of NamedShape to process persistent document during its opening.
If you will meet any difficulties, you may contact us via the Contact Form http://www.opencascade.org/about/contacts/. I hope we will find a way and a solution to help you.

szy

2012-09-06 16:50

manager   ~0021426

REPLACE evolution is removed.
MODIFY evolution can be used instead of REPLACE.
Persistence compatibility is added by patch CR23205.

Issue History

Date Modified Username Field Change
2012-04-16 16:39 Pawel New Issue
2012-04-16 16:39 Pawel Assigned To => Pawel
2012-04-16 16:52 Pawel Note Added: 0020398
2012-04-16 16:52 Pawel Assigned To Pawel => bugmaster
2012-04-16 16:52 Pawel Status new => resolved
2012-04-16 17:13 abv Assigned To bugmaster => szy
2012-04-20 19:26 szy Note Added: 0020425
2012-04-23 11:57 inv Assigned To szy => Pawel
2012-04-23 11:57 inv Status resolved => assigned
2012-04-23 11:57 inv Status assigned => feedback
2012-04-23 12:01 szy Note Edited: 0020425
2012-04-25 12:39 Pawel Note Added: 0020444
2012-04-25 12:39 Pawel Status feedback => assigned
2012-04-25 19:00 szy Note Added: 0020446
2012-04-25 19:02 szy Note Edited: 0020446
2012-09-03 09:17 abv Assigned To Pawel => szy
2012-09-06 16:50 szy Note Added: 0021426
2012-09-06 16:50 szy Status assigned => closed
2012-09-06 16:50 szy Assigned To szy => mkv
2012-09-06 16:50 szy Resolution open => no change required
2012-11-16 14:52 abv Changeset attached => occt master 1ec8a59e
2012-11-16 14:52 abv Fixed in Version => 6.5.4
2012-11-16 14:52 abv Target Version 6.5.3 => 6.5.4