Welcome To The Home Of The Visual FoxPro Experts  
home. signup. forum. archives. search. google. articles. downloads. faq. members. weblogs. file info. rss.
 From: Ken Murphy
  Where is Ken Murphy?
 Springhill
 Canada
 Ken Murphy
 To: Al Klapperich
  Where is Al Klapperich?
 Ripon, WI
 Wisconsin - United States
 Al Klapperich
 Tags
Subject: RE: access keys
Thread ID: 104592 Message ID: 104657 # Views: 4 # Ratings: 0
Version: Visual FoxPro 8 Category: Forms
Date: Friday, August 18, 2006 7:28:19 PM         
   


> > > > > Hi Gang,
> > > > >
> > > > > I in my forms, I have access keys defined for many of the buttons (N for Next, P for Previous, etc). I have [had? ;-)] the understanding that, you need to press the ALT key in order to activate them [Alt-N, Alt-P, etc]. Testing recently shows that I can press N, P, etc to carry out those function [if focus is NOT in a text box or a grid]. If focus is set to the Add button, I can press the N and my form will display the next record in the table.
> > > > >
> > > > > Obviously I don't want it to function that way. Any ideas?
> > > > >
> > > > > Thanks much!!

> > > >
> > > > Al,
> > > >
> > > > As Jim points out, the Alt+N/P is fairly standard Window behaviour so you probably do not wish to mess with it. You probably would not want to change the Alt+C (for copy) to just a C - your users would probably complain - loudly. On the other hand, the next/previous/top/bottom concept is fairly old. Consider a candidate list. Give the users a text box, a drop down list a "Find" command button and a grid all on the left hand side of your window. The user can enter some text, select a search type click the find button and the search procedure will populate the grid. For example, enter "Murphy" in the text box, select "Surname" as the search type, click the "Find" and the grid is populated with all of the customers where the surname begins with "Murphy". When the user clicks on a record in the grid, it populates the remainder of the window with that customer's details. If you have a large table, clicking next, next, next ... until you get to the right record can be a real pain.
> > > >
> > > > Ken
> > > > You shall know the truth - and the truth shall set you free. (John 8:33)

> > >
> > >
> > >
> > >
> > > Hi Ken,
> > >
> > > Sorry, maybe I didn't explain myself very well... I understand the Alt concept.
> > >
> > > You probably would not want to change the Alt+C (for copy) to just a C - your users would probably complain - loudly.
> > >
> > > I am having the opposite problem you are describing. The user CAN press just a C key. And yes - the user IS complaining because they DON'T have to press the Alt key. I don't want it to work that way either as it's causing data entry problems.
> > >
> > > The problem is not wanting to disable the Alt-[whatever] keys. Currently you DON'T HAVE TO use the Alt key to "click" that button. You press just the action key WITHOUT the ALT. As I try other Windows applications, I see that they all function that way.
> > >
> > > If there's no way to make only the Alt-[whatever key] be the sole way to activate a button by the keyboard - it'll have to go. I never realized that you could press just the bare key itself without the Alt to get the button to fire. To me this seems odd...
> > >
> > > While your interface suggestions are great, changing them at this point in time are not possible. Besides, in this particular application, doing a find as you suggest would not be as efficient for the user. Records are limited and they prefer it to be a bit more keyboard driven, not mouse driven. In some cases, newer is not always better ;)
> > >
> > > Thanks!!
> > >
> > > Al

> >
> > Al,
> >
> > OK, I think I see what you are talking about. For example, if you have a container that has a series of buttons in it, and if those buttons have short cuts attached to their captions ("\<Previous" for example) and if that container has focus, the user need only hit the P key to fire the .Click() of that button. This is in fact, normal windows behaviour. If the container does not have focus, the P key would act appropriate to the container that does have focus. For example if the container with focus had a listbox, you could hit the P key and the listbox would look up the first item starting with "P".
> >
> > If you wish to get rid of this behaviour, you need to do one of two things:
> >
> > 1 - you can containerize your command buttons. If the container containing the PreviousCmd button does not have focus, the P key will not send you to the previous record. If that container does have focus, pressing the P key will fire the PreviousCmd.Click().
> >
> > 2 - you can get rid of your command button shortcuts and use the command button's .KeyPress() event to check for an ALT+P combination.
> >
> > Again, I don't necessarily recommend messing with standard windows behaviour. Everything else works that way so your app probably should too.
> >
> > As to the interface suggestion, this works quite well in a data entry situation - no need for the mouse. On the form's .Activate, focus rests in the textbox, enter some text, hit enter; hit the first character of the search type, hit enter; hit enter on the find button and then down arrow to the appropriate record in the grid. Works well and reduces the "find time" for a specific record, especially in a large table situation, but also works well for small tables.
> >
> > Ken
> > You shall know the truth - and the truth shall set you free. (John 8:33)

>
>
>
> Thanks Ken!
>
> I will probably ditch the keycommand for those buttons. Just out of curiosity [and future knowledge]...how does one containerize something [in this case - buttons]. This is not something that I have done.
>
> Thanks much!


Al,

The best way to do it is to use a container class. Create a new container class and then place your next, prev, top, bottom buttons in it (along with the appropriate code.) Now when you create a form, you drop the custom container class onto that form. You will also need a container for your data controls (textboxes, grids, labels, etc.) that are used for entering data. This gives you two containers, only one of which can have focus. (The use of a custom navigation container class will speed up development. Let's face it, you will probably want the same four navigation buttons on all of your forms, so create it as a class and you only have to develop it once.) Set the tab order to your data controls container as 1 and to your navigation container as 2 and when your user opens the form, the data controls container will have focus - not your navigation container.

In my forms, I start with two containers. The first is the data controls container(where the user enters data) and the second container that I call a FileMaint container holds a series of three "sub-containers." The first of these sub-containers is a "Maintenance Controls" container that holds the New, Open, Save and Revert buttons. The second holds my navigation controls - a textbox, a searchtype dropdown list, a Find button and a grid. The final container holds a series of other buttons that are appropriate to the form. On most forms this container will hold at least one Print button, but if I have a number of reports that can be run, I will include one button for each report. Of course, all of these containers have been created as custom classes. I can drop my FileMaint container class onto any form, and half of the work is already done.

Hope this helps

Ken
You shall know the truth - and the truth shall set you free. (John 8:33)

ENTIRE THREAD

access keys Posted by Al Klapperich @ 8/17/2006 11:33:14 PM
RE: access keys Posted by Jim Winter @ 8/18/2006 12:43:41 PM
RE: access keys Posted by Al Klapperich @ 8/18/2006 4:45:19 PM
RE: access keys Posted by Ken Murphy @ 8/18/2006 2:06:22 PM
RE: access keys Posted by Al Klapperich @ 8/18/2006 4:40:29 PM
RE: access keys Posted by Ken Murphy @ 8/18/2006 6:26:21 PM
RE: access keys Posted by Al Klapperich @ 8/18/2006 7:05:16 PM
RE: access keys Posted by Ken Murphy @ 8/18/2006 7:28:19 PM
RE: access keys Posted by Barbara Peisch @ 8/19/2006 6:17:55 AM