Unlocked field receives the mouseUp message
Thanks Peter. Actually i do want to just toggle the locktext of the field. I use the field to proofread the text by reading from the clickchunk to the end using revspeak. If I encounter an error while speaking, I want to be able to easily click the field again to allow for edit. The control click does allow a mouseUp to get through and the locktext to be changed to allow for edit. In retrospect, I should have understood the rationale for this behavior. While editing text in an unlocked field it should be possible to copy and past into the field so that it has to respond to command, control keys etc. So, it doesn't respond to a naked mouseUp, but it will respond to a combination of command, control etc. mouseUP. It saves my bacon. Jim > I have the following in a frontscript, so it works on any field: > > on mouseup theBtn >if theBtn <> 1 then pass mouseup >if the target begins with "field" then > if the commandkey is down and the shiftkey is down then > set the writable of the target to not the writable of the target > end if >else > pass mouseup >end if > end mouseup > > setprop writable tf > if not (the target begins with "field") then exit writable > try > set the locktext of the target to not tf > set the traversalon of the target to tf > set the autohilite of the target to tf > end try > end writable > > getprop writable > if "field" is not in the target then return empty > try > put the locktext of the target into L > put the traversalon of the target into T > put the autohilite of the target into A > if T and A and not L then return true > return false > end try > end writable > > Holding the commandkey down during a mouseclick will trigger a mouseup > message (like the controlkey), and this means that cmd-sh-click will trigger > the mouseup handler. I use the virtual property "writable" to set the > locktext, autohilite, and traversalon of the field. Note that no enduring > property of the target field is ever actually set, since the calls are > intercepted to perform an action on the field instead. This is what is meant > by a "virtual" property. If you only want to toggle the locktext of the field > you can instead forget the virtual prop calls and just do "set the locktext > of the target to not the locktext of the target" in the mouseup handler. > > -- Peter > > Peter M. Brigham > > pmbrig at gmail.com > http://home.comcast.net/~pmbrig ___ 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
Re: Unlocked field receives the mouseUp message
I have the following in a frontscript, so it works on any field: on mouseup theBtn if theBtn <> 1 then pass mouseup if the target begins with "field" then if the commandkey is down and the shiftkey is down then set the writable of the target to not the writable of the target end if else pass mouseup end if end mouseup setprop writable tf if not (the target begins with "field") then exit writable try set the locktext of the target to not tf set the traversalon of the target to tf set the autohilite of the target to tf end try end writable getprop writable if "field" is not in the target then return empty try put the locktext of the target into L put the traversalon of the target into T put the autohilite of the target into A if T and A and not L then return true return false end try end writable Holding the commandkey down during a mouseclick will trigger a mouseup message (like the controlkey), and this means that cmd-sh-click will trigger the mouseup handler. I use the virtual property "writable" to set the locktext, autohilite, and traversalon of the field. Note that no enduring property of the target field is ever actually set, since the calls are intercepted to perform an action on the field instead. This is what is meant by a "virtual" property. If you only want to toggle the locktext of the field you can instead forget the virtual prop calls and just do "set the locktext of the target to not the locktext of the target" in the mouseup handler. -- Peter Peter M. Brigham pmb...@gmail.com http://home.comcast.net/~pmbrig On Nov 28, 2011, at 12:07 PM, Jim Hurley wrote: > I have been trying to find a way for the user to change a text field from > unlocked to locked and back without leaving the field, just using mouse > clicks. > > I have found (stumbled on) a way that appears altogether illegitimate. > > If the field is unlocked I can type into the field as expected. If I click in > the field nothing happens, again as expected. > > BUT if I right click (control click) in the unlocked field the field receives > both a mouseDown and a mouseUP message and I now have a way to change the > field from unlocked to locked even when the field is unlocked and supposedly > receiving key strokes but not mouse clicks. (See script below.) > > Is there some orthodoxy by which I can under stand this? > > Jim Hurley > > on mouseUP tNum > put the locktext of field id 1003 &cr after msg box > if tNum = 3 then set the locktext of field id 1003 to not the locktext of > field id 1003 -- returns false & cr & true > put the locktext of field id 1003 &cr after msg box > end mouseUP > > If tNum = 3 and the field is unlocked, the message box shows: > > false > true > ___ > 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
Unlocked field receives the mouseUp message
I'll have to wait for the summary list to respond to answers to that last message, as I still cannot access the RR archives. Heather? Jim Hurley ___ 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
Unlocked field receives the mouseUp message
I have been trying to find a way for the user to change a text field from unlocked to locked and back without leaving the field, just using mouse clicks. I have found (stumbled on) a way that appears altogether illegitimate. If the field is unlocked I can type into the field as expected. If I click in the field nothing happens, again as expected. BUT if I right click (control click) in the unlocked field the field receives both a mouseDown and a mouseUP message and I now have a way to change the field from unlocked to locked even when the field is unlocked and supposedly receiving key strokes but not mouse clicks. (See script below.) Is there some orthodoxy by which I can under stand this? Jim Hurley on mouseUP tNum put the locktext of field id 1003 &cr after msg box if tNum = 3 then set the locktext of field id 1003 to not the locktext of field id 1003 -- returns false & cr & true put the locktext of field id 1003 &cr after msg box end mouseUP If tNum = 3 and the field is unlocked, the message box shows: false true ___ 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
