MemoWindow, OpenWindow

These properties are supposed to let you handle memo fields the same way you did way back before FoxPro even had the @…EDIT command, let alone all the goodies we have now. In those days, you used an @…GET for memos, and the user pressed Ctrl+PgDn to open an editing window. It was a major improvement in FoxPro 2.0 when you could specify a window of your own defining and have the memo window open up automatically, as soon as focus hit the @…GET. (@…EDIT was even more of an improvement, of course.) MemoWindow mimics the first piece—letting you specify the window. OpenWindow is supposed to provide the second, but it’s broken. Since we can’t see any reason to do things this way, we don’t consider it a terrible problem. Nonetheless, read on.

Usage

txtTextBox.MemoWindow = cWindowName
cWindowName = txtTextBox.MemoWindow
txtTextBox.OpenWindow = lAutoOpen
lAutoOpen = txtTextBox.OpenWindow

MemoWindow seems to behave as expected. The memo field uses the specified window instead of the default.

OpenWindow doesn't do a blessed thing. Turn it on, turn it off, no matter. To open the memo window, whether the default or one you've defined, you have to press Ctrl+PgDn (or Ctrl+PgUp) or double-click on the text box.

Even if it worked, we’d recommend you don’t use these properties. Users shouldn’t have to know about the internal structure of their data, and showing them the term “memo” forces them to. Use an edit box for memo fields. We think that separate memo field windows may be needed in some circumstances, especially where the client is looking over long, narrative-type information and wants a full-screen view. We would probably design this as a small edit region on the form, with a Zoom button to go to a full-screen view. The full-screen view would really just be a modal, draggable, resizable black-box form with an edit box occupying all the form’s real estate. This way, you can still have full control of the edit box’s properties and events.

See Also

EditBox, Modify Memo, TextBox