[Progress Communities] [Progress OpenEdge ABL] Forum Post: RE: Using Progress.Data.BindingSource for non-GUI Purposes (on Windows)

Status
Not open for further replies.
D

dbeavon

Guest
>>The ProBindingSource is meant to get data from an ABL table and make it available to .NET, not the other way around - i.e., read data from .NET and copy it into an ABL table. Doesn't it allow users to edit and add data? I think that is the intended purpose, right? Moving data programmatically back into ABL is not the intended purpose but I suspect it would work as long as it is possible from "GUI for .Net". If a user can enter data into a .Net control and send it back to an ABL table, then that should be possible to do it programmatically as well. This approach would only appeal to me if the technology performed better than parsing lots of text (ie. XML or JSON). >> No you should not use the Progress.Data.DataSource directly. This could change at any time and is not meant to be used by ABL programmers I can see your point. But the DataSource class was public and it was implementing some pretty powerful (and familiar) interfaces like IBindingList so I was hoping it wouldn't be totally off-limits. I was digging into ProBindingSource to see where the magic happens. Then I found DataSource so I thought I'd ask. It would have made sense to use that, rather than place a PASOE dependency on classes within System.Windows.Forms. >> Avoid classes like System.Windows.Forms? Yes, In a .Net app if I put a dependency on (System.Windows.Forms.)BindingSource it loads System.Windows.Forms.dll which is a user-interface library (and a winforms one at that). It would seem odd to me to place a dependency on winforms if my code is running within a PASOE msagent. But in contrast, your DataSource class does *not* contain any major user-interface dependencies. It is based on interfaces from System.ComponentModel which is found in the System.dll. For reference sake, below is the simplified public interface of that class. It will compile successfully without any assembly reference to System.Windows.Forms.dll. using System; using System.Collections; using System.ComponentModel; public class DataSource : ITypedList, IBindingList, ICancelAddNew ... As I mentioned before, it seems odd to me that I would ever place a dependency on winforms if my code is running in PASOE. There should be a separation of concerns. And PASOE would never be concerned with presenting a winforms user interface. But placing a dependency on the System.dll doesn't bother me at all. >> Why are you worried about the size of the NetUI.dll assembly? I'm not. I'm mainly concerned about the size of the customer base that uses the assembly, and also I'm concerned about the size of data that I need to convert from the .Net side of things back into ABL. Given that we don't use "GUI for .Net", I wouldn't have known about the ProBindingSource option except for the fact that it came up in a prior topic that is related to what I'm doing : community.progress.com/.../1231 FYI, I can see you have previously cautioned people against using ProBindingSource for moving data programmatically, but it is not clear why. community.progress.com/.../23978 At a high level I suspect the ProBindingSource is a bad fit for use within PASOE. But ideally there would be a similar API that could be used for quickly transferring data back and forth across the CLR bridge. I was hoping to find something useful under the covers of the ProBindingSource (something that I could use in PASOE as well).

Continue reading...
 
Status
Not open for further replies.
Top