newbie datagrid question: field editing
Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, robinmiller
newbie datagrid question: field editing
Hi All...
I have a datagrid, table style, in which some columns have editing allowed. The grid is meant to be a live front end into an SQLite DB, so I am trying to do what is necessary to make that happen, ie, when a field is changed, write it to the DB immediately.
In my grid's script i have placed an "on closeFieldEditor" section which is correctly getting the data from the line as it originally was filled, and is getting the correct line number, which field was edited, etc. What I cannot seem to get is how to capture the data that was just typed in, ie, the new value, not the original value, so that I can pass that value on to the DB.
So, how does one capture the new value? There has to be something in runrev that means "the new value" but my search of the dictionary and the manual is coming up nill, so maybe I'm looking for the wrong words.
I have a datagrid, table style, in which some columns have editing allowed. The grid is meant to be a live front end into an SQLite DB, so I am trying to do what is necessary to make that happen, ie, when a field is changed, write it to the DB immediately.
In my grid's script i have placed an "on closeFieldEditor" section which is correctly getting the data from the line as it originally was filled, and is getting the correct line number, which field was edited, etc. What I cannot seem to get is how to capture the data that was just typed in, ie, the new value, not the original value, so that I can pass that value on to the DB.
So, how does one capture the new value? There has to be something in runrev that means "the new value" but my search of the dictionary and the manual is coming up nill, so maybe I'm looking for the wrong words.
-
- VIP Livecode Opensource Backer
- Posts: 1005
- Joined: Sat Apr 08, 2006 3:06 pm
- Location: Overland Park, Kansas
- Contact:
I've just added some new lessons to the docs that begin to discuss field editing. I've also added the relevant API calls to the docs.
This lesson will describe the calls you can use and links to the API docs which provide the details of each.
How Do I Open a Table Cell For Editing?
As for you particular scenario you can just grab the text of field pFieldEditor (the first parameter sent with CloseFieldEditor) and store that in the database. The default behavior for a data grid table is to automatically store the value in the dgData after CloseFieldEditor is processed but you can override that (see API docs for EditFieldText).
Read through the above lesson and the relevant API docs entries and let me know if you need further clairification after that.
This lesson will describe the calls you can use and links to the API docs which provide the details of each.
How Do I Open a Table Cell For Editing?
As for you particular scenario you can just grab the text of field pFieldEditor (the first parameter sent with CloseFieldEditor) and store that in the database. The default behavior for a data grid table is to automatically store the value in the dgData after CloseFieldEditor is processed but you can override that (see API docs for EditFieldText).
Read through the above lesson and the relevant API docs entries and let me know if you need further clairification after that.
Trevor DeVore
ScreenSteps - https://www.screensteps.com
LiveCode Repos - https://github.com/search?q=user%3Atrevordevore+topic:livecode
LiveCode Builder Repos - https://github.com/search?q=user%3Atrevordevore+topic:livecode-builder
ScreenSteps - https://www.screensteps.com
LiveCode Repos - https://github.com/search?q=user%3Atrevordevore+topic:livecode
LiveCode Builder Repos - https://github.com/search?q=user%3Atrevordevore+topic:livecode-builder
OK, this will put me in the right direction...
Thanks again, Trevor. You Da Man.
So, if I am reading this right, a good procedure might be something like this, placed inside the column behavior:
Is this correct?
It looks right on first glance, and isn't that far from what I had already, the pFieldEditor bit being the missing link.
So, if I have a calculated value based on this value elsewhere on the row, I'm probably not going to want to refresh the whole grid at this point to get that calc to update. Instead, staying inside the closeFieldEditor section above, I would be more wise to apply a "delta" to the existing value, yes? Would the grid then immediately display the new value or would I still need to call a RefreshList step? If I do a grid refresh, the user will lose their current table cell placement, and I don't want that as they may well want to be editing another cell in the row. Fewer clicks, more "natural" feel, happier users.
For example, the field in question is a time value from the DB, and elsewhere on the row is a calculated "time interval from previous row" value. This value was initialy calc'ed by the SQL query (and what a calc it is), but if the user changes the time entry of a line then the interval of this row and the next row must change. Fortunately, I know the dgData of each field before the update, and thanks to this post I now know the new value, so I could simply subtract the two, apply this delta-T to the interval's value with a GetDataOfIndex[theIndex] / subtract the delta-T / format the time as preferred / SetDataOfIndex[theIndex] routine, yes? Then rinse & repeat for the next row in the grid, which I can figure out, I think.
Or am I smoking something and need to rethink this in a major way...
So, if I am reading this right, a good procedure might be something like this, placed inside the column behavior:
Code: Select all
on CloseFieldEditor pFieldEditor
put the dgIndex of me into theIndex
put the short name of me into theFieldname
put the text of pFieldEditor into theValue
put the dgDataOfIndex[theIndex] of group "my_datagrid_name" into theDataA
put theDataA["dbRecID"] into dbRecID
SetDataOfIndex theIndex, theFieldname, theValue
// now that the dg's internal array is updated, do external db-related stuff
put "UPDATE sometable SET myfield=" & quote & theValue & quote & " WHERE lineID=" & dbRecID & ";" into tSQL
revExecuteSQL(myConID, tSQL)
if result blah blah blah error trapping blah blah
end CloseFieldEditor
It looks right on first glance, and isn't that far from what I had already, the pFieldEditor bit being the missing link.
So, if I have a calculated value based on this value elsewhere on the row, I'm probably not going to want to refresh the whole grid at this point to get that calc to update. Instead, staying inside the closeFieldEditor section above, I would be more wise to apply a "delta" to the existing value, yes? Would the grid then immediately display the new value or would I still need to call a RefreshList step? If I do a grid refresh, the user will lose their current table cell placement, and I don't want that as they may well want to be editing another cell in the row. Fewer clicks, more "natural" feel, happier users.
For example, the field in question is a time value from the DB, and elsewhere on the row is a calculated "time interval from previous row" value. This value was initialy calc'ed by the SQL query (and what a calc it is), but if the user changes the time entry of a line then the interval of this row and the next row must change. Fortunately, I know the dgData of each field before the update, and thanks to this post I now know the new value, so I could simply subtract the two, apply this delta-T to the interval's value with a GetDataOfIndex[theIndex] / subtract the delta-T / format the time as preferred / SetDataOfIndex[theIndex] routine, yes? Then rinse & repeat for the next row in the grid, which I can figure out, I think.
Or am I smoking something and need to rethink this in a major way...
-
- VIP Livecode Opensource Backer
- Posts: 1005
- Joined: Sat Apr 08, 2006 3:06 pm
- Location: Overland Park, Kansas
- Contact:
Yeah, that looks right. Note that if you are using the default column behavior then the data grid will save the contents (because the column behavior passes all three params to EditFieldText) of pFieldEditor again unless you pass "cancel". If you pass cancel though you have to make sure the data grid is refreshed.
Here is how updating works:
SetDataOfIndex DOES NOT refresh the data grid. It allows you to store values without redrawing.
dgDataOfIndex DOES refresh the data grid display. dgDataOfLine is supposed to as well but doesn't in the current build. I am preparing a new data grid stack for release that has this fix though.
So in your example you would want to set the dgDataOfIndex to refresh.
The same goes for your desire to change the next line. You can get the dgDataOfIndex for the next row, change a value and then set the dgDataOfIndex and the UI will update. Make sense?
Here is how updating works:
SetDataOfIndex DOES NOT refresh the data grid. It allows you to store values without redrawing.
dgDataOfIndex DOES refresh the data grid display. dgDataOfLine is supposed to as well but doesn't in the current build. I am preparing a new data grid stack for release that has this fix though.
So in your example you would want to set the dgDataOfIndex to refresh.
The same goes for your desire to change the next line. You can get the dgDataOfIndex for the next row, change a value and then set the dgDataOfIndex and the UI will update. Make sense?
Trevor DeVore
ScreenSteps - https://www.screensteps.com
LiveCode Repos - https://github.com/search?q=user%3Atrevordevore+topic:livecode
LiveCode Builder Repos - https://github.com/search?q=user%3Atrevordevore+topic:livecode-builder
ScreenSteps - https://www.screensteps.com
LiveCode Repos - https://github.com/search?q=user%3Atrevordevore+topic:livecode
LiveCode Builder Repos - https://github.com/search?q=user%3Atrevordevore+topic:livecode-builder
Right on...
Yeah, that makes perfect sense. Again, major thanks.
You and a couple other folks here on the forums are SO getting a free copy of what I come up with and props in the "about this app" box... don't know if you'll have use for it or if it will be an adequate token of thanks, but it's all I've got to offer.
You and a couple other folks here on the forums are SO getting a free copy of what I come up with and props in the "about this app" box... don't know if you'll have use for it or if it will be an adequate token of thanks, but it's all I've got to offer.
-
- VIP Livecode Opensource Backer
- Posts: 1005
- Joined: Sat Apr 08, 2006 3:06 pm
- Location: Overland Park, Kansas
- Contact: