Modi Memo Window ..Name object access problem 1

[willh2]

Hi,
I have a grid with memo fields, the latter currently can be opened with command buttons (1 per memofield): These open predefined windows (so they can be arranged e.g. on various monitors). I then have a routine for optional saving and restoring all onscreen forms, which works fine for "normal" forms with their editing grids etc on . In order to obtain or set the memo window positions programmatically, it seems I need to give the defined windows (used in the MODI MEMO CLAUSE) an Object name. e.g. MEMOWINDOW1. I assumed when the memo windows are moved, the top, left, Height, Width properties would be obtainable from the object via this namee.g s MEMOWINDOW1.TOP. But, strangely, although I can restore their positions by writing to these object properties (having just defined the windows if necessary), when I try to read them for saving, MEMOWINDOW1.TOP is not recognised ("alias MEMOWINDOW1 not found").

e,g,in CMDEDitMemo.button.Click
SELECT (aliasname)
mymemfield=this.tooltiptext && memo field name stored in tooltip text

IF TYPE(mymemfield)="M"
IF !WEXIST("MEMOWIN1") &&f rst creation of window for meo field
DEFINE WINDOW MEMOWIN1 AT 20,20 SIZE 30,30 NAME MEMOWINDOW1 IN screen TITLE mymemfield FONT 'Arial',7 CLOSE FLOAT GROW
MEMOWINDOW1.LEFT=THIS.LEFT &&position starting at command button
MEMOWINDOW1.TOP=THIS.TOP
MEMOWINDOW1.movable=.t.
Endif

MODIFY MEMO (mymemfield) NOWAIT WINDOW MEMOWIN1
ENDIF

then,in other parts of the app, memowindow1.left is not findable.

I realise DEFINE window is a bit old school, but find this MODI MEMO method convenient for setting up memo edits . The relation between the supposed object name, the "windoe name" etc is tricky. BASIC question- whats best way to save and restore the position of such windows. Or, Is the best option to create memo edit forms with just an edit box independent of the form with the mother grid on? (I prefer the ability to have memo windows to be outside the window which holds the rest of the grid and a load of other controls)

Thanks

 

[Mike Lewis]

then,in other parts of the app, memowindow1.left is not findable.

The key words there are "in other parts of the app". The point is that MEMOWIN1 is scoped to the method that creates it. When you get to the "other parts", it has gone out of scope.

The solution is to store the object reference in a custom property of the form. Then, whenever you refer to MEMOWIN1, place THISFORM. in front of it.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[willh2]

Dear Mike,
thanks for your answer. (Over the years your answers on this forum have been invaluable so thanks for all those also).

If I define the memo window beforehand (e.g. because saved positions are loaded in a PRG procedure), how do I find its full object reference? Even if created in The Command button method e.g. in FORM1.CMEEDITMEMO.CLICK , and the position of the window is later saved (along with postions of all other active forms) in a PRG procedure, is the full object reference FORM1.memowin1..., or maybe _screen.memowin1..? Or maybe I should use the HWND number as an object ref to find the current window positions? Clearly THISFORM isnt going to work off-form, and these forms also can have multiple instances, so even the form NAME isnt unique (I can use name and caption to distinguish though).

When I run through all FORMS in _SCREEN using a _SCREEN.FORMs loop, the .top and .left properties for the memo windows were wrong (not reflecting where I had moved the window to, but rather the starting postion).
Anyway, thanks again
William

 

[Mike Lewis]

William,

Given that you need to access the window from outside the context of the form, then clearly declaring a custom form property is not the way to go. Apologies for leading you down the wrong path.

The alternative would be to declare it as a private variable at the top of your main program. That way, it will stay in scope throughout the application, which should solve the problem. That said, I don't understand why the .Top and .Left properties reflect their starting values rather than the positions you are moving the form to. That will need further investigation.

By the way, welcome to the forum, and thanks for your kind words.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Mike Lewis]

Another suggestion:

Rather than using DEFINE WINDOW, you could create a new form specifically for editing the memo. It only needs to contain an EditBox. In the click of the button (or in the edit form's Init), you would copy the contents of the memo to the EditBox, and vice versa when you close the form.

Going further, you could instantiate the form at the start of the application (storing its object reference in a private variable), but keep it invisible until it is needed. When the user has finished editing, make it invisible again, rather than closing it. That way, you would never need to store its size and position.

Come to think of it, you could take the same approach with DEFINE WINDOW, that is, define it once at the start of the program, then call SHOW WINDOW or HIDE WINDOW as appropriate. Again, that would save you having to store the size and position each time.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[willh2]

Dear Mike,
thanks again, I'm sort of glad its not totally simple as Ive already pulled most of my hair out.
As suggested, I'm now abandoming modi memo windows and going down the path you suggest of a special editmemo form with an edit box on. I like the way the default double click memo box values change as you navigate down the main grid, so Im sending the editmemo form the alias and memo fieldname which it makes the recordsource for the editbox at form init. Then, I put a global message-to-refresh in the rowcolchange of the main grid form (by a global interform messaging system I have already set up). This all works OK so far.

I put the field name as the form caption, so I can open several editmemo forms, distinguishable by their caption/memo field name. I next aim to save the top,left etc of all the editmemo forms on command (having rearranged them all nicely) and an optional load from this file option...I'm hoping that these forms will behave better and when requested they can reposition themselves when requested.Then Ive got to close all the memo forms when the main grid is closed, so its a pity the modi memo approach didnt work out.

Thanks for the tips, I shall no doubt reappear if something in the above scheme proves unworkable,
best
William

 

[Mike Lewis]

Glad to hear you've found a solution, William. Be sure to come back if you need any further help.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads