LiveCode Forums.

Hello,

I made a very small stack with an editable Table Field (not a Datagrid):
- basicTableObject is checked
- cellEdit is checked
- maxColumnCount set to 2

All is working as expected in the IDE but this field is locked when I save the stack as Standalone (with LC Indy 9.04). Cells can be filled by script but I cann't manually edit cells.

Thank you for your help.

Hi Zax,

sound like a missing library.

In the "Standlone Application Settings..." the automatism "Search for required inclusions..." does not work reliably,
so you might need to check "Select inclusions for the standalone application" and add the TABLE libary manually via "Inclusions"


Best

Klaus

Klaus, you are my hero !!!!
Thank you so much for your quick answer.

Another question about Table Fields...

Pressing an arrow key when a cell of a Table Field is edited selects the next cell This is not very handy when trying to edit cells text.
So I tried to trap arrowKeys in the card script with: but only the rawKeyDown seem to be sended.
OK, but are the rawCodes cross-platform? For example, codes for arrow keys are 65361, 65362, 65363 and 65364 on my Mac, but are they the same with Windows?

Thanks.

I don't know, sorry.

That's where arrowKey is being intercepted.

Hi.

Many messages are sent from a table field:

keyUp
KeyDown
rawKeyUp
rawKeyDown
textChanged
scrollbarDrag

All these can be trapped in the card script.

Craig

Thank you for your answers.

@dunbarx: keydown message is not sent if the key is arrow:

If the key pressed is the Return, Tab, Backspace, Delete, or Enter key, an arrow key, or a function key, no keyDown message is sent. Instead, the returnKey, tabKey, backspaceKey, deleteKey, enterKey, arrowKey, or functionKey message is sent.

So, in my case, if I want to trap arrowKey message, I have to dig into revtablelibrary stack script, as bernard said.

Good news: it seems that rawKeyDown key codes are correctly handled on Windows.

keydown message is not sent if the key is arrow:

True, but that is not peculiar to table fields. Only rawKey[up|down] also send arrowKey parameters at all.

Craig

Zax wrote: ↑

Sun Aug 01, 2021 8:04 am

So, in my case, if I want to trap arrowKey message, I have to dig into revtablelibrary stack script, as bernard said.

Try this. Create a button on your card. Set the script of the button to this:
Select the button. Then type in msgbox "insert the script of selobj() into front".

That should allow you to intercept the arrowkey msg in the field that's created for editing "cells" of the table object. If you don't want that behaviour to apply to all table objects, then make the condition if "revcell" is in tLongName more specific (e.g. put a custom prop on the table object, then have condition check that the rect of target() is within the rect of the table object with that property).

On my test you can still get your "edit cell" by clicking, and arrowkey works in non-table fields.

Bernard wrote: ↑

Sun Aug 01, 2021 6:26 pm

Then type in msgbox "insert the script of selobj() into front".

Nice solution ! I never think of using "front" scripts (I always forget that it is possible to modify the hierarchy of messages).

You're welcome.

But we're doing something wrong as a community when someone who has been using the technology for a decade forgets these possibilities. In the old days one of the key things that LC Ltd charged more money for was how many scripts could be put into front and back. In itself that concept of charging to change scriptLimits pointed to the power of this feature. Without that link more-scripts=more-cost I think many new people have missed this power.

About 10 years ago Alan Kay did a talk about why everyone has misunderstood what he meant by object-orientation - he said that it all came down to message-passing and objects knowing if/how they should respond to messages. Livecode has become so rich in this way: object containment hierarchy, libraries, frontscripts, backscripts, behaviors, send in time, dispatch, before handlers, after handlers. It's so dynamic that sometimes one can make changes to the message path and later on find things are "broken" because one's intercepted something and forgotten that interception would have consequences elsewhere.

I think we need a map of the key technologies that make Livecode different from the rest. I've been writing to people this last week about what I think is missing in terms of orientating users.

Well, in my case, LC has become more and more powerful and I don't use it often enough to remember all the new possibilities... That's why I'm extremely happy to use this forum, because I know that I will find quick answers there and its users will answer me, even if I can sometimes ask stupid questions!