I have an MDI frame running. In the frame is a table-bound child, showing data from an existing table row. I edit some field of the child, and press F9. F9 is the accelerator for a frame menu item that runs the frame's WRITE handler. To be more precise it runs a quickevent calling the frame's commuter function. The WRITE handler sets the child's SAVEWARN to 0, writes the row to the table with a plain Write statement, does some indexing and stuff, and finishes. At this point SAVEWARN is still 0. The child has had its Clear Form After Write setting unticked, so the row data still show. Then I close everything with Alt+F4. But when the form's CLOSE handler runs, the child's SAVEWARN has become set again, so I get an unnecessary message about saving changes. Not nice.

If I do one single thing differently - tab to a different field before I save with F9 - it doesn't happen.

Is there a logical explanation?

- Oystein -

Oystein ..

Have you checked the SAVEWARN property after the Write Logic has been COMPLETELY processed (index updates, etc.)? It seems that it is possible that since the Child data elements are still there after the write that somehow the SAVEWARN is reset. Does tabbing to another field clear it? I think it probably would. I had a similar problem with a Non-MDI child some time back. I think that I found that the SAVEWARN was reset. My fix was to move focus to the next control or something like that.

Don

[notag]Yes!

Oh.. you want it? <g>

Well when you press F9 you invoke a MENU item and Menu items do not by default generate a lost focus on the field they leave as they are meant to be transparent. So perhaps you should send a LOSTFOCUS to the field with focus BEFORE doing the Write. Then the lostfocus will set SAVEWARN and the write will unset it! (Or you could set the menu to generate a lostfocus itself by clicking this property in the menu designer).

[<A HREF="http://www.sprezzatura.com" onMouseOver="window.status='Click here to visit our web site?';return(true)">The Sprezzatura Group</A>]

[<I>World Leaders in all things RevSoft</I>]

[<img src="http://www.sprezzatura.com/zz.gif">]

