Is there any Value in Navigation Forms?

Collapse
X
 
  • Time
  • Show
Clear All
new posts
  • twinnyfo
    Recognized Expert Moderator Specialist
    • Nov 2011
    • 3665

    #1

    Is there any Value in Navigation Forms?

    All,

    I've done a very little research on MS Access' new "feature" called Navigation Form, and I'm not convinced of its benefit for complex activities. Hence, I have not even considered including them into any of my projects.

    Am I completely missing the opportunity of a lifetime here?

    It appears that nearly every post I've seen on this forum concerning Navigation Forms is that referencing them is complex and confusing and typically generates errors, especially when the Average Joe Access programmer tries to reference an object or control in the "old-fashioned way", but that referenced control is on a Navigation Form.

    While I understand there may be a few advantages to a Navigation Form over, say, a Tab Control, such as the embedded Subforms not loading until they are called through the navigation system, I have yet to be convinced of their advantage. Can anyone explain?
  • jforbes
    Recognized Expert Top Contributor
    • Aug 2014
    • 1107

    #2
    Hey Twinnyfo,

    My two cents…

    It’s my understanding that SharePoint doesn’t support the Navigation Pane or Switchboards, so the Navigation Control is a replacement solution for automating the navigation of a Database. I’m happy to report that I’ve not had the luxury of using SharePoint, so someone else that has experience with it might be able to shed some more light on the subject.

    I’ve seen no real benefit for a Desktop deployment other than it’s initially quicker to develop and with less VBA. The benefit decreases significantly as the complexity of the Database grows.

    The Horizontal and Vertical Tabs version of the Navigation Form is intriguing, but, as far as I know, Split Forms won’t work in a Subform, which is what has ruled them out for me so far.

    Comment

    • Seth Schrock
      Recognized Expert Specialist
      • Dec 2010
      • 2965

      #3
      The advantage that you mention about the subforms not all loading at the same time is probably the only benefit that I would say could make it worth using. I do have one database where my home page has many subforms. If I did this without using tabs of some sort, I wouldn't have room. If I did normal tabs, then it would take forever to load. So for this database, it is really nice. However, I don't think that I would use it very often. In this case it was more of an experiment on how to handle a database where there are multiple distinct user groups that have different roles in the database. Each group has their own set of subforms. So instead of having a different form for each group of users, I put them all on one form.

      Comment

      • twinnyfo
        Recognized Expert Moderator Specialist
        • Nov 2011
        • 3665

        #4
        Thanks to both for your thoughts.

        @Seth, you have an interesting deployment for your different users. I hadn't thought of using a nav form in that way, before. I have my own methods for managing multiple distinct users.

        Overall, because my usage of Tab Controls requires the availability of static data to which I must refer often, the nav forms wouldn't work for my purposes.

        Good for me to think about other options for when the need arises, though...
        Last edited by twinnyfo; Apr 23 '18, 02:18 PM.

        Comment

        • zmbd
          Recognized Expert Moderator Expert
          • Mar 2012
          • 5501

          #5
          Starting in ACC2007/2010
          MS started a push to force developers to use sharepoint by depreciating ADP
          In ACC2010, one could open, but not create, however they added webservices to sharepoint and ACC2010
          ACC2013, ADP is completely removed and webservices are deprecited (and so much more Removed Features in ACC2013 forcing users to move to the Azure or SQL-Server side alongside sharepoint to develop webbased applications (the call them apps now... :shrug: )

          With this move, as J point out the old switchboard etc... were depreciated (removed).

          So you are stuck with this Navigation Control to publish to the sharepoint site, you also can not use VBA within the forms, and linked tables are not supported - you have to use the dreaded lookup-field.
          The bigest issue I have with this is the lack of office automation between the macro driven sharepoint based webapp and the rest of the PC for which you need the VBA code. (headaches just thinking about that again).

          Some of the issues with the reloading of the subforms can be worked around by using a combination of the Tempvars collection and the docmd.browseto method.

          The only other issue that sucks with the navigation control is the vba-engine glich that occurs when the parent form property "has module" is set to true/yes.

          Otherwise, my end users like the interface. It's very weblike which is what they have become use to...

          Comment

          Working...