This thread looks to be a little on the old side and therefore may no longer be relevant. Please see if there is a newer thread on the subject and ensure you're using the most recent build of any software if your question regards a particular product.
This thread has been locked and is no longer accepting new posts, if you have a question regarding this topic please email us at support@mindscape.co.nz
|
Hello- Does anyone have any comments on or experience with using LightSpeed with the Infragistics Winforms toolset? [NetAdvantage for .NET 2008 Vol. 2 CLR 2.0] In particular, I heavily use the Infragistics UltraGrid with both single DataTable binding and Parent/Child DataSet binding. I've successfully bound a LightSpeed class extending Entity to the UltraGrid and it seems to be okay but I'm having troubles binding a heirarchicaly Parent/Child structure to the UltraGrid. For example, from the LightSpeed walkthrough, m_Work = m_Context.CreateUnitOfWork(); The 'heirarchical' rows appear properly in the Infragistics UltraGrid - indented, parent/child appearance - but I can't add/edit/delete from the Member row. I believe this is due to LightSpeed giving back IList which doesn't play nice with the UltraGrid and its multi-level abilities. Any correction to this assessment would be welcome. I am hoping someone on the forum has experience with the Infragistics toolset and would be willing to share any comments or experiences with me regarding LightSpeed. Visual Studio 2008, .NET 2.0, SQLite and MySQL Best regards, Robert |
|
|
Hello Robert, We don't have anyone familiar with the Infragistics toolset so we can't comment definitively. Hopefully if anybody else has already done this stuff then they will chime in! Having said that, I suspect you are right as to adding and deleting top-level items. A plain IList<T> does not support the binding interfaces that databound WinForms list controls like to see. Furthermore, even if the grid is happy to add and delete items, those changes won't get persisted because the items will not be added to or removed from the unit of work. A possible workaround for this is to use an BindingList<T> instead of the plain List<T> that LightSpeed creates for you. The API for this is a little bit more fiddly: BindingList<Member> members = new BindingList<Member>(); This will cause the found Member objects to be placed in your BindingList rather than in a new List created by LightSpeed. The grid may be happier to work with such a list. However, please note we do not have a copy of the Infragistics tool set and we have not been able to test this for you. This still gives you the issue of needing to add and remove items when they are added and deleted through the grid. Fortunately you can do this by hooking the BindingList.ListChanged event (after you have done the initial Find). When you receive a ListChanged event of type ItemAdded, call m_Work.Add on the new item; when you receive a ListChanged event of type ItemDeleted, call m_Work.Remove on the deleted item. In this way the unit of work remains in sync with the UI and the items will get inserted into or deleted from the database when you save changes. Finally, you say that you can't edit the Member row. This is a bit surprising because I would expect the grid to be happy to work on an in-memory instance regardless of what kind of list it's in. Could you say a bit more about the behaviour? Does the grid refuse to let you modify the cell contents, or do you get an exception if you try, or does it let you edit the cell contents but the changes don't get saved? Thanks! |
|
|
Dear Ivan- Thank you very much for your reply, I appreciate your time. I have done as you suggested and the Infragistics UltraGrid does play much nicer with a BindingList. There is a lot of plumbing to hook up with the events as you suggested and I will work further on that. Thank you for the direction. I erred before - I did not receive an exception, rather the message "Unable to add a new row. Underlying DataSource does not support adding new rows." This was because of List rather than BindingList or something simply "bigger". The second thing your reply did for me was to scratch the surface of the sheer amount of things I _DONT_ know and I very much appreciate that too :) This old guy has lots to learn. We have a few small applications - 30 database tables for the smallest 300 for the largest - which are entirely based on classes that extend DataTable to which WinForms (and Infragistics) controls all bind quite nicely through the WinForm DataSource and DataMember properties. Unfortunately, we also find ourselves fighting our own creations, hence our looking into products such as LightSpeed to migrate our applications IN to. I know this question is slightly off-topic for this thread, and rather vague to begin with :) but I am hoping you might point me in a direction that would facilitate our moving from our DataTable Windows-style binding to LightSpeed-style data binding? In other words, "I used to have a DataTable, now I have an IList, need to allow users to edit the IList in TextBoxes/Combos/Grids/CheckBoxes/etc". Once again, thank you for spending your valuable time. I look forward to working with LightSpeed and implementing it into our projects. Regards, Robert |
|
|
In terms of migrating DataTable-style bindings to object bindings, a lot of this should Just Work, because LightSpeed implements the necessary interfaces for Windows Forms data binding. For example, you can bind a TextBox's Text property to a string property of a LightSpeed object either programmatically: textBox1.DataBindings.Add("Text", someObject, "Title"); or using the Windows Forms data binding designer, by setting up an appropriate BindingSource / object data source and pointing it at the LightSpeed entity type. These, I believe, are exactly the same ways you would set up a binding to a DataTable-based source. A ListBox, like a grid, can take a LightSpeed-based IBindingList as its DataSource. LightSpeed entities implement IEditableObject so the usual patterns relating to cancellation and committal of edits apply. Similarly, LightSpeed collections implement IBindingList so the Windows Forms currency manager handles synchronisation of master-detail views automatically. (See http://www.mindscape.co.nz/forums/Thread.aspx?ThreadID=1536 for a very quick example of setting up master-detail and parent-child views.) That said, there are probably some areas where there are differences. I'm not sufficiently familiar with the ins and outs of DataTables to be exactly sure. My suspicion is that there may be differences with the way DataRows handle edits (versioning) and the way IEditableObject handles edits (EndEdit/CancelEdit); that said, much of WinForms 2.0 data binding was meant to abstract away such differences so you may not have too many problems. Also, with grids you may have a bit of porting to do to tweak the displayed columns. For example, in LightSpeed, every entity has Id, HasError, IsValid and Errors properties. You probably don't want to show these in a grid. Similarly, an entity involved in a relationship will have association properties (e.g. a Children collection or a ParentId / Parent pair). You will want to consider how to show these (e.g. you probably don't want to show both Parent and ParentId, and the default display for Parent or Children probably wouldn't be very helpful). Due to lack of experience with WinForms data binding and grid controls, I am not sure what the best way to tackle this is -- manually customising the grid columns, using a custom type descriptor, etc. -- but I am sure you have come across similar issues with some of your DataTable-based types so hopefully you will be able to bring your existing solutions across. As a final observation, however, you commented that "we also find ourselves fighting our own creations." I don't know the nature of these battles, but this does imply to me that you may want to be cautious about trying to translate too directly from your existing designs to an ORM-based design. For example, rather than thinking "How can we bind our controls to ORM-based entities instead of DataRows," you may want to be looking at whether a more significant redesign such as implementing a MVC or MVP pattern is also going to be necessary to bring your creations to heel. This of course depends very much on where your pain points are -- I'm not trying to steer you, just mentioning a caveat. |
|
|
Ivan- I very much appreciate all the time you've taken with my questions. Thank you VERY MUCH for your professionalism in helping me to evaluate our move to a better architecture and a better way to create software products through LightSpeed. As I work through this, I'll post back any Infragistics-specific items to this thread. Best Regards and thank you again Ivan Robert |
|
|
Hi- For any Infragistics users, I'll add our experiences to this thread... When using an UltraGrid, and displaying any 'child tables'... for example an Orders entity which has a 'parent' entity of Customer, we need to set the UltraGrid Maximum bands to 1. NOT doing so sends the entities into a perpetual loop (as should be expected since the UltraGrid sort of 'recurses' through all related entities. To date, we've not seen any infragistics-specifics oddities beyond that. I hope this is useful to someone. Regards,
|
|
|
Thanks for the feedback and thoughtfulness of your response Lionel. John-Daniel Trask |
|