Table Field locked in standalone?
Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller
Table Field locked in standalone?
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.
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.
Re: Table Field locked in standalone?
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
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
Re: Table Field locked in standalone?
Klaus, you are my hero !!!!
Thank you so much for your quick answer.
Thank you so much for your quick answer.
Re: Table Field locked in standalone?
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.
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:
Code: Select all
on arrowKey tKey
on rawKeyDown rawKey
on keyDown tKey
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.
Re: Table Field locked in standalone?
I don't know, sorry.
Re: Table Field locked in standalone?
Code: Select all
edit the script of stack "revtablelibrary"
-
- VIP Livecode Opensource Backer
- Posts: 9582
- Joined: Wed May 06, 2009 2:28 pm
- Location: New York, NY
Re: Table Field locked in standalone?
Hi.
Many messages are sent from a table field:
Craig
Many messages are sent from a table field:
All these can be trapped in the card script.keyUp
KeyDown
rawKeyUp
rawKeyDown
textChanged
scrollbarDrag
Craig
Re: Table Field locked in standalone?
Thank you for your answers.
@dunbarx: keydown message is not sent if the key is arrow:
Good news: it seems that rawKeyDown key codes are correctly handled on Windows.
@dunbarx: keydown message is not sent if the key is arrow:
So, in my case, if I want to trap arrowKey message, I have to dig into revtablelibrary stack script, as bernard said.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.
Good news: it seems that rawKeyDown key codes are correctly handled on Windows.
-
- VIP Livecode Opensource Backer
- Posts: 9582
- Joined: Wed May 06, 2009 2:28 pm
- Location: New York, NY
Re: Table Field locked in standalone?
True, but that is not peculiar to table fields. Only rawKey[up|down] also send arrowKey parameters at all.keydown message is not sent if the key is arrow:
Craig
Re: Table Field locked in standalone?
Try this. Create a button on your card. Set the script of the button to this:
Code: Select all
on arrowKey
put the long name of target() into tLongName
if "revcell" is in tLongName then
put the long time && "block arrowKey" &cr& tLongName
else
pass arrowKey
end if
end arrowKey
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.
Re: Table Field locked in standalone?
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.
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.
Re: Table Field locked in standalone?
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!