[AccessD] Form navigation

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