Added some basic functionality to the program.

[schematic] / src / vendorclassdialog.cpp

diff --git a/src/vendorclassdialog.cpp b/src/vendorclassdialog.cpp
index ba670b96894163fad9500962d9ddac0d3c1a5241..61fe7b5e5a4267bd8bb50215b8720b864b5506d0 100644 (file)
--- a/src/vendorclassdialog.cpp
+++ b/src/vendorclassdialog.cpp
@@ -214,5 +214,33 @@ void VendorClassDialog::LoadList(void)
 
 void VendorClassDialog::SaveList(void)
 {
+#if 0
+We need to do a few things here. One approach is to drop the VendorGroup and VendorType
+tables and recreate them, but that approach might cause VendorSpecificTypes to contain
+invalid data.
+
+Another approach is to keep track of keys (vgid for VendorGroup items, vtid & vgid for
+VendorType items) and do an update for items with keys, and a regular add for items
+that don't have keys (items that the user added to the dialog). That approach will keep
+VendorSpecificTypes from being corrupted, but requires more overhead in the tracking
+department.
+
+One way to track those items would be to put the array # into the user data area; that
+way when we get here we can query that data to determine if there's keys associated with
+an entry or not and how to handle it. Unfortunately, we're already using the user data
+role to determine whether or not an item is a header. But we could fix that by giving
+it a number and using that number as an index into oldList--but that wouldn't work for
+new items! :-P
+
+So maybe the correct approach is to compare what's in the ListWidget with what's in
+oldList, that way we can ignore things that didn't change. But what about those that did?
+In that case, you're screwed.
+
+It would still be useful to do that in order to detect the case where the user deleted
+something and then changed his mind and put it back.
+
+
+#endif
+
 }