Your suggestion, if it didn't break many stacks, would certainly slow them down.
I mainly work with a Stack, a single card with anywhere between 10s to over a 100 fields, and a database. Going Next or Previous record populates those fields by using 'put' statements. Currently, even with 100+ fields it all happens in a blink of the eye. The user is then left to check the data, and if any are wrong those individual fields are changed, the closeField message is sent, which normally goes through some convoluted data verification process which includes not only checking the format of the data but also checking the MAX, MIN and UNIQUE entries in the database. Once all that is done the record is updated and everything is sweet. With what you are suggesting, every time I go Previous or Next the closeField message would be triggered 100+ times which is just a complete waste of time. The current logic of not triggering a closeField message has been with us since the birth of HyperCard. Frankly I wouldn't be surprised if you don't already have 1000s of situations across all your own stacks that already rely on this behaviour; the initial opening of your stack with all the fields prepopulated with data immediately comes to mind. From memory I handled your situation by setting a custom property in each field if data was pasted into it and then 'on exitField' testing to see if data had been pasted in: In the Edit Menu Script something like this: ... case "Copy" set the clipboardData["Text"] to the selectedText of the focusedObject break case "Paste" put clipboardData["text"] into the focusedObject set the cFldModByPaste of the focusedObject to true break ... and then in every fld script * something like this: on closeField --do what you need to here end closeField on exitField if (the cFldModByPaste of me = true) then --content change by paste so do closefield set the cFldModByPaste of me to false send closeField to me else --content hasn't been pasted in or changed end if end exitField * if groups of flds do exactly the same thing then you can save time by placing these scripts in a button and using behaviors. HTH On Sun, Sep 14, 2014 at 9:01 AM, Bob Sneidar <bobsnei...@iotecdigital.com> wrote: > I read from the Dictionary under closeField: "The closeField message is not > sent when a handler changes the field's contents using the put command.” > > May I submit that it ought to? An edited field is an edited field, and when > it loses focus, if the contents are not what they were when it was opened, > closeField *ought* to be sent! > > At any rate, I do not think there is a message I can send the the field to > let it know the contents have changed. I am probably going to have to recode > for textChanged. > > Bob S > > > On Sep 13, 2014, at 17:55 , Bob Sneidar <bobsnei...@iotecdigital.com> wrote: > >> Hi all. >> >> As many know, creating a custom menu set on OS X (not sure about Windows) >> will typically add the File and Edit menus to your customer menu set. This >> has the net effect of *disabling* cut/copy/paste/clear. I can live with >> that, because I have scripted the necessary menus to mimic the behaviors of >> those actions, but I am finding some quirks. >> >> First, if I cut or paste something in a field then tab out, closeField is >> not triggered. I assumed this was because the field was not getting >> selectionChanged, so I sent selectionChanged to the focusedObject after the >> cut/copy operations. Still, closeField does not get sent when I tab out of >> it. closeField DOES get sent if I simply edit the field then tab out. >> >> So what gets sent to the engine exactly that lets it know that the contents >> of a field have changed, so that tabbing out generates the proper closeField >> message? >> >> I suppose I could use textChanged to work around it, but frankly I would >> have to go through all my scripts which send a closeField to this object, >> and I’d rather not mess with what is already working. >> >> Bob S > > > _______________________________________________ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode