Change button label by pressing the command key

[Fjord]

Hi,
I'm wondering how / if I can change a button label just by holding, say, the command key. I have a button script along these lines:

on mouseUp
   if the eventCommandKey is up then
     do something on the current card
  else do the same thing on all cards
end mouseUp

It would be much neater to have the button label change from 'do something' to 'do something to all' whenever the command key is pressed. But I can't find a way, other than using a 'on idle' handler (which is not recommended) or some kind of timer with 'send'.
Can one trap the pressing of the command key alone?

[dunbarx]

Hi.

There is no actual "commandKey" message, though there is such a function. But that means that no message is sent if only the commandKey is pressed. It requires at least one other key. Other similar keys are the optionKey and controlKey.

You can kludge this if you really want to, by:

Code: Select all

on idle
   if the commandKey is down then set the label of btn 1 to random(999)
end idle

But that is really not a good solution at all, since a lot of resources and activity is squandered.

Craig

[dunbarx]

Really the best way forward, if you must have a single unadorned keypress do something is to use another key, like the tabKey. In the card script with a button somewhere:

Code: Select all

on rawKeyDown tKey
   if tKey = 65289 then set the label of btn 1 to random(999)
end rawKeyDown

Craig

[dunbarx]

I just learned that everything I said in my first post only applies to Macs. Apparently, the "commandKeyDown" message is sent on Unix and Windows machines regardless of whether another key is paired with it.

Why this very basic LC action should be machine dependent is bothersome to me.

Craig

[FourthWorld]

The design attempts to make it universal.

The challenge is that commandKey was already a HyperTalk function when MetaCard (later rebranded "LiveCode") was born in Unix.

So the solution was to use the established HyperTalk convention, automatically mapping it to the functional equivalent on PC keyboards, the Control key.

[dunbarx]

Richard.

Not sure what sort of effort it would take to make the "commandKeyDown" message fire without another keyPress. But I think it unfortunate that such a condition is required.

Craig

[FourthWorld]

Richard.

Not sure what sort of effort it would take to make the "commandKeyDown" message fire without another keyPress. But I think it unfortunate that such a condition is required.

Ah, that. Yes, modifier keys play a special role. Aside from unusual cases (usually in games) they're designed to be used in conjunction with other keys. It's been a long time since I read the Event Manager volume of Inside Macintosh, but IIRC the OS didn't even have a normal event flag for modifier keys used by themselves, requiring custom low-level hooks.

[dunbarx]

Pity, then.

Not that such a feature would ever be essential, it is just that I have come to expect (dream?) that LC was such a rich and varied toolbox that I should be able to do whatever I want with whatever I want.

Craig

[FourthWorld]

The world is a place of limitations; the joy of the game is finding and overcoming obstacles. How much fun is a game that offers no opposition?

xTalks make doing common things uncommonly easy.

Uncommon things are accommodated, but just outside the sandbox. In the HC we wrote externals; today we have those plus a scripting option with LCB.

It's all still possible, and now even through scripting. But the less common something is, the less easy the finite engine will be able to make it happen for us.

That said, given infinite budget I'll bet the team could craft infinite features.

[Fjord]

Wow! Thanks to all! At least I’ll stop searching the doc for a message.
Still, it is somehow sad that pressing a modifier key can’t be reflected visually by modifying the interface.

[richmond62]

it is somehow sad that pressing a modifier key can’t be reflected visually by modifying the interface

You'll have to ask Steve Wozniak or the ghost of Steve Jobs for the reasons behind that decision.

It does seem churlish, given MicroSoft; and presumably the reason why the Linux family go the same way as
MicroSoft is to help users transferring from Windows to Linux.

[richmond62]

But that is really not a good solution at all, since a lot of resources and activity is squandered.

Most computers are not going to throw a bluey over that one.
-

-

Code: Select all

on openCard
   set the idleRate to 500
end openCard

on idle
   if the commandKey is down then
      set the label of btn "XYZ" to "CmdKey Down"
   else
      set the label of btn "XYZ" to "CmdKey Up"
   end if
end idle

[dunbarx]

@Richmond.

You are using "idle", as I had posted earlier, but did not also include the caveats that really ought to go with it.

@Fjord. But do you see how this can work? Since there is no "command" message, and therefore no handler to trap it, one must use a function. But a function must be called from within a handler, and that requires a different message. The only message that the system continually sends, apart from any of the mouse or key related messages, is "idle".

You must be prepared beforehand if you use "idle"

Craig

[richmond62]

the caveats that really ought to go with it

As I am unaware of what those are . . .

Except, possibly, that if I want to perform a 'normal' Command + Key on a Mac system it might get blocked.

[dunbarx]

Richmond.

In the beginning, when I was a lad using HC, I used "idle" here and there for just the reasons you did; a continuous flow of messages coming out of the blue, the system interrogating the planet, available to be trapped.

It was Jacque, early on, who made me aware of the overhead costs of trapping all those messages, whether I used them or not. In other words, there is a big difference between the system sending those messages, and a living handler that traps them, again whether the functionality within that handler is ever exploited.

It is just expensive, and with certain tasks, might be cost prohibitive.

Craig