I have some MDI stuff that's starting to cause me grief. The whole thing seems to be built on sand. I would be very grateful if somebody could help me get it back on solid ground.

I've prepared a very simplified version of the windows and programming involved.

In this simplified version I have two windows - one MDI frame and one child. The child is bound to a table.

Both windows have quickevents calling commuter functions. Except the child hasn't got any events yet.

The child window and its table are very simple - one INTEGER SEQKEY and three VARCHAR edit lines.

The child has no menu. I've deleted all the default menus. All relevant menus are on the frame.

The MDI frame starts up empty. The frame has a Start button that starts the child.

I do the following procedure:

- I start the child with the frame's Start button

- I fill in the fields of the child

- I do a save from the frame's menu (with the mouse or a F9 shortcut)

- I click on the child's system close button (X) to close the child.

But the child thinks there are unsaved changes. That's the problem I want to address in this posting.

The problem occurs because of the way I do the save. I have (I think) a very good reason for not letting the child do the save. Instead I have my own OMNIEVENT WRITE on the frame that does the saving. My OMNIEVENT WRITE goes about its task the following way:

- First it extracts all the field values from the child window

- Then it puts together a record from the values

- Then it saves the record with a simple Write statement

- Finally it sets the SAVEWARN property of the child to false$.

But when I close the child, SAVEWARN has somehow been set to true$ again, resulting in the SAVEWARN message prompting the user to save unsaved changes, even if no changes have been done.

So I can't distinguish between this case and the case where the user really did change something after he saved.

Can somebody explain this behaviour? Is it a bug?

I have discovered some circumstances under which the problem does not occur:

- It does not happen if I - before saving - move to another field from the last field I filled in

- It does not happen if I save twice before closing.

(I can't of course tell my clients they have to take either of these actions. I mention them because I hope they can throw some light on the matter.)

Neither does it happen if (1) I use a button on the frame to do the saving, instead of the menu, and (2) let my OMNIEVENT WRITE handler set focus back to the child, to any of the child's fields. (It does the latter before setting SAVEWARN.) One of these changes alone doesn't help.

I had some reason to believe that another programmatic change would help: to let the OMNIEVENT WRITE handler sent a LOSTFOCUS to the child - to the control with focus in the child. So I tried to let the handler do that before doing anything else. But it didn't help.

Now can anybody shed some light on this matter for me?

- Oystein -

Oystein,

You may not have realized it, but you DID figure out the problem. Basically, when you attempt to close the window, it compares the GOTFOCUS_VALUE property with the TEXT property of the control with focus. If they are different then the SAVEWARN property will be set. Therefore it won't matter how many times you reset the SAVEWARN property because OI will still see that the GOTFOCUS_VALUE and TEXT properties don't match.

As you discovered, saving twice or moving into another field (but not making any changes) allows this to work. In similar situations, we have a generic routine that locates the Key ID field in the form and sets the focus there first. Then we can reset the SAVEWARN flag and successfully close the window.

dbakke@srpcs.com

SRP Computer Solutions, Inc.

Don,

I must have known this. But forgot.

What you suggest is to programmatically set focus to a different control before killing SAVEWARN. But I really do think I've tried that. I know I did in my bloated earlier code, but I'm also quite certain I thoroughly tried it today in my experiments with the simplified system. Except I don't set focus to the key but some ordinary field. In the real situation the key is hidden from the user.

I know I got the change-focus-trick to work today when I saved from a button on the frame. (That button sends a MENU message to the Save menu item.) But I didn't get it to work when I saved from the menu - neither when I clicked the menu item nor when I used the menu item shortcut keystroke.

All right - I'll have to do something else first, but will return to the problem as soon as possible.

Thanks so far!

- Oystein -

Don,

You suggested my OMNIEVENT WRITE handler should change focus programmatically to some other control in the child before killing SAVEWARN. I got your suggestion to work.

But please tell me

(1) why it only works when I set focus to the key field, not the other fields. (The other fields are plain edit fields with no fancy stuff.) STOP PRESS! It also works if I set focus to an unbound edit line in the child. Or a button.

(2) why it only works when I set focus the (Ctrl,"FOCUS",true$) way and not the ("SYSTEM","FOCUS",Ctrl) way.

- Oystein -

Oystein,

I don't have an answer to those questions as I think it should work in both situations. The only time moving the focus to another control doesn't work is if the control is a multline editbox. I'd have to duplicate what you are doing to get a better idea.

dbakke@srpcs.com

SRP Computer Solutions, Inc.

Don,

If you're interested I can send you my test setup. It's not much - two simple windows, a trivial table, a modest piece of programming.

But only if you're really interested. I believe with the help you've given I've learned enough to get my app back on safe footing.

Thank you very, very much!

- Oystein -

Oystein,

Sure, bring it on!

dbakke@srpcs.com

SRP Computer Solutions, Inc.

Yeah, it does that because one peice of the information has been set by TEXT and the other by TEXTVAL, so the CRFL and @VM or @TM don't equal.

I had a promoted event to handle that, somewhere…

The Sprezzatura Group

World Leaders in all Things RevSoft

You published it in an S/ENL if memory serves…

dbakke@srpcs.com

SRP Computer Solutions, Inc.

Don,

You say it works to set focus programmatically to any field. I found it only works with the key field. The truth is I can get it to work with any field as long as that field wasn't changed. I.e, if the record in the child is a new one it works if the field I set focus to wasn't filled in. If the record is an existing one it works if the field I set focus to wasn't changed since it was read/saved.

So I can't agree it's GOTFOCUS_VALUE that TEXT is compared with, but with the original value.

Or perhaps my programmatic focus-setting doesn't update GOTFOCUS_VALUE?

Do I make sense?

- Oystein -

Don,

Or perhaps my programmatic focus-setting doesn't update GOTFOCUS_VALUE?

This is it!

To set focus I do

UnUsed=Set_Property( Child_Id : ".FIELD1", "FOCUS", true$ )

but I also have to follow up with a

UnUsed=Send_Event( Child_Id : ".FIELD1", "GOTFOCUS" )

to get GOTFOCUS_VALUE updated! Might be obvious to you.

Now my programmatic focus-setting should work for any control. Except edit boxes.

- Oystein -

Oystein,

That's about what I was going to suggest. Remember, one method prevents the GOTFOCUS event from firing while the other causes it to fire.

I haven't loaded your RDK yet. Did you still need me to look at it?

dbakke@srpcs.com

SRP Computer Solutions, Inc.

Don,

That's about what I was going to suggest. Remember, one method prevents the GOTFOCUS event from firing while the other causes it to fire.

I remember now that you tell me.

But I did try the other one. I tried both ways of setting focus. I could only get the event-suppressing one to work.

But never mind. The important thing is I found a way that works.

I haven't loaded your RDK yet. Did you still need me to look at it?

No. Just put it out of its misery.

Thank you very much for all your help!

- Oystein -

Yes, which appears to be lost during the conversion. Believe it was the Gnu who found that one…wonder where he's been?

The Sprezzatura Group

World Leaders in all Things RevSoft

Srezzatura,

Yes, which appears to be lost during the conversion.

"Lost" like in "never coming back"?

- Oystein -

Oystein ..

As I have always said:

"If you're don't know where you're going, any road will get you there"

Don

Now was that George Harrison or the Cheshire Cat or Yogi Berra or Luke Rhinehart?

- Oystein -

View this thread on the forum...