Robin Lawrence
lawrence.robinr at gmail.com
Sun Aug 28 07:27:35 CDT 2011
Hi all, As I've always been a part time Access developer so I don't often contribute to the list, but I'm always lurking. I've written a ticketing application for a theatre run completely by volunteers with many retired people and non computer users amongst them. I designed the application as a 'wizard' by using tabbed pages with hidden tabs in a subform, using large green left arrow/ right arrow icons to move forward or back (previous tab / next tab) as necessary. Validation is carried out as the icon image is clicked, and appropriate messages displayed to persuade the users to do the required. Seems to work well and I've converted many of those users who said 'Oh I can't use a computer!' But that was as much to do with training and talking to them as the interface...... Regards Robin Lawrence training ----- Original Message ----- From: "Arthur Fuller" <fuller.artful at gmail.com> To: "Access Developers discussion and problem solving" <accessd at databaseadvisors.com> Sent: Sunday, August 28, 2011 12:36 AM Subject: Re: [AccessD] User interface > You and I differ on this point significantly, but that's ok with me. > > My take is that the user should be able to view any number of forms at any > given moment. Granted, some forms will open in Dialog mode, but that > exception aside, I see nothing inherently wrong with having, say, the > Customers form and the Orders form open simultaneously. Yes, I have to add > a > bit of code to synch them (i.e. choose another Customer and the Orders > form > automagically goes to that Customer's most recent Order) > > This is not about arguing that my strategy is better. This whole thread is > about learning how other developers approach the UI problem, so anything > said by me or anyone else participating in this fruitful thread should > bear > that in mind. > > I think it was Gustav, but it may have been Colby, who submitted a class > that deals with the "focus" issue; with a couple of declarations, any > given > form is handled automagically. In the given sample code, the control with > focus was turned Cyan. IIRC, there was a problem with coloring combo-boxes > and list-boxes, but for all other controls it worked beautifully. I didn't > use that code in my most recent app, so I'd have to back-track and dig it > up, but it was very slick. > > One other question I'd like to add to this thread: does anyone make use of > the Wizard concept? There are several ways to build Wizards, but I wonder > whether anyone has bothered to build them into an app. I am trying to do > so > in my current client's app, the idea being that when you create a new > Customer, you must also create at least one Customer_Locations and after > that, at least one Customer_Location_Project -- this all to be done within > the wizard; Then the backdrop, as it were, has been set, and thereafter > all > the combo-boxes can be populated with meaningful data. The FE also allows > additions to the various combo-boxes, but ideally the wizard pre-empts the > necessity to do so. > > A. > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com