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. /Mats _______________________________________________ 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
