**** The DataGrids! All of them!
-
:mad: :mad: :mad: I've spent a lot of time playing with my datagrid control and its associated datatable, and I think I did it all wrong. My scheme is way to complicated. I read a user defined data structure in from a file, then fill out the datagrid from it. Then I track any changes to the datagrid, update the datagrid to reflect these changes (these former two steps are giving me too much trouble, prolly b/c my overlycomplicated design), and then rebuild the structure from these changes. However, there seems to be some interdependencies in the updating of the datagrid that depends upon nonupdated information in the data structure, and it's all a big mess. :(( My actual on-disk data format is XML, which is then parsed into the datastructure for program specific manipulations (calculating chess scores from a tournament database if you must know). I want my users to be able to create and edit chess tournament databases using this datagrid, which will then be mapped into the in-memory data structure for the calculation and manipulation, and finally saved to a disk in XML format. I have all the XML -> Datastructure and Datastructure -> XML stuff down, but the user input is really getting to me. So, before I start with my datagrid all over again, I need to know how I'm supposed to do this. My current idea is: + Load the file into the data structure + Update the datagrid/datatable (I am using them as one, there's only one table). + Use the RowChanged event to determine when the datagrid is modified. If so, make those changes INSIDE THE DATA STRUCTURE. Then, after the datastructure is updated, set a flag so that RowChanged does nothing, and rebuild the datagrid from the beginning using the data structure. After it is rebuilt, set the RowChanged flag back so that it responds to user input. I want RowChanged to respond to userinput, but not to respond to itself. I will know this all works when I can throw any valid input into it, and get the same thing out, only now stored in the data structure. When I throw in invalid or incomplete (ie, half a row) input, it should not parse it at all, simply leave it there. Sound good? There must be a standard way of doing this. I am completely new to all this database stuff.
-Domenic Denicola- [CPUA 0x1337] MadHamster Creations
-
:mad: :mad: :mad: I've spent a lot of time playing with my datagrid control and its associated datatable, and I think I did it all wrong. My scheme is way to complicated. I read a user defined data structure in from a file, then fill out the datagrid from it. Then I track any changes to the datagrid, update the datagrid to reflect these changes (these former two steps are giving me too much trouble, prolly b/c my overlycomplicated design), and then rebuild the structure from these changes. However, there seems to be some interdependencies in the updating of the datagrid that depends upon nonupdated information in the data structure, and it's all a big mess. :(( My actual on-disk data format is XML, which is then parsed into the datastructure for program specific manipulations (calculating chess scores from a tournament database if you must know). I want my users to be able to create and edit chess tournament databases using this datagrid, which will then be mapped into the in-memory data structure for the calculation and manipulation, and finally saved to a disk in XML format. I have all the XML -> Datastructure and Datastructure -> XML stuff down, but the user input is really getting to me. So, before I start with my datagrid all over again, I need to know how I'm supposed to do this. My current idea is: + Load the file into the data structure + Update the datagrid/datatable (I am using them as one, there's only one table). + Use the RowChanged event to determine when the datagrid is modified. If so, make those changes INSIDE THE DATA STRUCTURE. Then, after the datastructure is updated, set a flag so that RowChanged does nothing, and rebuild the datagrid from the beginning using the data structure. After it is rebuilt, set the RowChanged flag back so that it responds to user input. I want RowChanged to respond to userinput, but not to respond to itself. I will know this all works when I can throw any valid input into it, and get the same thing out, only now stored in the data structure. When I throw in invalid or incomplete (ie, half a row) input, it should not parse it at all, simply leave it there. Sound good? There must be a standard way of doing this. I am completely new to all this database stuff.
-Domenic Denicola- [CPUA 0x1337] MadHamster Creations
I think the recommended way of working with data is through the DataSet. You can load a dataset from xml (create a schema then specify where to load it from an the schema), then bind the dataset to the datagrid, once you are done editing you should then be able to save the data back to the xml file. DataSets are a bit mysterious to me though; most of my data access has only been single read/writes so I've not had to worry about that yet :) James Sonork ID: 100.11138 - Hasaki "Smile your little smile, take some tea with me awhile. And every day we'll turn another page. Behind our glass we'll sit and look at our ever-open book, One brown mouse sitting in a cage." "One Brown Mouse" from Heavy Horses, Jethro Tull 1978
-
I think the recommended way of working with data is through the DataSet. You can load a dataset from xml (create a schema then specify where to load it from an the schema), then bind the dataset to the datagrid, once you are done editing you should then be able to save the data back to the xml file. DataSets are a bit mysterious to me though; most of my data access has only been single read/writes so I've not had to worry about that yet :) James Sonork ID: 100.11138 - Hasaki "Smile your little smile, take some tea with me awhile. And every day we'll turn another page. Behind our glass we'll sit and look at our ever-open book, One brown mouse sitting in a cage." "One Brown Mouse" from Heavy Horses, Jethro Tull 1978
A dataset seems to just be a collection of datatables that relate to each other. I only use one data table, and I only want to use it for display and user input purposes. My custom data structure is the best way of storing and manipulating my data, everything is organized for maximum usefulness from the programming side of view. I would like to use the datagrid as a method of directly editing and creating those data structures. What I am trying to say is, this program is primarily a computation program, not a database program. I have all the code for computation on my data structure and loading into my data structure. I simply want a viable way to display all this data both before and after computation, and also to edit and create new data. DataGrids looked like the solution to my problem, but I dunno, maybe I've stepped too far into the realm of database programming by using them. I JUST WANT USERS TO BE ABLE TO SEE, EDIT, AND CREATE DATA IN A GRID-LIKE FORMAT. I don't want to run a commercial database, or use ADO.NET, or generally have anything to do with the conventional meaning of "database". Does that help clarify my problem? It is all very confusing, and hard to explain. Sorry if I've just made it worse.
-Domenic Denicola- [CPUA 0x1337] MadHamster Creations "I was born human. But this was an accident of fate - a condition merely of time and place. I believe it's something we have the power to change..."
-
A dataset seems to just be a collection of datatables that relate to each other. I only use one data table, and I only want to use it for display and user input purposes. My custom data structure is the best way of storing and manipulating my data, everything is organized for maximum usefulness from the programming side of view. I would like to use the datagrid as a method of directly editing and creating those data structures. What I am trying to say is, this program is primarily a computation program, not a database program. I have all the code for computation on my data structure and loading into my data structure. I simply want a viable way to display all this data both before and after computation, and also to edit and create new data. DataGrids looked like the solution to my problem, but I dunno, maybe I've stepped too far into the realm of database programming by using them. I JUST WANT USERS TO BE ABLE TO SEE, EDIT, AND CREATE DATA IN A GRID-LIKE FORMAT. I don't want to run a commercial database, or use ADO.NET, or generally have anything to do with the conventional meaning of "database". Does that help clarify my problem? It is all very confusing, and hard to explain. Sorry if I've just made it worse.
-Domenic Denicola- [CPUA 0x1337] MadHamster Creations "I was born human. But this was an accident of fate - a condition merely of time and place. I believe it's something we have the power to change..."
[edit] bah after re-reading your original post I see I haven't posted anything helpful :(( About the best I can offer would be to let the grid do its job, then when you need the data, pull it from the datagrid all at once (or do it when you add/edit a row). [/edit] Domenic [CPUA 0x1337] wrote: A dataset seems to just be a collection of datatables that relate to each other. I only use one data table, and I only want to use it for display and user input purposes. The power of the dataset is its disconnected nature. The data stored in it is just that data; it doesn't have to come from a database at all. That is one of the strengths of .NET, it uses generic binding rather than forcing the use of ADO.NET or anyother database type technology. Domenic [CPUA 0x1337] wrote: DataGrids looked like the solution to my problem, but I dunno, maybe I've stepped too far into the realm of database programming by using them. After some playing around I think you can do what you need to with a single DataTable (as I think you originally suggested). Handling the ColumnChanging event lets you determine if a change should be allowed (if you don't want to allow the change throw an exception in the event handler). Unfortunately I don't see an event that tells you when a new row gets added (and accepted) so you may have a hard time to keep the two in synch at all times but so long as you know when it does/doesn't need to be in synch you can do so by going through the datarow collection on the table. Thanks for giving me the push to take a deeper look into DataGrids and DataTables :) James Sonork ID: 100.11138 - Hasaki "Smile your little smile, take some tea with me awhile. And every day we'll turn another page. Behind our glass we'll sit and look at our ever-open book, One brown mouse sitting in a cage." "One Brown Mouse" from Heavy Horses, Jethro Tull 1978
-
[edit] bah after re-reading your original post I see I haven't posted anything helpful :(( About the best I can offer would be to let the grid do its job, then when you need the data, pull it from the datagrid all at once (or do it when you add/edit a row). [/edit] Domenic [CPUA 0x1337] wrote: A dataset seems to just be a collection of datatables that relate to each other. I only use one data table, and I only want to use it for display and user input purposes. The power of the dataset is its disconnected nature. The data stored in it is just that data; it doesn't have to come from a database at all. That is one of the strengths of .NET, it uses generic binding rather than forcing the use of ADO.NET or anyother database type technology. Domenic [CPUA 0x1337] wrote: DataGrids looked like the solution to my problem, but I dunno, maybe I've stepped too far into the realm of database programming by using them. After some playing around I think you can do what you need to with a single DataTable (as I think you originally suggested). Handling the ColumnChanging event lets you determine if a change should be allowed (if you don't want to allow the change throw an exception in the event handler). Unfortunately I don't see an event that tells you when a new row gets added (and accepted) so you may have a hard time to keep the two in synch at all times but so long as you know when it does/doesn't need to be in synch you can do so by going through the datarow collection on the table. Thanks for giving me the push to take a deeper look into DataGrids and DataTables :) James Sonork ID: 100.11138 - Hasaki "Smile your little smile, take some tea with me awhile. And every day we'll turn another page. Behind our glass we'll sit and look at our ever-open book, One brown mouse sitting in a cage." "One Brown Mouse" from Heavy Horses, Jethro Tull 1978
James T. Johnson wrote: Handling the ColumnChanging event lets you determine if a change should be allowed (if you don't want to allow the change throw an exception in the event handler). Ahhh, so that's what's happening to my current code. It seems after I handle a deletion of a value, whenever I call DataTable.Columns.Remove(...) to reflect the invalidation of the row and update the columns accordingly, my ColumnChanged event handler is never called again. Ah, my code is way too messy anyway, it's prolly a good thing I'm redoing it. So, does this sound like a good plan? I just iterate through the rows every time columnchanging is called, determine the valid ones, rebuild my data structure using those, and then rebuild my datagrid from my datastructure. And how to decide between ColumnChanged and ColumnChanging? It seems ColumnChanged is called everytime the cursor moves out of the box or the data is otherwise accepted, which seems more appropriate than ColumnChanging, which is called whenever the column's value changes at all. I dunno, I'll work on it on the weekend when all this homework slows down :-D
-Domenic Denicola- [CPUA 0x1337] MadHamster Creations "I was born human. But this was an accident of fate - a condition merely of time and place. I believe it's something we have the power to change..."
-
James T. Johnson wrote: Handling the ColumnChanging event lets you determine if a change should be allowed (if you don't want to allow the change throw an exception in the event handler). Ahhh, so that's what's happening to my current code. It seems after I handle a deletion of a value, whenever I call DataTable.Columns.Remove(...) to reflect the invalidation of the row and update the columns accordingly, my ColumnChanged event handler is never called again. Ah, my code is way too messy anyway, it's prolly a good thing I'm redoing it. So, does this sound like a good plan? I just iterate through the rows every time columnchanging is called, determine the valid ones, rebuild my data structure using those, and then rebuild my datagrid from my datastructure. And how to decide between ColumnChanged and ColumnChanging? It seems ColumnChanged is called everytime the cursor moves out of the box or the data is otherwise accepted, which seems more appropriate than ColumnChanging, which is called whenever the column's value changes at all. I dunno, I'll work on it on the weekend when all this homework slows down :-D
-Domenic Denicola- [CPUA 0x1337] MadHamster Creations "I was born human. But this was an accident of fate - a condition merely of time and place. I believe it's something we have the power to change..."
Domenic [CPUA 0x1337] wrote: Ah, my code is way too messy anyway, it's prolly a good thing I'm redoing it. If its too messy its probably a good idea :) Personally I find myself redoing lots of code because it becomes difficult to discern what is going on. Domenic [CPUA 0x1337] wrote: So, does this sound like a good plan? I just iterate through the rows every time columnchanging is called, determine the valid ones, rebuild my data structure using those, and then rebuild my datagrid from my datastructure. Without knowing whats going on its hard to say what would be best. From what I know I would let the datatable do its job then pull the data out of it only when its needed. Handling the ColumnChanging/ColumnChanged events as needed for validation; then run a final validation with the RowChanging event to ensure that fields within a row are ok. Domenic [CPUA 0x1337] wrote: And how to decide between ColumnChanged and ColumnChanging? Here's a quote from the documentation. The ColumnChanging, RowChanging, and RowDeleting events are raised during the update process. You can use these events to validate data or perform other types of processing. Because the updates are in process during these events, you can cancel the update by throwing an exception, which prevents the change from being completed. For more information, see Data Validation in Datasets. The ColumnChanged, RowChanged, and RowDeleted events are notification events that are raised when the update has been completed successfully. These events are useful when you want to take further action based on a successful update. Hopefully you can get some idea where to go from here :) James Sonork ID: 100.11138 - Hasaki "Smile your little smile, take some tea with me awhile. And every day we'll turn another page. Behind our glass we'll sit and look at our ever-open book, One brown mouse sitting in a cage." "One Brown Mouse" from Heavy Horses, Jethro Tull 1978