Memo field scrolls to top on losing focus

[ChipR]

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,
Chip

[missinglinq]

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)>

[ChipR]

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.

[NeoPa]

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?

[ChipR]

Certainly this is a reasonable standard behavior. I just want a way around it for my application.

[NeoPa]

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.

[FishVal]

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.

[ChipR]

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.

[mshmyob]

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.

cheers,

[mshmyob]

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.

cheers,

[FishVal]

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.

• 
  

  Private Declare Function FlatSB_GetScrollInfo Lib "comctl32" (ByVal hwnd As Long, ByVal fnBar As Long, lpsi As SCROLLINFO) As Boolean
  Private Declare Function FlatSB_GetScrollPos Lib "comctl32" (ByVal hwnd As Long, ByVal code As Long) As Long
  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
  

  Do While SI.nPos <> lngLastKnownPos
      SendKeys "{DOWN}", True
      FlatSB_GetScrollInfo Me.fhWnd, SB_VERT, SI
  Loop
   

  becomes infinite due to (I guess) the previous paragraph.

[StewartW]

@missinglinq
Thank you so much.This was a huge help. StewartW, South Africa