You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Contains information about a "stream card" such as if it's a sender/receiver, selected branch etc. But also information about its previous receive operation, so that we can update elements of future receives.
Our Connectors handle stream state and consequentially the update behavior in different ways.
In Revit, it's stored in the stream cards and then in the Doc's extensible storage.
In Rhino, it's stored in the stream cards and on the object themselves.
In CSI products, it's stored in an external text file as there are no native ways to store custom data on the objects or documents.
The Problem(s)
Because of these different implementations, we have slightly different behaviors across the connectors.
For instance, in Revit the update functionality is entirely dependent on the Stream Card, if this is changed, the update capabilities can break.
If a different branch is selected, and new objects are received, the previously received ones are deleted as the update logic detects completely different IDs.
If the stream card is deleted and re-added, no update capability is preserved as the IDs are lost.
Proposed Solution
To be discussed, but perhaps storing the IDs on the objects themselves where possible, seems to be the most flexible option. In Revit it would require overcoming some potential performance challenges.
A good time to tackle this would be together with DUI3.
The text was updated successfully, but these errors were encountered:
The Stream State
Contains information about a "stream card" such as if it's a sender/receiver, selected branch etc. But also information about its previous receive operation, so that we can update elements of future receives.
Our Connectors handle stream state and consequentially the update behavior in different ways.
In Revit, it's stored in the stream cards and then in the Doc's extensible storage.
In Rhino, it's stored in the stream cards and on the object themselves.
In CSI products, it's stored in an external text file as there are no native ways to store custom data on the objects or documents.
The Problem(s)
Because of these different implementations, we have slightly different behaviors across the connectors.
For instance, in Revit the update functionality is entirely dependent on the Stream Card, if this is changed, the update capabilities can break.
If a different branch is selected, and new objects are received, the previously received ones are deleted as the update logic detects completely different IDs.
If the stream card is deleted and re-added, no update capability is preserved as the IDs are lost.
Proposed Solution
To be discussed, but perhaps storing the IDs on the objects themselves where possible, seems to be the most flexible option. In Revit it would require overcoming some potential performance challenges.
A good time to tackle this would be together with DUI3.
The text was updated successfully, but these errors were encountered: