Code: Select all
on keyDown
if shiftKey() is down then
set the backGroundColor of this stack to red
else
set the backGroundColor of this stack to green
end if
end keyDown
Code: Select all
on enterkey
set the backGroundColor of this stack to red
end enterkey
on returnkey
set the backGroundColor of this stack to green
end returnkeyCode: Select all
on enterkey
set the backGroundColor of this stack to red
end enterkey
on returnkey
set the backGroundColor of this stack to green
end returnkey
on rawKeyDown theKey
if theKey is 65505 or theKey is 65506 then -- left or right shift
set the backGroundColor of this stack to yellow
end if
if theKey is 65513 or theKey is 65514 then -- left or right alt
set the backGroundColor of this stack to orange
end if
if theKey is among the items of "65470,65471,65472,65473,65474,65475,65476,65477,65478,65479,65480,65481" then
set the backGroundColor of this stack to purple
-- tFunctionKey theKey -- or you could customise this further
end if
pass rawKeyDown
end rawKeyDown
command tFunctionKey theKey
put theKey
-- 65470 -- F1 key
-- 65471 -- F2 key
-- 65472 -- F3 key
-- 65473 -- F4 key
-- 65474 -- F5 key
-- 65475 -- F6 key
-- 65476 -- F7 key
-- 65477 -- F8 key
-- 65478 -- F9 key
-- 65479 -- F10 key
-- 65480 -- F11 key
-- 65481 -- F12 key
end tFunctionKeyCode: Select all
on keyDown
if shiftKey() is down then
--do something
else
--do something else
end if
end keyDownCode: Select all
on rawKeyDown theKey
if theKey is 65505 or theKey is 65506 then -- left or right shift
set the backGroundColor of this stack to yellow
put "Shift is down" into cd fld "text"
else
-- do something else
put "Shift is not down" into cd fld "text"
end if
pass rawKeyDown
end rawKeyDown
Code: Select all
on rawKeyDown theKey
put theKey
pass rawKeyDown
end rawKeyDown
Slightly less old-hat (MacOS 10.15) - Works there too (enter, return, function keys)
Only one, a Lenovo keyboard I have at work. I think it came off a gaming PC - but yeah, that says 'shift-lock' instead of 'Caps Lock'. There's also one that says 'Hard-lock' too, which does the same thing. Think that was an HP one.richmond62 wrote: ↑Wed Jun 19, 2024 7:31 pm Mind you: do you know any recent systems or machines that have a SHIFT LOCK?
Code: Select all
function isReturnKeyDown
if "65293" is among the items of the keysDown then
return true
else
return false
end if
end isReturnKeyDown
function isEnterKeyDown
if "65421" is among the items of the keysDown then
return true
else
return false
end if
end isEnterKeyDown
That thread exhibits a common pattern of that community: someone has a question, the question needs clarification to understand more precisely the intended use, one person asked for that clarification, everyone else just guesses and spawns pages of subthreads with adventurous speculation, and the OP hasn't returned to clarify the use case.richmond62 wrote: ↑Wed Jun 19, 2024 1:15 pm Would it be possible to implement enterKey() and returnKey() in OXT?
https://forums.livecode.com/viewtopic.php?f=7&t=39161
That would put LiveCode at a pip.
Having worked with keyDown/rawKeyDown plenty, trying for realtime input responsiveness (as mentioned like the way one would for using keyboard as game controller). I've had similar thoughts in regards to syntax inconsistency (another example: 'keysDown' message param will contain a character, but the keysDown contains rawKey code numbers and not characters). There's definitely been times I've thought it would be good to have the ability check using something like optionKeyDown() or returnKeyDown(). Like recently when I was building that On-Screen-Keyboard widget which is setup in a way to respond to both 'keyChar /keyNames and rawKey numbers that match the engines/XLib's numbers, which includes a default script that matches message (characters or names for non-printable char) OR rawKeyNumbers. But again it isn't like it's a lot of work to roll your own function for that (use 'the keysDown'), so I'd just do something like that and move on, never mentioning it in any forum anywhere.FourthWorld wrote: ↑Thu Jun 20, 2024 4:17 pm I recently spoke with a qualified developer about the possibility of addressing the need for recompilation for Apple's m-series processors. He passed, but AFAIK the need remains, yes?
For future discussions like that, which thread here offers the clearest description of the problem and remaining challenges?
I agree with Paul's assessment that, given Apple's history with architectural change, at this point we likely have somewhere between 18 and 36 months before any Intel-dependent engine will no longer run on the one OS where xTalks have ever had a foothold.
So we have time, and the sooner that challenge is addressed the more confidence folks can have in investing in building GPL software on this platform.
Users browsing this forum: No registered users and 7 guests