Position x, y in a scrollable, continuous form

[Lorenz Ingold]

I have an interesting problem. I have a continuous form, bound to a data
source, showing a number of records, one line per record, with a vertical
scroll bar. As far it is the "most normal thing" that Access can do. One
control of such a record is a push button, and when the user pushes it (by
mouse or by pressing <return>), I should be able to get the absolute
position (x, y) of the line of which the button was pressed; the problem is
the vertical position (y). Is there a possibility for that?

 

[Tom Ellison]

Dear Lorenz:

Here's a bit of a discussion I can offer on the topic. Maybe you'll see
some use for it.

The y coordinate for a row would seem to be somewhat like a "record number"
in concept. As such, there isn't one. Well, sort of.

Now, given any unique sorting of the rows in the table, there is a Rank that
can be generated. As a starting point for discussion, this might be useful.

But . . .

This rank would be based on a key (one of more columns) that together must
uniquely identify every row in the table. However, using natural data, such
a thing is tenuous.

If a user deletes a row, all the rows "higher" in the sort order would be
Ranked one less.

If a user inserts a new row, they move up.

If a user changes any of the natural key columns on which the ranking is
done, that row moves to another place in the ranking, and all the rows
between the new position of that row and the previous position would change.

So, implementing something like what you say would work best using an
autonumber / identity key. This would be capable of finding a specific row
no matter where it is in the sort order. If you change the sort order,
there it is. If you change one or more of the columns in the row so it
moves to a new place in the sorted order, there it is.

Now, this would allow you to keep the focus on the same record. However,
that doesn't necessarily sound like what you want.

Records do not have "absolute position". It is important to conceive of
them as being a bunch of chips thrown into a "bag." In the purest
theoretical sense, what you are asking is actually (to be quite blunt)
nonsense. But, if there is some reason behind your request that is not
nonsense, perhaps we can deal with that.

A simple concept here is: "a database is not a spreadsheet."

Please let me know if you found any of this at all helpful. Otherwise, it
was good exercise for my fingers.

Tom Ellison

 

[Lorenz Ingold]

Indeed I should tell what is the purpose behind my question. The user can
input data into the records, but there is (at least) one field that the user
might do some calculation to get the final value to put in. For this case
there is adjacent to this field a push button, that opens a little dialog
box representing a specialized calculator. I want position this calculator
such that the top border is exactly at the bottom of the active record,
exactly like the drop down part of a combobox. But "physically" this
calculator is a form, that is opened modal (so once open, the "background"
cannot move anymore) (or are there better "physical" solutions than a
form?). With Borderstyle=None even the dialog is not moveable, but I see
this not as a Must. The main problem is to get the y coordinate with respect
to screen or parent form, so that the dialog can open at the correct place.

 

[Tom Ellison]

Dear Lorenz:

I see now. I thought you wanted the position of the record withing the
table. But you want the position on the screen.

I have actually studied this problem. The simple answer is that it cannot
be done. If the user scrolls a continuous form there's no event and nowhere
to check where it is positioned.

The complex answer is, it can be done. You must replace the scroll bar with
a scroll bar control and change the recordsource every time it is scrolled.
You will then always know just where the from is scrolled. Given a unique
key from the current row, you can calculate it's rank relative to the first
row being displayed. That would then tell you the screen position of the
selected row.

This is really a fair amount of rather expert work just to get what you
want. I do not know of any other solution. If there is, it's probably
posted on Stephen Lebans site, so take a look:

http://www.lebans.com/

There are a number of exotic things there. I can't keep up with all of
them. They are superb, highly recommended, if what you want is there.

Tom Ellison

 

[Lorenz Ingold]

So I see that a solution could be worked out, but is not simple. The
www.lebans.com site can be a help for other problems; I didn't know it. In
the mean time a saw an idea that uses Windows API functions to find out the
Mouse pointer position. Maybe this could work, but again, some details must
be worked out. But the bad thing is, that this only is works if the user
presses the button with the mouse. If he uses the Tab to go to the button
and then presses it with <return>, then the mouse pointer does not help.
Maybe we will try the solution with taking an scroll bar control you told.
In all cases: Thanks for your help.