[<script language="javascript">function openNewPage () {window.location.href=(document.TOCNavigator.pageToGoTo.options[document.TOCNavigator.pageToGoTo.selectedIndex].value);document.TOCNavigator.pageToGoTo.selectedIndex="0";}end hiding from non-JS browsers –></script>] [<FORM ACTION "" METHOD=GET NAME="TOCNavigator" <SELECT NAME="pageToGoTo" SIZE=1 onChange="openNewPage()"> <OPTION>Pull down this menu to choose whereabouts on the Sprezz site to go <OPTION VALUE="http://www.sprezzatura.com">Home Page <OPTION VALUE="http://www.sprezzatura.com/whatsnew.htm">What's New <OPTION VALUE="http://www.sprezzatura.com/senl.htm">SENL <OPTION VALUE="http://www.sprezzatura.com/patches.htm">Download S/LIST <OPTION VALUE="mailto:support@sprezzatura.com">Send mail to support at Sprezzatura <OPTION VALUE="mailto:sales@sprezzatura.com">Send mail to sales at Sprezzatura </SELECT> </FORM>][/notag] </QUOTE> —- === At 08 NOV 2001 06:56AM Oystein Reigem wrote: === <QUOTE>Sprezzatura, Well when you press F9 you invoke a MENU item and Menu items do not by default generate a lost focus on the field they leave as they are meant to be transparent. I know. So perhaps you should send a LOSTFOCUS to the field with focus BEFORE doing the Write. Then the lostfocus will set SAVEWARN and the write will unset it! As I said before I write the row programmatically, with a Write statement. I kill SAVEWARN programmatically too. All this happens in the WRITE quickevent. Also as I said before - when the WRITE quickevent finishes (after having done indexing and all), SAVEWARN is still zero. After the WRITE quickevent finishes I assume the WRITE system handler runs. I've done nothing to prevent it from running. But I've always assumed the system handler would see that SAVEWARN was zero and not do anything. You see it's important that the WRITE system handler doesn't do a write by itself. Because if it did, it would only write some of the fields - the ones present in the child. My programmatic writing also includes other data - from fields in other child windows not currently open. But I have checked that my written data are correct, with no field values missing, so the WRITE system handler cannot have done any writing. Or??? But could it be that the WRITE system handler somehow sets SAVEWARN to 1???? I can't see why, but could it? Anyway - I did try to follow your advice of sending a LOSTFOCUS to the field with focus before doing the Write. From before I had some code that changed FOCUS to the next field before doing the Write, but now I tried with sending a LOSTFOCUS before that again. And then I tried with just sending a LOSTFOCUS and no change of FOCUS. Neither caused any improvement. (Or you could set the menu to generate a lostfocus itself by clicking this property in the menu designer). Tried that already. Didn't help. Please also see my reply to Don. - Oystein - </QUOTE> —- === At 08 NOV 2001 06:56AM Oystein Reigem wrote: === <QUOTE>Don, Have you checked the SAVEWARN property after the Write Logic has been COMPLETELY processed (index updates, etc.)? Completely as to checking with the Debugger to the very end of the quickevent, updating of indexes included. It seems that it is possible that since the Child data elements are still there after the write that somehow the SAVEWARN is reset. Does tabbing to another field clear it? I think it probably would. I do a programmatic tab before I write. Do you suggest I should do one afterwards too? Well, I tried, but it didn't help. When I say "programmatic tab" I mean I change the FOCUS property of the child to the next control in tab order. Or do you mean I should send a LOSTFOCUS? I've tried that too. It doesn't work. Actually, if my handler does a programmatic tab before writing, then writes, then sends a LOSTFOCUS to that next control that now has focus, something bizarre happens - the windows are closed. Could sending a LOSTFOCUS to a control in a child cause the frame to be closed? (In case it's of any relevance: It's the child that has got focus at this point, not the frame.) What does help is a manual tab before selecting write from the menu. Or to use the Write button I've got on the frame, instead of the menu accelerator F9. Seems like a crucial piece of the puzzle to me, but I can't figure it out. Must be something with the just edited control losing focus. I had a similar problem with a Non-MDI child some time back. I think that I found that the SAVEWARN was reset. My fix was to move focus to the next control or something like that. Some controls (edit table) seem to make SAVEWARN unreliable. That's why I have that programmatic tabbing (change of focus) before I write. But now I've tested everything in a place where all the relevant controls are plain edit lines, so it can't be the same problem. Please also see my reply to Sprezzatura. - Oystein - </QUOTE> —- === At 08 NOV 2001 09:28AM Don Miller - C3 Inc. wrote: === <QUOTE>Oystein .. Is puzzlement, indeed. I normally don't use MDI structures in my primary OI app. When I converted my nice stable AREV app, I just got too discombobulated over MDI's. But I do allow a user to open a number of related frames as part of the entry process. Here's what I do: 1. As each window is opened, it is possible that each one can change some portion of what I used to call @RECORD. All these windows are bound to the same table and @ID. 2. As each window is opened, an @USER property is set on the "main" form to contain an @FM delimited list of windows that the user has opened. This is global across all windows so I can check it anywhere. 3. In the "main" form, as the original record read from disk is saved in a user-defined varlable @OLD_RECORD (which may be NULL for a new entry). As each window is closed to return to the main screen, any changes made there are made in a pseudo-variable which corresponds to the "new" @RECORD variable. 4. The Write event is disabled in all forms except the main one. Then, at save time, the contents of the datafields in the main form are decomposed into the new @RECORD variable with suitable error checking along the way. This is needed because much of the database updating is done using "incremental" processing logic (back out the original and then add the new, etc.). Then a standard R/BASIC write is performed rather than the OI Write event. The way this is done is to issue a clear-form event with SAVEWARN set to FALSE using SEND_EVENT. Then the internal variables are cleared. The subroutine does a RETURN 0 to stop the event chain at this point. It's a bit of a kludge and probably takes more processing time than other things, but so far it's been reliable. Don </QUOTE> View this thread on the Works forum...