Back and Forth Navigation between Access Forms? (1 Viewer)

[misscrf]

Forewarning. This is a very general question, though I will explain what I'm working on, to give as much context as possible. I'm looking for different ways people are handling the need to have the ability to jump back and forth and all over to different forms in an application - basically the challenge of good form navigation practices.

I have an application, which is a SQL back end, and Access 2010 front end, This app is one where a user can go, from the main menu, to a projects form. We have another system with all projects ever done, or currently being worked on. This application will allow users to add one or more of those (100,000 + ) projects to this system. Each project has many sub projects, and each sub project can have multiple project plans (of different types of plans). The project plans are the real meat, but that's not where my current challenge is taking place.

Project Proposals
Projects
Sub Projects
Project Plans

From Projects -
Find Projects
Add Projects to system

Right now I'm dealing with the projects interface. When a user opens that form, the detail is not visible, until they pick a project that they want to view. There is a combo in the header, with all the project names and numbers, which are currently in the system. The issue is, that it's becoming too long for users to be able to find the one they want to view. Part of the issue, is that they want to be able to type any part of the name, not just the beginning.

I researched the ways to allow a search in string with a combo, and it's not directly possible. It takes work around and with that info being tied to another system, the refresh is too slow. That made me move instead towards putting a button in the header, for "find system projects". This opens a pop-up form, for the user to type in a text box. A listbox has all projects and will filter based on what they type in the text box. This seems like a much more effective way to allow a use verify which projects are in the system currently, while allowing the user to search any part of the project name or project number.

Also on the main projects form is a button for adding projects to the system. Here is where we get into a bit of a complicated sticky wicket. If the user goes to the pop-up form to add a new project, or they go to the pop-up form to find projects in the system, they might want to jump to the other form (find or add), instead of having to close the pop-up they are on, be returned to the main projects form, and then go to the other form. This presents a navigation challenge. If someone goes a form, and it's a pop-up form, I don't close the previous form, I make it .visible = false. This way, it is still loaded, and I can check if certain forms are still loaded, to know where they came from.

So how do I make sure the user can jump back and forth, and be able to know where they came from, where they started, and what forms to offer for them to go to next? I'm just thinking there are probably good ways to handle this, and I'm looking to gain some expertise on the best ways to handle this, that won't require a bunch of custom code. I want a good universal approach, that can be implemented in other modules and sections with ease. Something that is repeatable.

I'm including a picture to illustrate top level the forms described above, and the navigation. The boxes are forms, and the arrows are the navigation back and forth between the forms. I circled the ones I'm trying to figure out how to handle in a way that can be replicated to any similar back and forth in other modules in the application.

I mean, I can just put buttons in the footer for the other 2 forms and always have the ability to go to the one you want, regardless of where you came from, but knowing where they came from, can tell me about what they are doing and if they might want to take info with them, to the next form.

For instance, if a user adds a project, they might want to go back to the projects form and view that project. In that case, I'm not just navigating back there, I'm setting the project form's record source to filter to that record. Same with the find projects form.

Let me know if that makes sense. I'm just looking to see if anyone has figured out a cool repeatable way to manage this in Access forms. I'm a fan of public functions that I can re-use again and again and just supply 1 or a couple of parameters (like form names, captions, etc)

I have been flushing out this list, to help me identify what buttons I need for each form, if I'm going to explicitly put every button on every form. Some already exist and some need to be created. Some cause the form we are coming from (ie the one we are leaving) to be hidden, others to close that form. I am going to have to change a lot of code to address this, so I wanted to get advice from smart people before I settle on a plan.

here is a pic of that list:

Thank you for any who take the time to read this post and to give me any helpful thoughts.

 

[Uncle Gizmo]

Email and the mention of Free deleted, for obvious reasons!

Sent from my SM-G925F using Tapatalk

 

[Uncle Gizmo]

So how do I make sure the user can jump back and forth, and be able to know where they came from,

Breadcrumbs springs to mind.

I believe there was a Smart Access article on it years ago basically you add "breadcrumbs" to your forms, they look like a URL containing folder names but instead of folder name's it would be the names of the forms that brought the user to where they are.



Sent from my SM-G925F using Tapatalk

 

[misscrf]

Breadcrumbs springs to mind.

Yeah, I was thinking of something like that, but I wasn't sure if I could handle it in public functions, so I'm not having to explicitly keep track of the form's names in the code, with passing arguments and such. I'll have to do some searching on Access forms and bread crumbs.

 

[Pat Hartman]

