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
