newbie datagrid question: field editing

LiveCode is the premier environment for creating multi-platform solutions for all major operating systems - Windows, Mac OS X, Linux, the Web, Server environments and Mobile platforms. Brand new to LiveCode? Welcome!

Moderators: Klaus, FourthWorld, heatherlaine, kevinmiller, robinmiller

Post Reply
jkrische
Posts: 16
Joined: Mon Oct 06, 2008 5:45 pm

newbie datagrid question: field editing

Post by jkrische » Wed Jun 03, 2009 8:32 am

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.

trevordevore
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 979
Joined: Sat Apr 08, 2006 3:06 pm
Location: Overland Park, Kansas
Contact:

Post by trevordevore » Thu Jun 04, 2009 5:05 pm

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.
Trevor DeVore
ScreenSteps - http://www.screensteps.com

Levure Application Framework: https://github.com/trevordevore/levure
LiveCode Resources for Developers: http://livecode.bluemangolearning.com

jkrische
Posts: 16
Joined: Mon Oct 06, 2008 5:45 pm

OK, this will put me in the right direction...

Post by jkrische » Thu Jun 04, 2009 6:32 pm

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:

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
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...

trevordevore
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 979
Joined: Sat Apr 08, 2006 3:06 pm
Location: Overland Park, Kansas
Contact:

Post by trevordevore » Thu Jun 04, 2009 6:42 pm

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?
Trevor DeVore
ScreenSteps - http://www.screensteps.com

Levure Application Framework: https://github.com/trevordevore/levure
LiveCode Resources for Developers: http://livecode.bluemangolearning.com

jkrische
Posts: 16
Joined: Mon Oct 06, 2008 5:45 pm

Right on...

Post by jkrische » Thu Jun 04, 2009 7:39 pm

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.

trevordevore
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 979
Joined: Sat Apr 08, 2006 3:06 pm
Location: Overland Park, Kansas
Contact:

Post by trevordevore » Thu Jun 04, 2009 7:40 pm

Sounds good to me :-)
Trevor DeVore
ScreenSteps - http://www.screensteps.com

Levure Application Framework: https://github.com/trevordevore/levure
LiveCode Resources for Developers: http://livecode.bluemangolearning.com

jkrische
Posts: 16
Joined: Mon Oct 06, 2008 5:45 pm

hot damn

Post by jkrische » Thu Jun 04, 2009 8:02 pm

heck yeah, working perfectly now. Eliminates the need for me to have a "post this edit" button on the end of the row, leaving that much more room for data display.

many thanks, Trevor.

Post Reply

Return to “Getting Started with LiveCode - Experienced Developers”