« June 2004 | Main | September 2004 »
July 11, 2004
Classic Autos on display
An Indianapolis classic car club held an exhibit and competition this weekend. Some really incredible cars from the early 1900's were there. More shots are in my gallery
Posted by donb at 11:01 AM | Comments (0)
July 04, 2004
Hungry Baby
Little guy was just sitting in the feeder, waiting for Mom to come by and feed him.
Posted by donb at 08:00 AM | Comments (0)
July 02, 2004
Editable Grid - stop updating all rows!
One thing that seems to be a problem for everyone is the fact an Editable Grid control will update all rows, not just those that you've actually edited. Why, Yes, why?
It's been a problem for me when I wanted to have an audit trail of whos changed what and when. The way the Ed Grid works, this means lots of audit updates occur - even when there was nothing change! Bad. Very bad.
Well, I decided to see what I could do about this to avoid the problem.
I began playing with the events to see what information was going to be available to me. Well, the answer is, "Not much."
I put a checkbox on the grid as an indicator that "this record has bee updated". That's fine, except (for some reason) when the (Before or After) Update events fire, This checkbox only has the value of the last row of my grid. Hmmmm more "bad".
If the checkbox is bound to the underlying Data Source, then it becomes available for each row as EdGrid.Datasource.Checkbox1.Value, AND it reflects the value for each row. Ta Da! But wait, not so fast. There is a problem. That checkbox does not have a corresponding column in the Data Source, so a nasty SQL error appears, telling me it's not going to update the database.
Now comes the interesting part: What if I removed the non-existent column from the Update query? All would be fine. BUT! How to do this? Well, there is a Command object contained in the Ed Grid (it's a property of the grid class). I named my checkbox "Marked" and assigned the checked/unchecked values to 1/0. Thus, the Command object's SQL property contains either "Marked='0'" or "Marked='1'", so it's easy to simply excise this from the EdGrid.Command.SQL property.
Voila! I also now have a useable indicator of each row in the grid, which can tell me whether it's been updated or not.
A refinement to this technique would be to use a Hidden textbox with a default value of 0, and with a little javascript, "set" the hidden control's value to 1 whenever one of the other columns is modified (via the onclick() client-side event). That would make the detection of changed rows automatic. To finish things off, whenever the "changed" control is a "1", dump the Update instead of executing it.
There are still some details to work out before this is fully functional. When they are, the Ed Grid will only update rows where data was changed, and thus, NEEDS to be updated.
Once it is done, I'll be posting the code and documentation on gotodon.com
Posted by donb at 08:00 AM | Comments (0)
July 01, 2004
CCS Needs more class
I really hope that CCS evolves from the "collection of functions" model into one where features are mostly encapsulated into class modules. Oddly, all the internal structures that CCS provides (like datasources and controls) are classes, but when you get to things like security information (e.g., CCGetUserID or CCGetGroupID) and other things, these are provided as functions
Documenting the "runtime" elements needs to be more complete and insightful. There are a lot of functions that don't appear in the help file - for reasons known only to Yes Software. Maybe they are only temporary or maybe they forgot. But it's a pain either way. It's not always clear how to use them, either - even when they are in the help file. Take the add/remove parameter function. I defy anyone to makes use of these just by reading the help file.
Good documentation is not voluminous, it does not merely regurigate the parameters which must be passed into functions. It is (brief) and insightful description of the software - "why" as well as "what", so that the user can understand why something does what it does, not just that you have to give it 2 parameters that are strings.
I think a regular and consistent organization of the runtime into classes would help greatly with understanding and using CCS.
Posted by donb at 08:00 AM | Comments (0)