in

The ORM Foundation

Get the facts!

exclamation marks on fact types

Last post Mon, Oct 27 2008 18:48 by Matthew Curland. 3 replies.
Page 1 of 1 (4 items)
Sort Posts: Previous Next
  • Sat, Oct 25 2008 13:05

    • rolemo
    • Top 25 Contributor
    • Joined on Sun, Oct 12 2008
    • Posts 38

    exclamation marks on fact types

     Hi Again...

    I can't figure out the meaning of the exclamation marks on some fact types (especially as there are no errors according to the list).

    any ideas? Smile 

    I've attached the list and the diagram, just in case.

    Thanks! 


  • Sat, Oct 25 2008 13:07 In reply to

    • rolemo
    • Top 25 Contributor
    • Joined on Sun, Oct 12 2008
    • Posts 38

    Re: exclamation marks on fact types

    opps...here is the list for the aboove post


  • Sat, Oct 25 2008 15:17 In reply to

    • rolemo
    • Top 25 Contributor
    • Joined on Sun, Oct 12 2008
    • Posts 38

    Re: exclamation marks on fact types

    Well I still don't know what was the problem, but I've erased the fact types and rewritten them, and the exclamation marks are gone.

    Though I'm still wondering how come the Error List didn't show any errors.

    Cheers 

  • Mon, Oct 27 2008 18:48 In reply to

    Re: exclamation marks on fact types

    I can't say for sure, but my guess is that you had temporarily introduced a duplicate name error into the model. Adding an error of this type puts two error overlays (the !) in the model browser, but only one of them goes away when it is cleared. This is not critical, it is just outdated information.

    There are five error display mechanisms, and the error state for each is maintained slightly differently:

    1. The Error List display is tied directly to the 'ModelHasError' relationship. Although the information is cached, this error set is very easy to manage because there is only one relationship to watch.
    2. The model diagram retrieves the error state on a redraw. If the state changes, a notification is required to force the displayed item to redraw. If there is a problem with the notification, then any redraw (mouse over, selection, cover/uncover, etc) will show the correct error state.
    3. The context menu error list is refreshed when the menu item is opened.
    4. The Verbalization Browser error display is refreshed when a transaction log completes playback (edit/undo/redo) or when the selection is changed. There is no caching.
    5. The model browser mechanism caches all state information used to organize and display the elements (element name, grouping, primary and overlay glyphs). The browser will not change the state unless it is explicitly told to requery the state for a given element. Most error objects have natural owners, and there is a catchall mechanism to handle updates for these case, but a handful of validation errors (especially the duplicate name errors) do not follow the standard pattern and need custom code to update naturally.

    Basically, the model browser (especially the error glyphs) is most likely to get out of sync with the true state model state. If you think an element is showing the wrong state, then delete the element and undo to reset the browser state information.

     I can't tell exactly what happened in your case without knowing your editing sequence. I'm sorry if this took you off task.

     -Matt

    PS You can fully reload an entire model without saving by using the Extension Manager to add an extension, then reopen the dialog to remove the extension.

Page 1 of 1 (4 items)
© 2008-2024 ------- Terms of Service