In the normal CET working model, users work on the drawing (World) as a whole. Whenever the user makes changes to the drawing, the modified flag in the World is set. The flag is reset after the World has been saved (to cmdrw file).

For the working model in Collaboration G3, users work on a subset of the collab files at a time. And changes are made to the project files independently. As a result, each project file has a modified flag, and this flag will be set when Collaboration detects that a change to that file has been made that file. The equivalent of saving those changes is submitting the file. This is when the changes have been committed to the project and the flag is reset.

Marking the files as modified correctly is important as it:

• Provides users with indication of which files have been changed
• Warns the users of potential loss of work if they attempted to close the file or project without submitting the changes

Typical examples of when a file is marked as modified:

• When Snappers are added to the drawing (assigned to active section), the active section file is marked as modified.
• When Snappers in the drawing are removed/modified, the corresponding Section file will be marked as modified.
• When the Section file have been renamed.
• When Papers have been added/removed from a Paper Group, the Paper Group file will be marked as modified.
• When Snappers have been added to the Paper Space, the owning Paper Group will be marked as modified.
• When the orientation/resolution of the Paper Space has been modified, the owning Paper Group is marked as modified.

Using the Undo Hooks System

For drawing space related actions, Collaboration uses the Undo system to detect the user’s actions and identify appropriate sections that have been affected. Refer to the example below on how this works for user insert Snapper actions.

Example: Inserting Snappers

Let us consider the case where the user inserts a new Snapper into the drawing Space. The expected result is that the inserted Snapper gets assigned with the Section Id (of the active section) and that Section file is marked as modified.

The associated UndoOp (in this case, UndoInsertOp) should meet the following.

• return couldModifyModifiedState as true (default)
• populate the appendReferred or appendReferredSpace appropriately. For the case of UndoInsertOp, appendReferred returns the inserted Snappers

Since the referred Snappers (or spaces) store the section Id, Collaboration can retrieve the affected sectionIds from the Undo hook and identify the file to be marked as modified.

For Custom User Actions/Tools

It is recommended that all user actions to the drawing spaces enabled by each extension to be undoable. This ensures proper handling of the modified states of Collaboration project files.

Use a suitable UndoOp classes available from core or defined your own (ensure the couldModifyModifiedState, appendReferred and appendReferredSpace is returned appropriately!).

Using Collaboration Interface to Mark Modified

For cases where the Undo system can't be used to mark files as modified upon some user action, there is an interface available to explicitly mark as modified.

Using the setSectionModifiedG3 method in Entity, pass in the desired modified state. The project file owning the entity will be marked accordingly. (cm/core/entity.cm)

public class Entity extends CoreObject : modify notice, abstract {
    //...

    /**
     * Set the section file as modified.
     */
    extend public void setSectionModifiedG3(bool modified=true) {
        if (isCollabEntityG3()) setSectionModified(this, modified=modified);
    }

    //...
}