Scrollbar positions...
- Thread starter Chatbox
- Start date
ChrisO
Registered User.
- Local time
- Today, 09:29
- Joined
- Apr 30, 2003
- Messages
- 3,202
G’day ChatBox.
Unless there is only one ‘portion’ (Row and Column) of the form visible to the viewer at any one time I think it might be rather difficult to know where the user is viewing.
(Particularly more difficult if something is on the screen but the user has ‘left the building’.)
I think a little more detail might be in order here.
Regards,
Chris.
Unless there is only one ‘portion’ (Row and Column) of the form visible to the viewer at any one time I think it might be rather difficult to know where the user is viewing.
(Particularly more difficult if something is on the screen but the user has ‘left the building’.)
I think a little more detail might be in order here.
Regards,
Chris.
So I can't get a scrollbar's scroll unit? That kind of sucks.
Reason why I want to do this is to save the user's previous viewing position, so that the next time the user reopen the form or application, it'll pop back to where he/she was viewing last.
Reason why I want to do this is to save the user's previous viewing position, so that the next time the user reopen the form or application, it'll pop back to where he/she was viewing last.
Save the record position in a global variable, and if not null, use it when the form is opened. It won't be available the first time the form is open.
However, will every user always want to go back to the last position. I think not.
Another idea is to use some criteria in an unbound combo box in the form header to reposition the form, at users election.
However, will every user always want to go back to the last position. I think not.
Another idea is to use some criteria in an unbound combo box in the form header to reposition the form, at users election.
llkhoutx said:
The thing is, the form isn't bound.
I have setup user preferences, so the user can choose go to last position or not (using registry for VBA). Again, I need to know the scrollbars x or y position, or window viewing position.
ChrisO
Registered User.
- Local time
- Today, 09:29
- Joined
- Apr 30, 2003
- Messages
- 3,202
G’day Chatbox.
Can you hold off for a day or two, it’s taking some time. (Longer than I thought.)
Almost got it, current position needs to be saved to a table in the FE so the FE can restart at the same position depending on the login user. (We could push the table to the BE but at this stage I don’t see why…it’s a FE configuration table.)
It also requires handling form/subform combinations…
Regards,
Chris.
Can you hold off for a day or two, it’s taking some time. (Longer than I thought.)
Almost got it, current position needs to be saved to a table in the FE so the FE can restart at the same position depending on the login user. (We could push the table to the BE but at this stage I don’t see why…it’s a FE configuration table.)
It also requires handling form/subform combinations…
Regards,
Chris.
llkhoutx said:
yes, that I'm aware of...but so is VB. (In VB you can get a scrollbar's value, as you know)
I was hoping that upon Form_Close or Unload, I can read certain properties of the controls within the form.
Last edited:
ghudson
Registered User.
- Local time
- Yesterday, 19:29
- Joined
- Jun 8, 2002
- Messages
- 6,194
That works if the user has selected a record. But what if the user only scrolls through the records [just viewing]? I think that Chatbox wants to know how to remember where in the form the user was last at. Not sure why but I could also be wrong. If the form is that large [oversized for the screen] then maybe the design of the form should be modified or maybe the use of tabs will help the user navigate the form.
ChrisO
Registered User.
- Local time
- Today, 09:29
- Joined
- Apr 30, 2003
- Messages
- 3,202
G’day ghudson.
Point taken, didn’t even think of it. Might be another little demo coming up.
The Microsoft Forms 2.0 scroll bar has its position available and it works from A97 to A2K3. Don’t know how to use it to position a form vertically and horizontally but might be possible. If so the x and y positions could be save in the same table as in the demo.
I’ll give it a shot but don’t know what I’ll find.
Regards,
Chris.
Point taken, didn’t even think of it. Might be another little demo coming up.
The Microsoft Forms 2.0 scroll bar has its position available and it works from A97 to A2K3. Don’t know how to use it to position a form vertically and horizontally but might be possible. If so the x and y positions could be save in the same table as in the demo.
I’ll give it a shot but don’t know what I’ll find.
Regards,
Chris.
ChrisO
Registered User.
- Local time
- Today, 09:29
- Joined
- Apr 30, 2003
- Messages
- 3,202
This demo does not save the position; it’s just a test to see if this is the sort of thing required.
The X and Y scroll bar coordinates are ‘exposed’ so they could be saved in the same way the first demo does.
A bit more math to ‘jump the deadband’ on change of direction is also required.
But one thing at a time. (Could be useful.)
Regards,
Chris.
The X and Y scroll bar coordinates are ‘exposed’ so they could be saved in the same way the first demo does.
A bit more math to ‘jump the deadband’ on change of direction is also required.
But one thing at a time. (Could be useful.)
Regards,
Chris.
ChrisO
Registered User.
- Local time
- Today, 09:29
- Joined
- Apr 30, 2003
- Messages
- 3,202
G’day Chatbox.
You’re welcome but when you get to the ‘jump the deadband’ math it has been done before but not in Access as far as I know.
The aim is to keep a sign of direction of last movement and to add a constant offset when the sign changes. That’s the way it is done in process control applications when deadband is present in a process. (Absolutely a pain in the backside but has been overcome.)
In this case, the constant offsets would be the width and height of the form applied to the horizontal and vertical position respectively on change of direction.
Please also note; I left the size of the Text Box visible so people could see what’s going on, the height and width can be set to zero.
Anyhow, early days yet, let’s just try to get it smooth for the moment.
Regards,
Chris.
You’re welcome but when you get to the ‘jump the deadband’ math it has been done before but not in Access as far as I know.
The aim is to keep a sign of direction of last movement and to add a constant offset when the sign changes. That’s the way it is done in process control applications when deadband is present in a process. (Absolutely a pain in the backside but has been overcome.)
In this case, the constant offsets would be the width and height of the form applied to the horizontal and vertical position respectively on change of direction.
Please also note; I left the size of the Text Box visible so people could see what’s going on, the height and width can be set to zero.
Anyhow, early days yet, let’s just try to get it smooth for the moment.
Regards,
Chris.
ChrisO
Registered User.
- Local time
- Today, 09:29
- Joined
- Apr 30, 2003
- Messages
- 3,202
G’day Chatbox.
No need for the ‘jump the deadband’ math as it would lead to not being able to set the position mid-screen… my mistake.
Last values are now saved and retrieved. The criteria are the last time the user was on that particular form. When updating the table it might be an idea to remove any settings older than some period of time, let's say a week. That will keep the table to a reasonable size.
Although the table is for FE configuration it should go in the BE. That will allow the user to log onto any machine and retrieve their last settings, for any form that uses it, to the local FE they are at.
If there is a requirement for this panning to occur one more than one form then the bulk of the code should go to a standard module…haven’t done that yet.
Anyhow, version 4 is attached and thanks for the question…it was quite interesting.
Regards,
Chris.
No need for the ‘jump the deadband’ math as it would lead to not being able to set the position mid-screen… my mistake.
Last values are now saved and retrieved. The criteria are the last time the user was on that particular form. When updating the table it might be an idea to remove any settings older than some period of time, let's say a week. That will keep the table to a reasonable size.
Although the table is for FE configuration it should go in the BE. That will allow the user to log onto any machine and retrieve their last settings, for any form that uses it, to the local FE they are at.
If there is a requirement for this panning to occur one more than one form then the bulk of the code should go to a standard module…haven’t done that yet.
Anyhow, version 4 is attached and thanks for the question…it was quite interesting.
Regards,
Chris.
Last edited:
