UPD Mail Archive: UPD> Dependencies

UPD> Dependencies

From: Jim Sommer (sommer@granitesystems.com)
Date: Thu Sep 26 2002 - 08:55:21 EDT

  • Next message: NorbertSchade@oaktech.com: "UPD> glossary"

    I have been working quite a bit with implementing dependencies and have
    some comments for the group.

    Introduction To Dependencies:

    UPDF defines three types of dependencies - filter, message, select. All
    dependencies consist of one or more conditions. The conditions are AND'd
    together. Each condition can be either and EQUAL or a NOT EQUAL. Conditions
    are defined using unique IDs. Therefore, a condition appears as -
    MediaDuplex_Record.ID NOT EQUAL Simplex AND MediaType_Record.ID EQUAL
    Type_Transparency.

    Filter - A filter dependency defines a group of settings (it may be a group
    of one) that should never be displayed. If N conditions are defined for the
    filter and N-1 of the conditions are true then all settings that would make
    the remaining condition true are to be hidden. Using the conditions above,
    if media type is set to transparency then all settings with duplex not
    equal to simplex are hidden. Also, if duplex is not set to simplex then all
    settings with media type equal to transparency are hidden. Filters are not
    a very user friendly dependency but they do have their uses.

    Message - A message dependency defines a message that should be displayed
    when a group of settings (it may be a group of one) is selected. The
    message must have an OK and/or a Cancel button. If the user clicks the
    Cancel button then the last action performed by the user is undone. If the
    user clicks the OK button then a group of settings selections (it may be a
    group of zero) is automatically made. In addition, any of the features in
    selections may be grayed out and an information icon may be added to the
    feature to explain why it is grayed out. Using the conditions above, when
    duplex is not simplex and media type is transparency the message "You
    cannot duplex transparencies. Click OK to turn off duplexing. Click Cancel
    to undo your last change." is displayed. If OK is clicked then duplex is
    set to simplex, grayed out, and an information icon is added to the duplex
    feature. When the information icon is clicked, the message "You cannot
    duplex transparencies." is displayed. All this is defined within the
    message dependency.

    Select - The select dependency is really a degenerate form of the message
    dependency. The select dependency has no message and assumes the OK button
    is clicked. So, what you have is a group of settings selection (it may be a
    group of one, zero doesn't make sense) that is automatically made when a
    group of settings (it may be a group of one) is selected. In addition, any
    of the features in automatic selections may be grayed out and an
    information icon may be added to the feature to explain why it is grayed
    out. Using the conditions above, when duplex is not simplex and media type
    is transparency then duplex is set to simplex, grayed out, and an
    information icon is added to the duplex feature. When the information icon
    is clicked, the message "You cannot duplex transparencies." is displayed.
    All this is defined within the select dependency.

    Implementation:

    This is how I implemented dependencies to provide the results that one
    would expect from the UPDF definition.

    When the user interface is brought up, dependencies are run against the
    saved settings. This should not produce any messages or cause any
    selections to be made since the saved settings should be valid. Filters may
    cause settings to be hidden from some features.

    Each time the user changes a setting by either changing a standard feature
    (ie destination changed from top bin to left bin) or changing a composite
    feature setting (ie media changed from "plain letter in tray 1" to "plain
    legal in tray 2") dependencies are checked. The following steps are then
    taken -

    1) Save the settings before applying the current change. If the current
    change is a composite feature then set all the component features to their
    appropriate settings.
    2) Make all settings visible (undo any filters), ungray all features, and
    clear all information icons.
    3) Start dependency checking with those dependencies defined in the user
    policy file. The user policy dependencies may duplicate some of the device
    description dependencies but are assumed to be more appropriate. For
    example, the device description may define a select dependency whereas the
    user policy defines the same condition as a message.
    4) Check the conditions of each dependency and act on each as appropriate
    (filter, message, or select).
    5) If a select dependency is true or the user clicks OK on a message
    dependency then set the automatic selections and restart dependency
    checking (goto step 2) with the new settings.
    6) If the user clicks Cancel on a message dependency then stop checking
    dependencies and restore the saved settings (from step 1).

    I made this mistake in another email so I want to note that if a dependency
    grays out and/or adds an information icon to a feature then you do not have
    to write another dependency to ungray the feature and/or remove the
    information icon. I do this in step 2 above. I think we should make this
    part of the definition of UPDF dependencies - When a dependency is no
    longer true, features will be displayed normally and information icons will
    be removed.

    Dependencies and Composite Features:

    Dependencies can be defined using standard features or composite features.
    A condition can be MediaDuplex_Record.ID != Simplex AND MediaType_Record.ID
    = Type_Transparency or it can be MediaDuplex_Record.ID != Simplex AND
    Media.CompositeFeature_Record.ID = CF_Media_Transparency. Using the
    standard feature, all settings which cause media type to be transparency
    will cause the condition to be true whereas using the composite feature
    will only cause condition to be true for a specific composite feature setting.

    One other use of dependencies is for user extensible composite features. A
    composite feature record should not be defined that causes any dependency
    based on the components of the composite to be true. For example, if a
    media composite feature has the components media size, type, and source and
    there is a dependency that says #10 envelopes can only come from the
    envelope feeder then the user should not be able to create a composite
    feature record with a media size of #10 envelope and source not equal to
    the envelope feeder.

    I have not implemented this portion of dependencies yet but my plan is that
    during the definition of a composite feature record I will apply only those
    dependencies that have all condition features as components of the composite.

    If you've read this far, I hope I've helped you understand dependencies a
    little better. Please feel free to respond with questions and comments.

    Jim

    mailto:sommer@granitesystems.com
    978-486-3068



    This archive was generated by hypermail 2b29 : Thu Sep 26 2002 - 08:55:48 EDT