• Odd form behaviour (2000 sr1)

    Author
    Topic
    #381906

    I am having trouble with a standard type of form with subform in terms of the behaviour of the enter/tab key. This form is very basic in terms of design and underlying tables of the Invoice and Invoice details type found in Northwinds the subform is linked on the the InvoiceID field. The form is set to cycle through all records.

    The odd behaviour results on the SECOND new record created. When I hit enter to jump to the subform, it jumps to the LAST field in the subform instead of the first. I have tested this by making a brand new database from scratch and it still keeps happening, which suggests there is something going on in Access rather than something stupid I did in the original database.

    Here is the scenario. I enter data using only the keyboard and use the enter key to move from field to field. The first record works fine in that when I jump from the main form to the sub, the cursor goes to the first field in the subform. When new data is done, I keep hitting enter to tab through the form and it will pop up a new record (since it is cycling through all records). This is the one that goes wonky. All is well until you tab into the subform. On this second (and all subsequent new records) the cursor jumps to the LAST field in the subform instead of the first.

    I am at a complete loss as to this behaviour. I have checked tab order, for stray code, tested it out on a brand new database and gone back and looked at existing ones and they all seem to be doing it. even if they cycle only on the current record.

    Am I missing something or is this weird?

    Peter

    Viewing 0 reply threads
    Author
    Replies
    • #645575

      In my experience, using the enter key like that generally results in odd behavior somewhere along the line. I’ve build apps that allowed tabbing between fields and in and out of subforms, though. Have you tried that?

      • #645675

        The problem is occurring regardless of whether you use the tab key or the enter key to move forward. The problem is quite consistent in always happening when one reaches the second and following records in a session of having the form open. It doesn’t matter whether it is an existing record and you are just scrolling through or a series of new records, whether you use tab or enter. On the second record, the cursor is going to the last field of the subform. Shift+tab is working in reverse. If you start at the end, it will scroll through all the fields and on the next (previous) record, it jumps to the first field in the subform and from there to the main form. (This is presumably standard practice as that is where the cursor is supposed to go in the tab order of the main form)

        Peter

        • #645681

          That sounds like you’ve got some code that gets executed the first time and affects the behavior after that. Check any code routines or property values that might be affecting your navigation. Could you be using a KeyDown or KeyPress event to trap and change key behavior in the subform? Could you have an OnEnter or GotFocus event procedure that is affecting this?

          • #645688

            That was my original thought because I was playing around with that when I was first designing the original database. However, this is now happening in all databases. I even made a quickie from scratch with no code whatsoever last night to test it and it does it there. Is there some place I could have placed offending code that it would affect all databases on this hard drive? i.e. that I’ve changed some sort of setting in Access itself?

            Peter

            • #645866

              Can you post one of your quickie databases as an attachment so some of us can test it for ourselves? If it behaves on other machines, it has to be a problem with the installation, but I can’t imagine what that might be. shrug

            • #646039

              I have continued to work on this and tried creating a similar quickie to the attached database at a friend’s place and came up with the same results, which leads me to believe that either I am truly jinxed, or, more likely, that I am missing something obvious in the table/form design and the relationships which I used to know (since lots of my old databases work fine). Hopefully it will be easy for you to find and I can slink into the ether. confused

              Peter

            • #646178

              OK, now I understand what you were describing. I never use datasheet subforms, so I was having trouble “seeing” what was going on. I know it’s confusing, but what is happening is that the cursor is going back to the field that it *left* when you tabbed or entered your way from the subform back to the parent form. By default, when you move to a new record (i.e., tab back to the parent form) on a single form, the focus goes to the first control on the form, but datasheets (and continuous subforms) don’t behave the same way. Notice, that if you use the navigation buttons to move between records, either from the parent form or the subform with the cursor in the subform, you see the same behavior–the cursor stays in the field it was in even though it jumps to a different record. You can fix it by putting something like this in the OnCurrent event of the subform:

              Private Sub Form_Current()
                Me.InvoiceID.SetFocus
              End Sub

              Here’s an alternative to using the actual name of the control, assuming that the first control in the collection is the right one of course:

              Private Sub Form_Current()
                Me.Section(acDetail).Controls(0).SetFocus
              End Sub
            • #646183

              Thanks for the help and the code. At least I won’t spend more time trying to figure out what is going on in the cases I was mentioning. It does still moot the question as to why the databases I have that are working “correctly” are working in that fashion (i.e. the cursor is going to the first field rather than the one it *left*). If only I knew what I did to make the other ones work properly without code! surrender

              Along the same tack, you say you never use datasheet subforms. What do you use, then? Single forms, continuous forms? Datasheet subforms in the type of application I am dealing with seem to be the most economical in terms of space and entry of info.

              Peter

            • #646186

              I generally use continous subforms designed to resemble datasheets. That way I can do things that datasheets don’t allow, like having hidden controls on the subform.

    Viewing 0 reply threads
    Reply To: Odd form behaviour (2000 sr1)

    You can use BBCodes to format your content.
    Your account can't use all available BBCodes, they will be stripped before saving.

    Your information: