How to know if an object has been edited/modified?

[FourthWorld]

I couldn't believe there wasn't a simple, non-convoluted way to determine when an object has been modified.
It appears there isn't.

If you find a lot of languages with a single message sent for all possible changes it may help to include the relevant APIs when you submit you feature request so the team has something to model the request on.

In my own limited experience, what may seem "convoluted" to some merely seems like "complete control" to me: we have separate messages for specific actions (e.g. "mouseUp") or categories of actions ("textChanged"), giving me enough control to determine exactly what I want to do for a given app.

With one single message, consider that clicking a button changes the mouse stack twice, once to highlighted and again to non-hightlighted. Should the stack save twice each time a mouse is clicked? Or consider text entry: with every key stroke the contents of a field changes; should the stack be saved on every keystroke?

While I can appreciate the attraction of a single message, I suspect that in practice it may prove quite troublesome, prompting most of us to just go back to the more granular control we have today with invidivual messages.

That said, I realize my view is only based on the work I've done, and there may be other circumstances where a single message may be optimal, even if my own experience is to limited to allow me to think of one myself.

You've noted that the auto-save scenario may not be a good example, so may I ask what sort of scenario did you have in mind when you first propose this new feature? In addition to helping refine the enhancement request when you submit it, once we know the specific task you're looking to achieve we may be able to help you come up with acceptable solutiions using what's the language offers today.

[sritcp]

In my own limited experience, what may seem "convoluted" to some merely seems like "complete control" to me: we have separate messages for specific actions (e.g. "mouseUp") or categories of actions ("textChanged"), giving me enough control to determine exactly what I want to do for a given app.

It doesn't have to be either/or. I meant a generic message in addition to "separate message for specific actions". It will only add to the flexibility.

With one single message, consider that clicking a button changes the mouse stack twice, once to highlighted and again to non-hightlighted. Should the stack save twice each time a mouse is clicked? Or consider text entry: with every key stroke the contents of a field changes; should the stack be saved on every keystroke?

The stack doesn't HAVE to be saved each time there's a click. It gives us the option NOT to save if there has been no action.

May be I am complicating things unnecessarily here. In any program (word processing, LiveCode, ..), for example, if you open to view a file, don't do anything, and quit it, it doesn't ask you to save. If you have made ANY change to it, however minor, it asks you if you want to save it. So, there is already a mechanism. I was just wondering if there is a LiveCode message that lets us take advantage of it.

The actual scenario was this: I successfully made and tested a program for use in my work. Card 1 has a DataGrid "All Data"; Card 2 has a DataGrid "Current Data", which has a subset of records from "All Data". Each of card 3, 4,... has a DataGrid "Basic Data", "Advanced Data", etc., each of which has a subset of records from "Current Data". Since data can be edited on any card (especially card 3 and above), it is necessary, on closeCard, to update both Current Data and All Data. A lot of the use of this program would be to flip between cards to view information, and edit only occasionally. Thus, I wanted to update "All Data" only if some data had been edited on the card (in the DataGrid as well as other objects). The fact that in my particular program it would only have taken a second to update All Data even when unnecessary was beside the point (to me). It grated me to leave it alone.

Regards,
Sri.

[jacque]

In this case you're in luck. There is a message sent only when field content changes, and that's the closeField message. Just trap that and set a flag, and if the flag is true on closeCard, save the stack.

[richmond62]

But:

"The closeField message is not sent when a handler changes the field's contents using the put command."

Not sure how you are changing your data.

Why does it seem impossible to copy-paste from the online Dictionary?

[jacque]

But:

"The closeField message is not sent when a handler changes the field's contents using the put command."

Not sure how you are changing your data.

True, but the OP was talking about people editing the fields manually.

Why does it seem impossible to copy-paste from the online Dictionary?

It works here on Mac.

[FourthWorld]

The textChanged message would also be useful, as would trapping setprop for when the dgText changes. Lots of ways to save in response to the specific range of relevant messages, without being triggered by things like keyDown.

But the bigger question emerges here: why save the stack file at all? If the interest is in saving changes to specific data, why not take the more common road of simply saving the data externally from the UI?

[[-hh]]

..........

[dunbarx]

Hermann.

Your points are well taken, as usual.

I think that a generic message sent with any change at all, for example, it would be sent twice in your example of typing an "A" and then deleting it, is what the OP meant and wanted. In terms of knowing when a save is appropriate, well, that is complicated, as you pointed out.

I think the generic message, in and of itself, would be useful. Did you see my earlier feature request? Richard answered that with a revelation to me.

Craig

[[-hh]]

..........

[Simon]

--hh
Phew, I thought the book disappointed you because I didn't hear your review.

Simon

[sritcp]

...your question is not precise enough

I do agree. Ideally, if the resultant file is unchanged, it is unmodified. This would mean that, if you typed A and deleted it, there would be no modification.
But, for practical purposes, I wouldn't mind if the program treated doing-undoing as a modification.
My larger point was the desirability of a generic message for such situations.

....why save the stack file at all?

I leave LiveCode (and a bunch of other applications) open all the time on my computer. Whenever I have a break in my work (I am not a professional programmer), I get back to LiveCode and carry the ball another yard or so. Sometimes, it is for an hour, at other times, it is only for five minutes. I don't want to lose my work, and I don't want it to save the stack file every five minutes, willy nilly.

As an amateur, I know I am a little out of my league here. But I can't help but think that a generic message would be useful in all kinds of ways. Craig seems to agree, so may be I am not completely off here

Here's a product idea I've been considering (but yet to work on):

It is an iPad app for children with hearing loss (0-5 years of age), who have been fitted with a cochlear implant (or hearing aids). It helps train the child's listening skills, by providing appropriate stimulation. Thus, it would help to extend therapy the child is receiving (which is expensive). The key here is self-dosing. The child plays with it as long as it interests her. The program stores data on the nature and duration of interaction (for assessment of efficacy as well as for progressing to the next module, etc). Often the program would be on and running (mom would have turned it on and gone away), but the child may or may not be paying attention. The key here is meaningful interaction -- one measure could be "was any object modified in some way?"

That's just one. I'm sure there are many other uses.

Regards,
Sri.

[sritcp]

I think the OP had, on a different level, as he wrote, basically a similar idea like you.
But his topic has soon turned into "advanced", far from a beginner's thread.

Hermann,
The problem is the boards are named "Complete Beginners" and "Experienced Developers",
not "Basic Topics" and "Advanced Topics"!

Regards,
Sri.

[FourthWorld]

....why save the stack file at all?

I leave LiveCode (and a bunch of other applications) open all the time on my computer. Whenever I have a break in my work (I am not a professional programmer), I get back to LiveCode and carry the ball another yard or so. Sometimes, it is for an hour, at other times, it is only for five minutes. I don't want to lose my work, and I don't want it to save the stack file every five minutes, willy nilly.

Having established that we don't really want to save on every user event (key strokes, button clicks, etc.) and instead want to save only only in response to a specific subset of events, one more way to do what you're asking for here is to use the suspend message, so you can save whenever the program is put into the background.

Of course it's possible that you might switch into the program and then back out of it without making changes, which could mean a redundant save. But given that it ensures your stack is saved on suspend and the load on the system for saving is pretty minimal, what downside would there be to having the auto-save you're looking for accomplishable right now?

[dunbarx]

Richard.

I think the idea of a message sent with any change at all is the best. Again, sort of a "setprop" for native properties. I would rather deal with "subset" events myself, derived from and built around that most basic and ubiquitous message. You can always make a larger gadget from a small building block. It is difficult to do it the other way around.

And why not a "getProp" as well? I cannot think of a use for this right now, but that does not mean a thing.

Craig

[FourthWorld]

I think the idea of a message sent with any change at all is the best.

I saving every five minutes represents an unacceptable load on the system, how would saving in every keystroke improve things?