[AccessD] Form navigation

Right, I generally do the same thing, but I was referring to Tab Controls
on the forms, not tabbed navigation of objects. The system has to know not
only what subform was active, but which tab was selected displaying it
(hint, the same subform can be on parents on multiple tabs). I was won over
to a back button working in VB.Net.  If you're interested in seeing it,
email me and I'll knock out a set of stripped down classes as a demo.

Charlotte


On Wed, Oct 2, 2013 at 12:09 AM, Gustav Brock <gustav at cactus.dk> wrote:

> Hi Charlotte
>
> Yes, certainly, that sounds very close to what I need. Right now we use the
> navigation form for some of these tasks - a form's button changes colour
> when the form is open, things like that - but it has evolved slowly so a
> firm structure is missing. A backbutton seems like a very good idea.
> It should be noted, that we don't use the default tab-view for forms but
> moveable and resizable forms.
>
> Thanks for the input.
> /gustav
>
> -----Oprindelig meddelelse-----
> Fra: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com] På vegne af Charlotte Foust
> Sendt: 1. oktober 2013 19:20
> Til: Access Developers discussion and problem solving
> Emne: Re: [AccessD] Form navigation
>
> Gustav,
>
> I addressed that issue in an application by creating a hidden form that
> tracked all navigation within the app.  That form was the startup form and
> was not allowed to close until the application was exited.  I used form
> classes to control general  behavior of the forms and to pass form names
> into a tree class which the nav form could examine to get the current form
> as well as the previous.  It didn't matter if you clicked on a subform on a
> tab or you went to a different menu, the nav form kept track of the
> breadcrumbs and a back button could get you back to where you had been.
>  Each form registered itself when it opened or closed by raising an event
> that the nav form sank.  It's harder to describe that to implement, and it
> worked quite nicely.  It also handled popup forms from a button or
> hyperlink, so you could always find you way home.  Does that sound like
> anything you could use?
>
> Charlotte
>
>
> On Mon, Sep 30, 2013 at 7:52 AM, Gustav Brock <gustav at cactus.dk> wrote:
>
> > Hi Dan
> >
> > Yes, the forms are grouped. So within a group it is very easy to
> > navigate between the forms.
> > However, if one group is active and you need to jump to a form in
> > another group, you have to travel to the top and then down the other
> branch.
> > If Arthur finds his treeview menu I'll study that, though one problem
> > with treeviews is that all leafs appear equal. This is fine in many
> > cases but probably not here, because some forms are much more
> > important or frequently used than others.
> >
> > To further complicate matters I would prefer a system that is easy to
> > modify, as the application is planned to evolve quite a bit.
> >
> > /gustav
> >
> > -----Oprindelig meddelelse-----
> > Fra: accessd-bounces at databaseadvisors.com
> > [mailto:accessd-bounces at databaseadvisors.com] På vegne af Dan Waters
> > Sendt: 30. september 2013 15:51
> > Til: 'Access Developers discussion and problem solving'
> > Emne: Re: [AccessD] Form navigation
> >
> > Hi Gustav,
> >
> > With 50 forms I'm going to guess that you could create some groups of
> > forms that have related functionality.
> >
> > Perhaps a wide narrow form at the top of the screen could contain
> > several comboboxes where each one contains the names of those forms?
> > Users could tab into the combobox they want, then just begin typing
> > the name of their form, then hit enter.
> >
> > Or, perhaps just a list of form name labels from top to bottom in a
> > tall and narrow form at the left side of the screen.  Users could just
> > click the label to open the form they need.
> >
> > I do use a treeview in my app - and it's great because it shows many
> > records which are constantly changing.  But it takes a lot of clicking
> > to get to what to you want - and because the forms you use are rarely
> > changed there are better ways to allow users to quickly get at their
> > form.
> >
> > Good Luck!
> > Dan
> >
> > -----Original Message-----
> > From: accessd-bounces at databaseadvisors.com
> > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Gustav
> > Brock
> > Sent: Monday, September 30, 2013 5:06 AM
> > To: 'Access Developers discussion and problem solving'
> > Subject: [AccessD] Form navigation
> >
> > Hi all
> >
> > I'm working with an A2010 application to be used by about 100 users
> > from different business areas.
> > The users are trained and will use the app extensively.
> >
> > It has about 50 forms and a dozen reports. Currently we are using what
> > I believe is the native switchboard of Access (I didn't build it), but
> > I find it clumsy, and it takes too much screen estate even though all
> > users are equipped with 24" monitors or dual monitors. However, the
> > biggest disadvantage is that once a menu branch is chosen, the other
> > branches are hidden, so if you are working in different corners you
> > have a lot of going up and down in the navigation form.
> >
> > Could anyone suggest a proven alternative? The treeview is gone, I
> > believe, but how about the ribbon? The users are using some of the
> > general options on the native band, so how would you combine those
> > with custom options?
> > Other ideas?
> >
> > /gustav
>
>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>