By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,275 Members | 1,995 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,275 IT Pros & Developers. It's quick & easy.

Memo field scrolls to top on losing focus

Expert 100+
P: 1,287
I have a text box bound to a memo field. Regardless of where I've scrolled down to in the text box, when I click out of it, it returns to the top. Is there any way to prevent this?
Thanks in advance,
Oct 6 '09 #1
Share this Question
Share on Google+
11 Replies

Expert 2.5K+
P: 3,532
I did something like this a few years ago for somebody and the only way I could get it to work was to
  1. Create a second form with the same Record Source
  2. Add the one memo field
  3. Strip this form of everything you can, Nav buttons, Control box, Dividing line, etc. so you only have the memo field showing
  4. Go back and add this second form as a subform to the original form
Now you can scroll thru the memo field, and when you click out of it to another control on the main form, the memo field will remain in the same place.

This was done for someone who only needed to scroll thru the memo field to reference its contents. If you edit the memo field and leave it, it will return to the begging of the text. I could never figure out an answer to this. Maybe you or someone else can, if needed.

Linq ;0)>
Oct 7 '09 #2

Expert 100+
P: 1,287
Looks like I'll have to go the subform route for now. Thanks for the tip, and I'll let you know if I come up with an alternative.
Oct 7 '09 #3

Expert Mod 15k+
P: 31,660
I wouldn't think there would be a way to be fair. Is it just me or would you not expect the control to lose its edit position once the focus is lost? I know Memo fields are often fuller and need scrolling more than other types of field in a TextBox, but would this not be the standard behaviour of a TextBox control generally?
Oct 7 '09 #4

Expert 100+
P: 1,287
Certainly this is a reasonable standard behavior. I just want a way around it for my application.
Oct 7 '09 #5

Expert Mod 15k+
P: 31,660
I can't think of anything better than Linq's suggestion then Chip. I'm pretty sure all attempts to select what is displayed would get reset as soon as you left the subform involved. Sorry.
Oct 7 '09 #6

Expert 2.5K+
P: 2,653
Seems like a good way around is to store edit position in an additional field of a bound table. Edit position could be saved to the table in OnExit event handling code which is being triggered just before control loses focus.
Oct 9 '09 #7

Expert 100+
P: 1,287
That's a good point Fish.

To be more specifi, the text box that I have is actually only for viewing puposes. It lists notes that have been added to the memo field. Another text box is used for typing in new notes, then a button appends the new note to the memo field. With the subform, I can scroll down the notes, then click out and go add a new one and it won't reset to the top, but of course when the data is updated, it automatically scrolls to the top.

Perhaps I can save the length of the field in a local variable before I append to it, then scroll it back to that length afterward.
Oct 9 '09 #8

Expert 100+
P: 903
Hello ChipR,

Here is something I threw together using API's (my first attempt so no laughing).

It does what you want albeit a little slow with the scrolling. Unfortunatly just moving the scrollbox does not update the contents and I cannot get the 'sendmessage - user32' api to work.

Anyways try out the demo and let me know. If you improve on it please re-upload so I can see what you did.

I saved it in AC2003 format.

Attached Files
File Type: zip (63.4 KB, 232 views)
Oct 10 '09 #9

Expert 100+
P: 903
I noticed a bug after I was cleaning up the code and I removed something I shouldn't have.

try this version instead of the previous.

Attached Files
File Type: zip (62.5 KB, 226 views)
Oct 11 '09 #10

Expert 2.5K+
P: 2,653
Hello, mshmyob.

Without getting into discussion about feasibility of the WinAPI solution (comparatively to native SelStart and SelPos properties of Access.Textbox class) I would like to emphasize flaws of your implementation of WinAPI method.

  • Expand|Select|Wrap|Line Numbers
    1. Private Declare Function FlatSB_GetScrollInfo Lib "comctl32" (ByVal hwnd As Long, ByVal fnBar As Long, lpsi As SCROLLINFO) As Boolean
    2. Private Declare Function FlatSB_GetScrollPos Lib "comctl32" (ByVal hwnd As Long, ByVal code As Long) As Long
    3. Private Declare Function FlatSB_SetScrollPos Lib "comctl32" (ByVal hwnd As Long, ByVal code As Long, ByVal nPos As Long, ByVal fRedraw As Boolean) As Long
    All these functions are available in "user32" lib there is no need to use "comctl32" library.
    Scrollbar API
  • As far as I remember this child window (window class - "OKttbx" in Access 2003) which Access places over active control is being actually moved after GotFocus event has been handled. The window parameters you get using hWnd returned by GetFocus() API function are those for the previous state (rendered over a control which is about to loose focus).
  • And the last but not the least - SendKeys() which sends keys to whatever window is currently in focus. This is noticeable particularly in a case when
    Expand|Select|Wrap|Line Numbers
    1. Do While SI.nPos <> lngLastKnownPos
    2.     SendKeys "{DOWN}", True
    3.     FlatSB_GetScrollInfo Me.fhWnd, SB_VERT, SI
    4. Loop
    becomes infinite due to (I guess) the previous paragraph.
Oct 13 '09 #11

P: 1
Thank you so much.This was a huge help. StewartW, South Africa
Jan 18 '20 #12

Post your reply

Sign in to post your reply or Sign up for a free account.