I use a simplistic method. When formA opens formB, formA passes its name using the OpenArgs argument of the OpenForm method and then hides itself. Having multiple forms open at once just confuses people so unless formB is a popup which I use when I actually want formA to remain visibile for reference, formA always hides itself.

The downside of this is I can end up with a half dozen forms open but not visible. The other issue is that it fails if you take two paths to the same form without retracing your steps since I am not opening multiple instances of a form (that is a whole different problem) so you need to be aware of that possibility and prevent it.

So formA --> formB --> formC --> formD --> formB = problem because you will never get back to formA since formA is superseded by formD.

When formB closes, it checks the OpenArgs and if there is a value, it opens that form making it visible again. Otherwise, it opens the main menu.

 

[misscrf]

Pat, That's a pretty good summary of my issue. Users will generally go in one direction, but they can bounce around a bit, and that makes this complicated.

I'm still pondering this and will be thinking on it over the weekend.

My head hurts lol.

 

[Uncle Gizmo]

Yes I was right it was Smart Access and I have found it!

http://www.vb123.com.au/200509_aw_breadcrumbs.htm

Sent from my SM-G925F using Tapatalk

 

[static]

In your diagram 'find projects' should come before 'projects'. Infact you should remove 'Projects' and 'Add Projects' from the list.

You're either adding a new record or editing an existing one. Therefore, you need to determine what the user needs to do, so the find screen should be the main screen.

If the project is found, open the edit form, otherwise open the add form (you probably don't even need two different forms since the fields will be the same.)

If doing a search in the existing form is slow, it doesn't make sense to me why a search in a new 'find' form should be any faster. What's the difference?

 

[misscrf]

Thanks for your reply. The add projects has a text box and 2 list boxes. The left listbox has every project that is NOT in the system yet. You can use the textbox to type a filter, as there are over 80,000 not in the system. Double-click one, to move that to the listbox on the right, for adding to the system. single click as many as you want, and use an arrow between the 2 listboxes, to move them all over to the right. Then click to add them, and they get added (vba stuff). The right listbox is cleared out, after they are added, and the left listbox is refreshed to not include any that are in the system, which now includes those 2.

The find form has 1 listbox, with all the projects in the system right now, and a text box to filter the list with a text stream.

That being said, you have some good points. I could probably consolidate this to 1 form, with the left listbox being switch to whats in the system or what is not. That will take some work, but I can certainly do that. You also make a good point about having the add/find/pick one to edit on the main menu, instead of the edit form. It is not ideal that they go to the edit form, without a project to edit in hand. There is a drop down on that form, with all the projects in the system, so they can pick one right on the form, if they know the name/what the name starts with.

I was thinking about this over the weekend, and I was starting to think I should just include a type of "nav bar" on every form. It would have a button for every other form. Make it all totally independent. They can move from any one form, to any other, and instead of making forms invisible, I close them every time.

Does that sound like a good way to handle the overall design? Any pitfalls I should consider first?

Thanks for the thoughts. Definitely some good stuff to consider.

 

[jleach]

Not sure how well it applies to what you're trying to do, but I've done navigation via left sidebar approach before. Basically there's one (shell) form, which has a somewhat narrow left subform containing the navigator, and the right side being the "content area" where the content for the current selected navigator is displayed. The content area is a subform (or a bunch of subforms, depending on how you want to set it up).

I thought this was a nice system for a few reasons, but major ones being:

1) the display of the main content area can be loaded dynamically, and you have full control over whether they become hidden or released from memory altogether. In a small app with a known number of main forms, you can have a subform control for each and leave their SourceObject null until you load that form (and thus once a form is loaded, it can stay loaded even when you hide that subform control and display another). In a more robust scenario, you would have a single subform control, but could still manage the form objects themselves via a collection to help optimize lazy loading, object caching and not having to worry too much about state persistence.

2) On the navigation end of things, I've found that sometimes a tree-style control can help for the ability to really move around, if the flow of available forms makes sense. Also, having the navigation as an embedded subform means you can do whatever display you want, and also may lend itself well to searching (for projects that aren't in the system yet, for example). Sometimes I really wish Access would allow on-the-fly control creation in compiled apps, as it would make display jobs like this a bit easier, but there's ways around it anyway. You can even take that navigation subform and throw a tab or two in it: one for main navigation, one for more advanced searching, etc.

Ultimately what you wind up with is a navigation and content area contained within a shell, and the shell acts as the controller for what's displayed, what's cached, what your breadcrumb trail is (your breadcrumb visual can be displayed above the main content area). Then your forms don't really need to know which one called it, you always have a single nav area and don't have to manage new nav objects for each form you open, so on and so forth. It makes for a nice disconnected, uncoupled navigation/display module so you don't have to bleed that logic into your main forms.

