Brad Marks
BradM at blackforestltd.com
Mon Sep 10 13:23:25 CDT 2012
Charlotte, Could you elaborate on your "garbage disposal called CleanAll" that you mentioned when writing about Switchboards? Thanks, Brad -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Saturday, September 08, 2012 2:27 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Switchboard My apps have a distinct mission, they aren't general purpose. So I use a "menu" form as a navigation tool to the distinct features of the particular app. I'm at the end of my current contract, and the last app I built won't be deployed, but I did a couple of experimental things in it to try to approximate some of the stuff I've done in dot net. That app contains about 26 forms and 11 subforms, which all get displayed on one of three tabbed interfaces selected from the menu. It would have been more efficient and would have been faster if built unbound using ADO, but this was one of those projects where the requirements were being extracted with dental forceps right up to the end, . One experiment was to simulate nested tab controls, which is messy in design view, but works like a charm at run time. Another was a user-defined system form which is opened hidden by any form if it isn't already opened. The hidden form serves as the control tower for the application. I keeps track of the current open form (parents and popups) in an in-memory list so that when a popup (not a dialog) closes, the application can step back to the appropriate location.It also keeps track of the currently selected primary keys for the application, which in this case was MbrID, CaseID, and RequestID--all autonumbers. The hidden form is a substitute for what I've done in dot net with a creatable class object. The various forms and subforms are all bound to a custon form class and part of their code sets up an event sink on the control tower form, so every one of them can retrieve the current member, case, and/or member request at any time. The custom form class sinks the individual form that initializes it. I created a HasParent routine in the class because most of the subforms were built to perform as popup forms as well, and some actions aren't appropriate when they're loaded as subforms. The TakeBackFocus routine tells the control tower to retrieve the previous form from its list and make that the current form. The class handles some of the garbage cleanup as well as containing standardized confirmation messages for discarding on editing or cancelling invalid records. And I have one lone macro, Auto_Close, which calls a garbage disposal called CleanAll that makes sure any memory resident forms, reports, etc. are shut down, just in case. The same routine is called when you close the menu form, but I like insurance. My contract ends in two weeks, so I'll never finish the app for the company, but I'm going to continue playing with the concepts. Charlotte On Sat, Sep 8, 2012 at 11:20 AM, Arthur Fuller <fuller.artful at gmail.com>wrote: > I'll show you mine if you show me yours, and in case any internet police > are reading this, I meant switchboards! > > I have several versions of the basic switchboard concept, which I would be > happy to share with you, and will send them to you privately, The one I'm > currently working on is based on code from our lister and guru Jim Dettman, > whose code I inherited and began to modify. My last version I also > inherited and modified. Both have virtues and limits. > > But I guess that what I'm after is an answer to the question, "If you don't > use a switchboard, how do you map the navigation into your app?" Do you > even begin with a switchboard or its equivalent, or do you immediately take > the user to the "Do Right Now" list of tasks? Which obviously may vary > widely from app to app, but nonetheless there could be an opening form that > lists, for example, "Overdue Invoices", "Purchase Orders Unfulfilled" and > so on as its top items, followed by general (i.e. time-insensitive) items > such as "Maintain Lookup Tables" which leads to a sub-menu of Regions, > Cities, Employees etc. > > Or would you prefer to begin with a list of Customers and drill down from > there? Ah! I think that I'm finally beginning to discover the abstract > nature of the question I'm asking, which goes much deeper than the most > desirable front end: What is the most intuitive hierarchy (not from the > developer's perspective, but the user's)? Do Actions lead to Objects and > then Events? Or to Events (i.e. Overdue Invoices) lead to actions, and only > after that lead to Info Forms such as Customer_Edit_frm? Of course, there > must also be a way to get to that form directly, but what I'm attempting to > address in this overlong question is this: should one design the interface, > whether switchboard or any other presentation model you use, most > immediately present the tasks or actions the user is facing upon login? And > in the latter case, ought we do dispense with the switchboard as the > initial presentation, and instead move right away to the "S**t we have to > deal with RFN (if English is not your first language, think about it) > list(s), which conceivably could be several subforms on an opening master > form, and a double-click on any item in any of the subforms could open a > dialog on same detail, and invite an action upon same item? > > I don't know. I'm groping for your approaches to these > questions/approaches. > > A. > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > > > > Website: http://www.databaseadvisors.com > > > > -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.