I have a CHANGED event on a table (non-bound), which triggers a property indicating that the information has changed.

If the user closes the form I check and ask if they want to save.

This works fine, except for the CHANGED event on a table.

If you press return or tab it is fine, but if you modify a cell and then click close in the title bar, it does not recognise that a change is made and does not trigger the change event.

If I use the CHAR event instead it is fine and works perfectly, but I dont like using the CHAR event as this is triggered too often and makes the system a little jittery.

Any other suggestions?

Colin,

The best advice is to wait until Don Bakke wakes up. He's the expert on this stuff.

In the meantime: Your CLOSE handler must help the edit table a bit. I think it should send a LOSTFOCUS to the edit table.

But your CLOSE handler must run early. So it must be a user event or a promoted event and not a quickevent. If you don't like to have your programming in user events but in a commuter function called from quickevents you can still have most of your programming in the commuter. Just let the user event call the commuter function.

I have similar cases to yours. I do tricks like sending LOSTFOCUS to the current control or setting the focus to a different control. But I also have some problems with bogus SAVEWARN messages. I've got rid of most of them but some remain. I don't know if you'll get that problem. But if you do I think you can work around that too.

Now sit tight and wait for Don.

- Oystein -

In the meantime: Your CLOSE handler must help the edit table a bit. I think it should send a LOSTFOCUS to the edit table.

Yup - the close button gets treated like a menu item (which is why they have that handy "Trigger LOSTFOCUS" option for cases like this)

But your CLOSE handler must run early. So it must be a user event or a promoted event and not a quickevent.

Not necessarily. You can prevent a window closing in a quickevent procedure by calling set_EventStatus( TRUE$ ) .. so send the LOSTFOCUS, check SAVEWARN or whatever and then set_EventStatus() if you need to.

The Sprezzatura Group

World leaders in all things RevSoft

ZZ,

Well - one out of two isn't so bad, is it?

- Oy -

Tried calling LOSTFOCUS event, and setting focus on the table to zero, and setting focus on another control to 1…. all failed.

Seems as though actually losing focus on a table when you change a cell triggers the CHANGED event, but calling LOSTFOCUS on the table when a cell is changed does not call the CHANGED event.

How can the CHANGED event be triggered.

NB: I dont want to call the CHANGED event on LOSTFOCUS as the data may actually not have changed.

Whats this 'Trigger Lostfocus' option.

Are you pulling legs or is this a real thing somewhere that I cant find.

Colin,

Did you really try

RetVal=Send_Event( EditTableCtrlName, "LOSTFOCUS" )

?

That Trigger thing - I think they mean the "Generate LostFocus Event" setting for menu items.

- Oystein -

You could also try a POSCHANGED event, or just move the SELPOS…

The Sprezzatura Group

World leaders in all things RevSoft

Rechecked LOSTFOCUS and did not work.

Tried POSCHANGED and did not work.

Tried changing SELPOS and did not work.

Checked all these by adding debug and monitoring, and all are actioned, but none actually cause the CHANGED event to process.

Any more suggestions?

Colin,

I really believed I successfully do something similar to what you do.

But my window is an MDI frame with a child. I don't know if that makes a difference. (Usually MDI makes stuff harder. Would be nice if it made some stuff easier too…)

- Oystein -

Colin,

If I were you I think I would work around the problem the following way (after having spent a day or two to get it to work the "proper" way of course):

- Have some place where you can keep a copy of the edit table's previous content, e.g a user-defined property "@PREVIOUS_ARRAY" of the edit table or the window

- Have some code to update "@PREVIOUS_ARRAY" each time the content has been changed. That will probably be in the window's CREATE handler and the edit table's CHANGED handler. Set "@PREVIOUS_ARRAY" to the current content of the edit table ("ARRAY" property). (Remember to think things through if there are other ways of changing the edit table's content than through user input)

- In the window's CLOSE handler check the current content of the edit table ("ARRAY" property) against the content of "@PREVIOUS_ARRAY"

- Oystein -

Colin,

Might be easier to store original values of your edit table during the "read", and "clear" events, and then check for changes during the "close" event.

Kinda like this…

Within clear event…

RESULT=SET_PROPERTY(EDITTABLE_FOCUS,'@ORIGINAL','')

Within read event…

ARRAY=GET_PROPERTY(EDITTABLE_FOCUS,'ARRAY')

RESULT=SET_PROPERTY(EDITTABLE_FOCUS,'@ORIGINAL',ARRAY)

Within close event…

ORIGINAL=GET_PROPERTY(EDITTABLE_FOCUS,'@ORIGINAL')

CURRENT=GET_PROPERTY(EDITTABLE_FOCUS,'ARRAY')

IF ORIGINAL NE CURRENT THEN

RETURN 0

END

Sure, this is a possibility, and in fact a method I use now.

Problem is, using OI16, we can never be sure how much data a user enters in a table and I dont want to break the 64k limit on tests using ARRAY.

View this thread on the forum...