Thought I'd throw it out there. Cheers,

 

[misscrf]

Thanks, JLeach. I'm thinking I will need to make the nav bar a subform, and put it on the other forms, for 1 reason. Some of my edit forms, like for project plans, have subforms and sub/sub forms. I don't think I can go that many deep. It does mean I don't get the advantage you have, where you are only loading 1 form and just switching out the subform control. If I would have been able to do that, it would have been really slick. One of my edit forms has 3 subforms on the top, in a tab control. The bottom half has a tab control with about 13 tabs & subforms. It's just so heavy, I don't think imbedding that as a subform would work well. Just too much. Some of the other edit forms are way smaller, which will make resizing an issue.

Your solution sounds great, though.

 

[isladogs]

Jack

I think it would be appreciated by many if you could offer an example database to illustrate your ideas. I've seen something similar on 'another forum' but AFAIK there isn't a similar example here.

Someone else may correct me on the last point ...

 

[jleach]

From a performance standpoint it shouldn't really matter: it's two additional fairly lightweight, unbound form objects that are in memory, which shouldn't cause problems on any reasonable modern machine. For nested subforms, you can theoretically have as many as you like. The biggest trick there is to make them look nice, which is easily enough done with a shell form, as the shell itself is almost indiscernible from the rest.

Also theoretically, you can take any standalone form and drop it into a subform (like a "main content" area of a shell) with no fundamental side effects (you may have some code that does certain things based based on the assumption that it's a standalone form, but from a core functionality level there's really no difference between an embedded and non-embedded form).

Regarding the sizing of edit forms, this is an issue not specifically related to using a shell host. Using any of the newer versions of Access in tabbed mode would present the same problem, and even in the older MDI mode it was usually either a) a popup, or b) a full-coverage form (which we used to be able to mitigate to an extent by using Lebans' Set Background Color). Anyway, I'd expect most any size-specific form to be a popup anyway.

All that said, the layout won't work for all, no doubt. Cheers,

 

[jleach]

Hi Colin - this is about the best I can do on short notice. For a sample db... free time isn't what it used to be.

 

[isladogs]

Hi jack

I'm just pleased to see you giving up your time to be here.
The inline attachment didn't work however.
Was that just the image as well?

 

[jleach]

The inline attachment didn't work however.
Was that just the image as well?

Yes, I tried via the Insert Image button, then again via attachment. The Insert Image button wanted a link so I uploaded to imgur, but that didn't seem to work.

 

[misscrf]

The attachment works for me. Ridders it is a pic (a png) not a db. It illustrates what he is describing and looks even nicer than I imagined. I really love the look of it. I think I can still do it as it's own subform component, which I can put as a piece into every form, where I need it. It would work the same way an includes works in web development, sort of.

I love this kind of solution. I'll figure out passing args when needed, afterwards. I'm sure I'll figure it out. Many times, cleaning things up to be more universal, makes the rest of the challenges easier to solve. I always prefer a universal (public function sort) way of solving problems, over having to have a custom written solution for each challenge that needs to be solved.

 

[misscrf]

JLeach, I'm still unclear how I can compensate for different sized forms. All my forms are not a maxmized window. I used overlapping forms, instead of tabbed. I also always have forms sized to the biggest they need to be, based on the controls on them. So, often times no 2 forms are the same size. That may be my problem but I'm generally not wanting a form to be bigger than it absolutely has to be.

Make sense?

I'll wait for you to educate me on how this is horrible design practice lol.

 

[isladogs]

I agree. The form design is very nice - exactly what I'd seen elsewhere.
There is an example db showing this layout at another forum but I am unable to provide a link.

Just look up sidebar menu or similar

 

[jleach]

With overlapping forms, this isn't really going to be the best design. I generally prefer overlapping forms myself, but I have no means to turn this into a psuedo-MDI container, so if you did want to use this approach, you'd probably have to redesign some things on your end to make it fit, and/or utilize your forms as popups, if it makes sense to do so (often it does: popup supplier editor for when you click Add Supplier on a main item for, for example). The main forms though (Panels, as I refer to them in that project), would have to be designed accordingly.

The anchoring that newer versions of Access has helps a bit (certainly light-years ahead of older methods), but still nowhere near as nice as web-based layouts. Another trick is to keep the background color of the undersized "panel" form and the background color of the shell the same color (white, or whatever), then have no border on the subform control. This gives the impression of it being all one "maximized within the shell" form, even though it's not.