How to use
by matooo on Jan.07, 2009, under Uncategorized
Since this is WIP (work in progress). Best way to work with this library is to
- Update library from svn
- Add projects System.Data.Bindings and gtk-databind-lib to your solution
- Reference your solution to those two projects and that is it
Now, you can freely update it from svn and your own project will reflect changes asap.
5 comments for this entry:
February 4th, 2009 on 8:55 pm
I have been keeping my eye on this for some time now, knowing that I would be needing to dig in further at some point. Well that point is now.
Here is my goal:
1. Create a “DataGrid” that is reusable.
2. Use a DbLinq Table for the DataSource.
Where would you suggest I start? Is there a particular sample that I should look at closer? Is there any existing “DataGrid” that I could extend?
February 22nd, 2009 on 5:36 pm
DataGrid??? you mean like MS…??
No need for that. DataTreeView already has everything what it needs for that…. except CellRenderer type editors. DataTreeView already has complete support for specifying custom CellRenderer types per column in Mappings (look sample1). The only thing you need is Mappings string builder, nothing else. You can send me your CellRenderer types and I’ll gladly include them inside of this library. I already mentioned in one of my blog posts that this is one of the topics I’d like to see more user intervention.
In short you only build Mappings string property. From here… everything is already there. Columns and editors will change. Data will reload.
Using DbLinq table as DataSource? What is stopping you to do that now? Just read Memory handling… post. If you don’t understand something simply ask. For now I haven’t yet decided if my so called bug is not a feature. Memory consumption is way lower than before. The only thing that is required from you as user of this library is to keep one reference of that object alive during the life of the form. Which means:
SomeForm.DataSource = select ….;
AVOID THIS!!!!
// don’t know the result of DbLinq, so forgive me if I declared a wrong
IEnumerable a = select …..;
SomeForm.DataSource = a;
// keep a alive until form is alive
SomeForm.DataSource = null;
a = null;
I know it is few additional lines. But having reduced memory to 10% is a very nice feature to have. So… I’m still questioning this one. Bug or a feature? Could be called bug… yes… but… since it forces you to reduce memory consumption in every software???? It is a bug that produces way better results and more active GC.
February 23rd, 2009 on 5:44 pm
Thank you for the response, I don’t mind at all that it took so long, and I completely understand being busy. I have come to learn that the DataTreeView is the right control. Part of my challenge (handicap) has been that I haven’t done this type of data driven application in GTK#, only in MS.
The part I am not understanding then, is if my objects have to inherit from Observeable (no offense, but it should be spelled Observable), and ObserveableArrayList or ObserveableList. Or do I really just need the mapping string?
Anyhow I am glad to have your work with databinding to build upon, and as my needs increase, I will likely need to do some CellRenderers of my own which I will be more than happy to submit to you for inclusion.
Thanks.
February 24th, 2009 on 11:02 am
Thank you!
February 24th, 2009 on 2:15 pm
Inheriting from Observeable is deprecated now;) Observeable was used for two way communication between widgets and data binding. Instead rather use INotifyPropertyChanged data types as I specified in one of my posts. Note: Observeable…*anything lists are not deprecated.
As far as simple data lists go? Well, in fact any IList object does the trick. But using Observeable…(anythingList) provides communication for Hierarchical changes and parenting of the lists. So if any observed object changes, he notifies list, that one notifies all observeable lists that specify it as element and so on. In case of linear lists, MS.Net already has right messages, and I’d reuse those, except TreeView is so much more than linear data list provider. So I had to add something able to handle hierarchy.
But the data you want to handle is simple linear data list. So… yes, any list class and INotifyPropertyChanged data classes will do the trick. In sample1 I use special cellrenderer for percentage, but you can register any cellrenderer under specific name and then use it trough string mapping. So in short, after you have working cellrenderers… building mapping string and specifying it to list mapping property is the only thing needed. You might wanna look at my last post, where I went on describing how to make usable widget, which is also reusable as CellRenderer.