Dynamic or not Dynamic Help, Help!

Dynamic or not Dynamic Help, Help!

• Niaz

  The context service looks up the keywords in the Help system and then filters the list of returned topics based on the attributes in the Active Context Collection. See the Help page named "Dynamic Help Window Implementation" in your VSIP SDK for guidance.
  
  Here's a somewhat clunky illustration:
  Let's say you have a dialog box that you want to provide Help for. A single keyword (say, "ThisDialogsKeyword") can be associated with the dialog box for the purposes of context-sensitive Help. But along with that keyword, you could push an attribute to the Active Context. The attribute could be named "UserLevel", and you could have an enumerated set of values assigned to that attribute, such as "General", "UnitMgr", "Admin", and "SuperAdmin". Perhaps you have a way of identifying the user level of a person when he or she opens your app. Let's say you do it by having users log on. The appropriate "UserLevel= " value could be added to the Active Context based on how a user has logged on.
  Meanwhile, in your Help file, you have two Help pages about this dialog. One is for general staff, and one is for unit managers and admins. The page for the general staff would have two pieces of metadata assigned to it:
        <MSHelp:Keyword Index="F" Term="ThisDialogsKeyword" />
        <MSHelp:Attr Name="UserLevel" Value="General" />
  And the Help page for other staff would have this metadata assigned to it:
        <MSHelp:Keyword Index="F" Term="ThisDialogsKeyword" />
        <MSHelp:Attr Name="UserLevel" Value="UnitMgr" />
  
  When Help is called from that dialog, a two-step process would occur:
  1. The keyword is passed to the Help engine. All pages in the Help containing that keyword would be returned.
  2. The attributes of the returned pages would be compared to the Active Context. Pages containing attribute values that conflict with the Active Context would be removed from the list that is displayed in the Dynamic Help window.
  
  Therefore, users logged on as "General" would see the Help page appropriate for them, and users logged on as Unit Managers or above would see the Help page appropriate for them.
  
  
  
  
  
  
  

• &amp;#34411;&amp;#35960;

  No, my last response was not what you needed. I misunderstood your question. My answer had to do with F1 support and Dynamic Help support. Instead, you want to control what appears in the Table of Contents (or the "TOC").

  Look up the Help page named "Managing Help Filters" in the VSIP documentation. What you want to create is a TOC filter for each different type of user you have.

  In basic form, here's what you'll do to acheive this:

  Assign metadata (called "attributes") to each of your Help pages that identifies which user(s) it is appropriate for.

  Write definitions of TOC filters, based on the attribute values you have assigned to each type of user. You'll define one filter for each type of user.

  Register the filters as part of your collection.

  Programmatically tie each filter to the appropriate UserType/Level, so that the Help engine chooses the correct TOC filter for a given user.

  The "Managing Help Filters" Help page in the VSIP documentation will get you started on this process. For an example of how TOC filtering manifests itself in the Visual Studio Help viewer, open the Contents pane of the Help. At the top you'll see a drop-down box labelled "Filtered by". Each list item in that box represents a filter definition that, when selected, reduces the TOC to a subset of the overall set of Help pages.

  
  
  

• ss23

  Hi.

  Its difficult to say wether your description helps.  I intend to only create one help file containing all topics and subtopics for all staff (Administrators, Unit Managers and General staff), then, when the user selects Help>Contents from the toolbar the system checks their UserType/Level (wether they are Administrator, Unit Manager or General Staff), and displays only the topics relevant to them (Making the non-relevant topics invisible).  This is because:

             o if I make changes to a help file, I don't have to reimport/refresh the help file in all 3 places (Unit Manager, Administrator, General Staff)

             o When installing the application the system will install the help file in its full context automatically, rather than asking the person installing the application for which usertype is intended on this machine (as this may vary).

  I am not (as-of yet) intending to create HelpProviders for the controls.

  Therefore I need the option of stating in code, something like

  Myapp.MyHelpFile.Topics("Administration\Setting Up A New User").Visible = False

  If the user is a Unit Manager or General member of staff (because this is not available in the application to these users).

   

  
  
• Dynamic or not Dynamic Help, Help!