Scripting Data Grid creation
matsastrom at yahoo.se
Wed Feb 24 18:02:49 EST 2016
This is about the DG strategy I choosed.
The task: a data centric application with lots of dB tables (+50) that needed to be presented, some of the tables needed to be cell editable in an ”Excel fashion” (double-click-edit-return), the user be able to specify visible/hidden columns, specify column witdths all to be saved between sessions… and more.
I had no desire to code a GUI for each table so I dug into the heart of the Data Grid. My starting point was how the .net TableAdapter and DataGridView works. I had never (and have not yet) coded C# .net but the solution I was to upgrade/replace was built in .net and I was handed a Visual Studio project and its (to me) somewhat incompahencible code.
So I went for this:
A generic LC stack method that copy’s the DG template and creates a DG on the fly. The method is passed a number of parameters telling it:
- which dB to connect to
- which table to read from
- the DG size & position
- an (optional) SQL SELECT statement
- if a menu should accompany the DG
- whether or not update/insert is allowed (in which case the appropriate menu items are shown)
… and more
The method reads the dB table’s column characteristics from the dB schema and sets the DG columns headers (via a column-name-to-header text mapping function) and the DG column alignment sdepending on column data types. It also sets the DG text properties and populates the DG.
All DG:s are thus created programmatically and then deleted when they are no longer visible in the GUI (accomplished by keeping track of the visible DG(s)). Performance is reasonable - a DG with 3-4000 lines takes 3-4 secs. I am not so sure if this approach would be ok on very large tables.
All DG-related scripts, all DG editing and ”db-manipulation-related” code, all DG menus & menu scripts are also created on the fly by extensive use of behaviors.
Even though this might not be the most beautiful code I ever wrote (some of the requirements came in late - at least that is what I will plead in court) the whole ”DG affair” came out manageble through this approach.
It all took a great deal of trial & error because, although the DG documentation is correct, everything was not all that easy to figure out.
But all in all it was well worth the effort.
I admit that it came out a bit complex, but it is reusable, stable and still works like a charm.
More information about the use-livecode