Datagrids have a distinct advantage over normal LC field objects in several 
areas. First, there is included a method for displaying huge amounts of data 
beyond what a normal field could handle. Secondly, you get a LOT more control 
about how to format and display the data. Things you would think were simple, 
like changing the size and justification of a column are actually fairly 
complex things to do. Datagrids handle these with ease. 

I personally wish there was some kind of "actLikeASpreadSheet" property you 
could set for a dataGrid and have it work like a basic Excel table (minus the 
formulas of course) but I remember when there was no table object to speak of. 
It's a glorious new day with dataGrids! 

If the datagrid needs to display several known data structures, I have done 
something along these lines. I use a shared background that contains 2 
datagrids. (The second is only for displaying relational data from linked 
tables). I sent you a screen shot of what I have done to your personal email. 
All the cards of this type share the datagrid. I have code that reads data from 
a database, then populates the datagrid. I store the column structure 
information in custom properties and set up the datagrid on opencard. Each card 
represents a different data structure, and has it's own set of properties. 

What I have done gets pretty involved. I have what I call a Field Dropper, 
which allows you to pick a column from a table in a database, and then answer 
some questions about how you want it displayed on the form. It's merely 
utilitarian, and for the dev only, for form generation. The point is, I have a 
framework for building forms because I foresaw what you are presently 
struggling with. The field dropper updates all the properties necessary for the 
form to work properly. 

Your approach need not be that complex. If you are working with arrays, just 
get the keys of the array and format them in such a way as to pass it to you 
datagrid using dgprop["columns"]. You will probably want at some point to play 
around with dgprop["column widths"] and dgprop["column labels"]. (Doing this 
from memory so check me on that). 

The trouble comes in with your form fields. This is why I use a different card 
for each form I need. If your forms are known and fixed, you can just use that 
approach. If however your data structure and hence your forms are unknown, if 
you are making something to open any table and edit it, then it becomes a lot 
more work. I wouldn't use a forms based approach, but rather I would learn how 
to work with opening a datagrid for editing and working through it that way. I 
personally do not like the look and feel of a datagrid edit session. It feels 
clunky to me. 

Bob


On Sep 28, 2012, at 3:49 PM, Dr. Hawkins wrote:

> And then gmail ate my message, with no saved version???
> 
> Anyway, let's see if I can remember all of this.
> 
> It seems that the file "LiveCode_Data_Grd.pdf" is what passes for
> documentation for datagrids?  Or is there some other manual out there
> that actually documents it?
> 
> This seems to be a situation of shooting flies with cannon.  I need to
> have the user able to enter rows with two to four elements, with
> usually zero to a few rows, but sometimes a great many.  Always pure
> text, but might be multiple lines.
> 
> So since I need to work with rows, I need a "Form" template rather
> than the "table" type? (In spite of this being what we'd call a
> "table" in English?)
> 
> loading/saving from a 2d array is not a problem.  It then seems that I
> should set the dgData to this array?
> 
> So i drag a dg onto my card, then click on the row behavior & template
> behavior to get stuff copied over, and start editing those?
> 
> And then add buttons to the template for things like delete row?
> 
> And since three are something like 50 different ones of these that I
> want to edit with the same editor, I can name the fields I add to the
> template A, B, C, and D, and set the widths & position of these in the
> template from a script?
> 
> Am I getting anything out of this as opposed to a basic table other
> than being able to have a delete button, not have to trap for return
> to not jump down a row, and getting alternating grey rows?
> 
> thanks
> 
> 
> -- 
> Richard E. Hawkins, Esq.
> (702) 508-8462
> 
> _______________________________________________
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Reply via email to