Wed, 02/23/2000 - 00:14
Forums:
Hi !
The documentation on ocaf (ocaf.html) is not correct some methods are not documented correctley, one example are the TPrsStd_AISViewer::Find() methods, I guess this has to do with changes in the API to version 3.0.
Will the documentation be up to date when you release the next time (end of mars I think it was) ?
Mikael
Wed, 02/23/2000 - 12:03
Hello Mikael,
Thank you for your feedback.
I have looked at the example you give, and find no error. The documentation agrees with the .cdl and the .hxx except that there are 3 prototypes for this method and only one is documented.
In order to help us identify the problem, could you be more specific?
Could you also either post a list of other errors which you have noticed, or send this list to me directly?
Finally, to answer your question, I will be happy to provide any corrections to the existing documentation for the next release, which is next week, in fact. I cannot, however, extend the documentation at this point to cover prototypes or methods which were not in the original project manual, as I have no resources to do so.
Nonetheless, if you think that something should definitely be documented, let me know your arguments for it.
Best regards,
Douglas McCarthy
Wed, 02/23/2000 - 12:20
Mikael,
I've taken a second look and seen the problem: a Boolean is returned.
I'll correct it for next week.
Do let me know what other questions or observations you have.
Best regards,
Douglas
Wed, 02/23/2000 - 16:36
> Mikael,
> I've taken a second look and seen the
> problem: a Boolean is returned.
> I'll correct it for next week.
Thanks.
> Do let me know what other questions or
> observations you have.
Yes I will, there is the same error in the ocaf.pdf file at page 41.
Mikael
> Best regards,
> Douglas
Sun, 02/27/2000 - 20:11
Hi !
The documentation on the function services is also very sparse, examples are very helpful and would be very useful, at the moment the description of the function services does not say much at all (it's just one page).
Mikael
Mon, 02/28/2000 - 10:05
Hello Mikael!
The function services are very useful and increase the capabilities of OCAF. I'm very sorry that the documentation on this functionality is so small. Let me describe a little (briefly) the usage of the function services: About classes of TFunction package: Function. It's an attribute located at a label. It contains the GUID of a driver (a driver is a class inherited from TFunction_Driver). Driver. A pure virtual class which contains a very important method Execute(). This method contains the algorithm. DriverTable. This class is a static container of drivers. The usage of the function services. 1. Create a tree of Your model using TreeNode attributes. 2. Set a Function attribute to each node. 3. Create a child class inheriting from the Driver class implementing the method Execute() where You must realize the algorithm. 4. Set the driver to the DriverTable. Now You may move from a node to another one in Your own specified order and invoke the algorithms of Your drivers.
I agree that it is not very clear. But I hope an example of the function services usage will appear soon.
Good luck,
Vlad
Wed, 03/01/2000 - 23:42
Hi !
Does this mean that I use the function services for example if I have a shape made up of a boolean operation between a sphere and a cylinder forming a hole trough the sphere, and then I change the radius of the cylinder (bigger/smaller hole), then the TFunction_Driver should take care of updating the shape by performing the boolean operation again ?
Mikael
Thu, 03/02/2000 - 11:30
Hello Mikael!
You are quite right!. In Your example the tree may consist of three nodes: SHPERE, CYLINDER, CUT. You may regenerate them from up to down in the tree starting from the modified node. In this example it is CYLINDER. So, You have to execute CYLINDER, then CylinderNode->Next(). It is CUT. Another way is to implement the pure virtual method MustExecute() from TFunction_Driver. For this example: SHPERE: its argument is radius (TDataStd_Real attribute located somewhere), ... . The shpere's driver knows where its argument is located (what the label it is attached to). It may check if it is modified. CUT: its arguments are the SHPERE and the CYLINDER. In Your example the CYLINDER is modified. So, the CUT must be regenerated.
For a complicated data model it is very good to have such an optimized algorithm which allows to save time for computation.
I hope that more examples on the function services will apear soon.
Do You have any ideas how to compute a data model in optimization mode? Do You have any improvements? I'd be glad to recieve them from You (and not only from You).
Best regards,
Vlad
Fri, 03/03/2000 - 02:22
GUID !
When I want to have multiple tree nodes atached to one label I need to use explicit GUIDs, how do I create new unique GUIDs for my tree nodes ?
root main -> node1->label1 node2->label2
label1
label2
Mikael
Fri, 03/03/2000 - 08:51
It is possible to use any GUIDs as You want. You may generate them by means of guidgen.exe or to write by Yourself. Every tree must have its own GUID. The nodes of the different trees may locate the same label. The difference between them in GUIDs.
Good luck,
Vlad
Tue, 03/07/2000 - 16:00
Mikael and Vlad,
The documentation on Function Services is sparse on purpose.
This package is one approach, but the part demo used in Linux Expo did not use Function Services at all.
Perhaps a developer can write here about what the alternative is.
Best regards,
Douglas
Thu, 03/09/2000 - 10:22
Hello Douglas! Hello Mikael! Hello all!
I'm glad to recieve a message from You and to continue the discussion on Function Services.
My opinion is that the missunderstanding does concern the therminology. When I speak about function services I mean all the functionality provided by the TFunction package: the class Function, the class Driver, ...
The demonstration in Linux Expo used the class Driver from TFunction. So, the part demo used the function services. Just a feature is modified, all the other features concerned the modifications must be recomputed. It's a conception of the function services. There wasn't used the class Function from TFunction package, because this class is an indicator of a label only, and it is possible to indicate a label in another way (for example, by TDataStd_TreeNode or UAttribute). Do You agree with the definition of the Function Services? Do You have another one? Do You remember how You surprised me saying that TFunction_Function class is not removed from the TFunction package?
Hope to see You once again (and again),
wishing GOOD LUCK,
Vlad