LiveCode Forums

This may sound sacrilegious, but maybe HyperCard was wrong. The notion of inserting or remove the script of one object (the card) from the message path of an object based on whether that object is a member of a different object (the background) seems an unnecessary ambiguity, and a particularly odd...

Mark wrote:Jacque,

You don't see what the problem is. In HyperCard, once a message is sent to the background, it never goes back to the card before continuing to the stack.

Agreed. That isn't what you said in the part I quoted, which is why I commented.

There may be a crafty way to do what you want, but I think you'll be surprised at just how fast "repeat for each" really is. It can easily process tens of thousands of items in a few milliseconds. In fact, it's so fast that it is usually the preferred way -- it beats out a number of other methods in...

Hi Bernd, If you want to mimic the HyperCard behaviour, the button that's part of the group should return card background I don't believe background buttons in HC ever passed through the card. The messages went directly to the background, then to the stack. So the current behavior looks correct to ...

Well, it shouldn't crash like that, so that's a bug. But Android apps don't really quit, and you shouldn't even try. The Home hardware button will close your app and go back to the launcher screen. Android OS expects to control the app behavior, and manages all memory and the state on its own. It ca...

It looks like you are using a table field. This is a specially-formatted field that is always locked, and you can't type into it. When you click in a "cell" a second, temporary field is displayed over the entry so you can type there. When you tab out of the cell, or click elsewhere, the temporary fi...

Right, LiveCode is a typeless language. You can easily compare strings and integers, for example, because under the hood everything is converted to text. The engine decides what type is inferred by the usage, but as a developer you don't need to worry about it. There is a little trick you can use to...

That's a tough one in any language. I think basically you need to determine whether the user is touching an object or the card itself. If an object, then use your drag scripts. If the card, do a swipe. You can determine what is under the mouse/finger by checking "the target". If "card" is in the tar...

Basically, the work flow would be to "start using" your library stack(s) during development. That way you only need to keep a single library updated and all your development stacks will use the latest one dynamically. When it is time to build a standalone, use the Stacks pane in the Standalone Setti...

...and it's not just Windows OS X too -- like all the Command key shortcuts that manage window switching, Spaces, app switching, etc. It's impossible to intercept anything that OS X has decided "belongs" to it. And unfortunately they've usurped almost all the keyboard characters now, so there are v...

I don't think it can. If the OS doesn't tell LiveCode there's been a keypress, it can't know the key went down. LiveCode doesn't monitor the keyboard directly, it relies on the OS to notify it.

Are these unicode fonts? If so, the extra space may be the extra byte. You probably would need to treat the text as unicode text and adjust it for display.

Not a bug. Windows doesn't send rawKeyDown for several key presses, and Print Screen is one of them.

As to the 'lock cursor', it appears to work as I have it, so is that just coincidence? The order doesn't really matter as long as both commands are in the same handler. Locking the cursor just prevents the engine from changing the cursor at pre-determined events. You can always change it via script.

Good idea about the lesson, though it isn't really a lesson, it's more of an explanation. I'll put it on my list of things to do once the conference is over. It's getting pretty busy right now.