This may be the day of class I missed but is it possible to bind a textbox (or datepicker or grid or whatever ) to a property ( which perhaps is a list(of T) ) declared in the code of the form itself? i.e. no business object, just whatever is done to that control changes the value of the property without further coding.



I guess one could test on leaving a textbox or whatever and then change the property based on the text but I was thinking more of two way binding to a property. Seems the properties sheet wants a bizobj in order to bind. Should I use a non SF textbox for something like this?



Just feel I'm missing/forgetting/am completely ignorant of something very basic ...

I don't think this is going to be an SF thing. I'd look into ADO binding, though I'm not sure that would do it either.



Another possibility would be to subclass the control (textbox, datatime picker (datebox is nicer)) and add a property (i.e. list). If the property is a reference type, then changing it via the control would change it in your variable. I think you'd still have to do some work to then display the value of the property in the control. For value types, I think you'd have to handle an event on the control and then update the variable.

In Visual FoxPro you could define a form's property and then use that property as the binding control source and it will be updated automatically. I believe Charles is looking for the same feature.



Sorry I can not be of much help here since I was looking for the same a week ago and just opted for reading the control's value and update my property manually.

Edhy Rijo

I think SF/ADO binding is intended to bind the property of some control/component to data (in a datatable). I don't think it can just arbitrarily bind two objects together. I'm not exactly sure I see the need, but then I've never used VFP....

My thought was, if I have a collection - List(of String) let's say - stored in a SQL column. When I deserialize that list I now have a local variable that is a list of strings for that record in the BO. I want that list to be displayed on the screen in a listview, checkedlistbox or whatever. I want any changes made in that UI component to be reflected in the current contents of the list, such that when I'm done if I write that list back into the SQL column on save the changes are retained.



As I write this I"m realizing that because of the disconnected nature of the collection UI controls themselves, I am still going to have to be writing changes back to the property/variable so I guess the direct binding thing is moot for any control that is more than just a single value.



I just wanted to make sure there wasn't some magic I was missing as I want to explore the idea of wide and shallow "child" records being stored as a single serialized object in the parent record.



I'm hoping Dustin will chime in here with a little more elaboration as to how they are doing that in the medical app.

Just wanted to bump this in hope Dustin or Trent would see it. I am particularly interested in storing a number of datatables, each representing a couple of columns of data that would show up on a form which I could present in the interface as plain ol' grids that resemble the form interface. IOW I want to store each datatable as if it is a child table



My thinking was to have one big object that is a collection of these datatables. when I save I store off the datatables to items in the collection, then store the whole collection in one column in sql.



This is data that will be used for filling in PDF forms, so the number of rows is very finite. my main concern is easy data entry for the user, with columnar data flowing as they would expect - i.e. filling in an entire row before creating a new row.



Am I on the right track with this?



Any suggestions, examples whatever would be greatly appreciated



>>My thought was, if I have a collection - List(of String) let's say - stored in a SQL column. When I deserialize that list I now have a local variable that is a list of strings for that record in the BO. I want that list to be displayed on the screen in a listview, checkedlistbox or whatever. I want any changes made in that UI component to be reflected in the current contents of the list, such that when I'm done if I write that list back into the SQL column on save the changes are retained.



As I write this I"m realizing that because of the disconnected nature of the collection UI controls themselves, I am still going to have to be writing changes back to the property/variable so I guess the direct binding thing is moot for any control that is more than just a single value.



I just wanted to make sure there wasn't some magic I was missing as I want to explore the idea of wide and shallow "child" records being stored as a single serialized object in the parent record.



I'm hoping Dustin will chime in here with a little more elaboration as to how they are doing that in the medical app.

This is actually something that we do (kindof) in our medical application. Not in regards to binding to a form property, which can be done easily by using the standard data binding, but there is the hitch. You will need to create a bindable collection to do what you are trying to do. Here is a generic declaration in VB (leaving out the rest of the code) of the collection and implementations to basically do what you need to do.











If you have never used the generic collection, it makes it very easy to create a quick collection for any class type. All of the above code is going to be slightly overkill for what you are trying to do (that is why I left all of the body of the class out). But you will need to focus on two implementations above that will allow you to natively bind to grids, etc. Start with creating a collection that exposes a simple class and implements IBindingList on the collection. Once you implement IBindingList, you will then be able to take your collection and attach it as a data source to a grid, for example, and all rows within the collection will show in the grid. Once you get a shell of this working, then you can take the next step as many lights will come on when you start this type of implementation.

Thanks Trent - actually bumped this in the wrong thread



In the business layer section I was talking about doing exactly what you are saying here - except I never dreamed I'd be able to bind these collections like this ! Way cool. I'm thinking of a list(of Datatable) so I can create exactly the "child" structure I need and serialize the entire list(of datatable) to a single SQL column.



In your medical app, do you store all the collections in one object ?



I'm still unclear at exactly what point to deserialize and start binding the objects in the collections to their grids but I'm sure once I start poking at the stuff you are showing here at least I'll be able to ask better question.s



I'm sure I'll have lots of questions as I go along but what you've given me here gives me a lot to research and I can certainly get started. I used generics a lot so that part is comfortable for me.



I promise when I get a test app working using this concept I'll share it in the user contributed stuff as I can see a lot of use for this approach when the "child" needs of a major datum are broad and shallow and maintenence of 100 child bo's would be a nightmare.

Yes, we tend to keep all the related collections in one object, and serliaze the "daddy" object.

So our "Claims" object has all kinds of members:
-Foreign keys t o patients, insurance carriers, etc.
-Specific fields related to values on paper claim forms
-Logical fields related to the type of claim (auto accident, related to employment, etc.)
-A collection containing all transactions on the claim
-Monteary totals on the claim
-Etc.

In our DB, we have a "Claims" table, which has 20 or so data columns that just store basic information used to find and filter claims, and one "Data" VarBinary column that contains the serialized claim object (which contains all of those members, including the related collections.) 

Hope that helps

Thanks, Dustin



Okay, sounds like so far I'm on track. Now the question is how do I treat that column in the BO? I would assume I load the data as I normally would and then deserialize the object. In my case at first I am going to try to make the objects in the collection all datatables. I will have gridviews on the forms and after deserializing I will use the each item of the "daddy" object as the datasource for a grid. Seems this takes care of binding, no? (confess that as of this moment i've never even looked at grids in .net but by the end of today expect to have made chips in my ignorance - my understanding currently is that unlike listview a grid is actually directly connected to the datatable that is its datasource. )



In save pre I will re-serialize the daddy object list(of datatable) to the bo.daddyobject property and then save the policy?



Make sense?