Finding Scrolled position in Access forms

[RJosephNewton]

Hi Folks,



I have a very large data entry form in my application, and I need a way to programmatically find the scrolled position of a a form. You can do this in a VB form by doing an API call to GetScrollPos with the hwnd of the control. From Access, I get Error 1447: that the object has no scrollbar.

Is there some more direct way to ascertain the current position of the scrollbars in VBA/Access?

Joseph

[pbaldy]

This type of thing?

http://www.lebans.com/SelectRow.htm

[RJosephNewton]

Im afraid not. That seems to relate to grid-type continuing forms. Mine is a single form. Each form is much longer thanas screen is high, so the actual detail must scroll within its window. It has mostly textboxes, but also two subforms, and I am trying to detect whether the mouse is over one of them.

This gets tricky because even though there are API calls to get the cursor position, the screen postion of the form, and the scrollbar information for the form, the last just doesn't work in Access. It returns an error telling me the form doesn't have any scrollbars. I also note that in Access only the parent form has an Hwnd, not any of its children, another difference from VB forms.

Right now, I guess it's academic. I just realized that this approach will not help with my current base problem, but I am interested in how this can be done. I'm really amazed that otheres haven't found this need and writtten about it, but all Google has is the stuff that works in VB but not VBA.

[NTC]

you write "really amazed that otheres haven't found this need ".....

what is the user experience benefit of this? it isn't intuitively obvious to me at all.....can you describe a typical scenario of this?

[pbaldy]

I think you'll find that most of us don't create forms that are longer than the screen. Tab controls are often used to organize a lot of info into a form that fits on the screen.

[RJosephNewton]

Thanks Paul, but that is not my call. This database was created 7 years before I came along, and the users like it to change only to the extent necessary to take care of new business rules. There is a lot of information to be gathered in a screening and they want it all in one place. One clone of this form is a tab on a tabbed interface already. The program exists for these busy support personnel, not vice-versa.

The overall scenario is a form that is a bit bigger than a page and about the same shape. I do contain all forms horizontally within the extent of the smallest screen used, but users need all the fields for any purpose in one place. The subforms are for open-ended lists that support personnel need to access and fill in during the screening. This is the tool that they are used to. My customers are an economically stressed service agency with its priorities on meeting human needs, and not on accommodating the limitations of technology or design. It's hard enough to get staff time for training on new features. There is certainly no time for training on a completely reworked set of tools.

[NTC]

I, for one, still don't get it; what is the benefit of:
"a way to programmatically find the scrolled position of a a form"

??

For intense data entry situations - the typist is generally going to be accustommed to the tab button in my experience....


otherwise the scroll bars can slide in any direction

[RJosephNewton]

OK. I see that I haven't really explained the setup on this thread. I started another one closer to the root problem.

This is actually part of a series of pieces I need to put together to ascertain whether a form is updating because the user is really done editing the record, or because they have entered a subform within the record, which triggers an update event. I use the BeforeUpdate event to prompt the user to save the current edit as a Screening event in the clients Client File History--essentially to log their work. I don't want to bother them with the message just because they are filling in a list in a subform. Unfortunately, the update happens before the Enter event for the subform is triggered, so I need another way to deduce that the prompt should be aborted.

Since I have set tab stop on the subforms to False, users must click into the subforms to shift focus there. Therefore if the cursor position is taken at that time, the window position relative to the screen, padding, and scroll position, that point where the user has clicked can be compared to the bounds of the subforms to ascertain this.

Darn, that's circuitous, huh? I would love to hear of some more direct way to figure out during the BeforeUpdate event whether the update was triggered by entering the subforms or by actually changing records or closing the form.