Thu, 08/03/2017 - 00:45
Hello,
We are pleased to inform you that OCCT 7.2.0 is ready for beta testing, and invite you to test this beta version in your applications.
Use the commit tagged "V7_2_0_beta" in the Git repository for this testing. Alternatively, you can use either complete source archive or Windows installer including ready-to-use binaries built with VS 2010.
If you have reported some issues in the bug tracker, please check those with Verified status and Target Version set to 7.2.0 -- we assume they are fixed, and will appreciate to see your comments in the notes of the issue. If you detect a regression, please report it as soon as possible.
For details on the content of the 7.2.0 release, see draft Release Notes.
The final release of 7.2.0 is scheduled for the end of this month.
Your feedback is appreciated!
Andrey
Tue, 08/08/2017 - 11:19
Hello,
I installed the 7.2 beta and wanted to test the QT browser. On Installation I selected binaries (no source, no documentation, no samples) and TInspector. After installing everythign works as normal (draw.exe etc work well) but running the dfbrowser.bat reports an error due to missing QT libraries.
Looking in the root folder with all listed libraries (ffmpeg, vtk etc.) there is no QT folder. I suppose Qt was not installed correctly.
Have you any advise how to fix this?
Tue, 08/08/2017 - 12:10
I think it is an issue with missing dependencies within installer for new item TInspector. Try re-installing with (Qt) samples checked.
Thu, 02/17/2000 - 11:31
Hi !
I thought the idea here was to use the document to create the hierarchy for a model, and then this would be saved to disk and then later loaded back in.
My idea was to display the label hierarchy of a document in a tree view widget to allow the user to have a good overview of the models hierarchy.
But I must have missunderstodd something here, I mean I must be able to delete labels or else it's pretty useless.
What should I use to create this hierarchy instead, do I have to do that on my own maybe and skip the OCAF classes ?
What I need is a nice tree hierarchy of the parts of a model that can be saved to disk, loaded back in, modified, displayed in a viewer and also I would like to display the hierarchy in a tree widget.
Mikael
Tue, 08/08/2017 - 14:00
That worked, thanks!
Thu, 02/17/2000 - 14:35
Hello! Ok. It's a good idea to display the hierarchy of labels, but in fact labels are not data. They are only the handlers of data. Real data is in attributes, attached to labels. In fact what can be usefull to display is:
rootlabel
|
AttributeOnRootLabel_1
AttributeOnRootLabel_2
|
|
ChildLabel1
|
AttributeOnChildLabel1_1
|
ChildLabel2
and so on...
In fact such of information is usefull. You are right, that labels themselves without any information on them are... a little bit useless.
Labels are very low level. In fact You have the attribute TDataStd_TreeNode. Using this attribute You can generate the tree inside the model with the structure You want. each of node have to be placed on some label and after You connect nodes between each other. And how to provide the label structure of model... it's only Your private question. It depends in fact of the model.
Regards.
Mikhail.
Mon, 02/28/2000 - 01:35
Hi !
If I use the TDataStd_TreeNode to create the hierarchy of a model, I still need to have the labels in the same hierarchy, for example if I add a TDataStd_CoordSys attribute and let that transform the children to, this will then transform the child labels, not the child tree nodes, correct ?
Is there a way to solve this ?
...
> Labels are very low level. In fact You have
> the attribute TDataStd_TreeNode. Using this
> attribute You can generate the tree inside
> the model with the structure You want. each
> of node have to be placed on some label and
> after You connect nodes between each other.
> And how to provide the label structure of
> model... it's only Your private question. It
> depends in fact of the model.
Mon, 02/28/2000 - 09:13
Hello Mikael!
You are right. TDataStd_TreeNode is an attribute only and it has to be set at a label. Labels during the creation of a model hierarchy are only the containers for the model's nodes. So, to create a node You have to set a TDataStd_TreeNode attribute attached to a label. In this case it doesn't matter what the label is. You may set it anywhere (attached to any label). What is important in this case - a TreeNode set at a label. Then You must connect just created node with other nodes of Your model. For this there are such methods as Append(), Prepend(), InsertBefore() and InsertAfter(). Using these methods You connect a node with others or You can redesign the tree of nodes using these methods. The manipulations of nodes don't concern a label hierarchy. You may forget about labels during working with TreeNodes.
The answer to You question. If You transform a node to a new place (for example: using TDataStd_TreeNode::Append() method) its label remain at the previous position. It's impossible to change the label's hierarchy.
The TreeNode attribute is very important one in OCAF. It may be used with the Function Services of OCAF. Changing a tree of Your model You may change the regeneration sequence of functions (function drivers).
Good luck,
Vlad
Thu, 02/17/2000 - 15:26
Bonjour Mikael!
It's not necessary to make Your own classes instead of OCAF classes. Please, look at the class TreeNode from TDataStd package. You may see that this class provides creation of an editable tree.
Good luck, Vlad
Fri, 09/15/2017 - 12:22
(As there is no thread for the 7.2.0 public release let me use this one for the Beta).
Congratulations on the 7.2.0 release !
Our team did not have enough time to port to 7.2.0 Beta given three weeks window and own existing assignments. Although we tried to regularly catch up with git we consistently failed due to significant porting efforts so we gave up and currently try to use Beta/public releases. Hence the feedback comes late.
A couple of issues so far:
https://tracker.dev.opencascade.org/view.php?id=29115
https://tracker.dev.opencascade.org/view.php?id=29116
The porting is not over yet, so perhaps more feedback will be provided.
Hope the above will be helpful anyway.
Best regards,
Roman
Sun, 09/17/2017 - 23:04
Thanks for a feedback!
The issue reported as #0029115 is not a bug but intended modification described in Upgrade Guide:
Mon, 09/18/2017 - 18:13
Thanks for the response and link to the guide.
The technical discussion is kept in Mantis to preserve a single place.
Thank you.