It is just a Dialog from Resources
as a sample with 3 Gets and 2 Buttons
The resource looks like :
Obj Var Order ID
oGet1 cGet1 1 110
oGet2 cGet2 2 120
oGet3 cGet3 3 130
oBtn1 4 1
oBtn2 5 2
When I Press < RETURN > in cGet1,
oBtn1 gets the Focus not cGet2
In the ressource the order is ok ( 1 to 5 like in sample )
With RETURN, the next field doesn't get the focus
Greetings from Germany / Essen
U. König
Next Focus on Gets in Resources when pressing RETURN
Next Focus on Gets in Resources when pressing RETURN
Since 1995 ( the first release of FW 1.9 )
i work with FW.
If you have any questions about special functions, maybe i can help.
i work with FW.
If you have any questions about special functions, maybe i can help.
- James Bott
- Posts: 4654
- Joined: Fri Nov 18, 2005 4:52 pm
- Location: San Diego, California, USA
- Contact:
>With RETURN, the next field doesn't get the focus
It was standard behavior in DOS apps for Return to move from field to field. It is standard behavior in Windows apps for Tab to move from field to field. It is also standard Windows behavior for Return to cause the "default pushbutton" to be depressed. This allows the user to make a change to a field, then press Return to save the changes. No mouse required. No multiple Returns required.
So you are describing standard Windows behavior. I would not suggest changing it, as most other Windows apps work the same way. Even if you have users of an old app that are used to using Return for field movement, you are just purpetuating this habit which makes it more difficult for them to remember which way the app they are currently working in works.
If you still wish to change this behavior, then note that the default pushbutton always has an ID of 1. Change this ID to different number.
James
It was standard behavior in DOS apps for Return to move from field to field. It is standard behavior in Windows apps for Tab to move from field to field. It is also standard Windows behavior for Return to cause the "default pushbutton" to be depressed. This allows the user to make a change to a field, then press Return to save the changes. No mouse required. No multiple Returns required.
So you are describing standard Windows behavior. I would not suggest changing it, as most other Windows apps work the same way. Even if you have users of an old app that are used to using Return for field movement, you are just purpetuating this habit which makes it more difficult for them to remember which way the app they are currently working in works.
If you still wish to change this behavior, then note that the default pushbutton always has an ID of 1. Change this ID to different number.
James