From sample code we've gotten from customers (e.g., from reported bugs), it seems that a lot of people are using the ProBindingSource (Progress.Data.BindingSource) "incorrectly", meaning in an inefficient manner and in a way that we did not intend. So I thought I would start here to try and educate and correct some misconceptions. Note that there is also extensive documentation on this in the GUI for .NET Programming book. There is a whole chapter on it called "Binding ABL Data to .NET Controls".
I've attached a file with my thoughts. I'd love to here what y'all think about this.
Cheers.
[View:~/cfs-file.ashx/__key/communityserver-discussions-components-files/19/BindingSourceUsage.rtf:550:0]
stern schrieb:
I'd love to here what y'all think about this.
Excellent write up! I've seen exactly the same things when working with customers (only new customers, of course ), sometimes because they were just trying out or they were expecting a certain behavior from previous .NET experience.
I'd make the dependency between the BindingSource and the query's result list even more clear!
Another thing I'd mention would be how to "empty a grid" bound to a ProBindingSource. Closing the query causes bad errors, so I'd rather open the query FOR EACH eCustomer WHERE ROWID (eCustomer) = TO-ROWID ('0x0') or FOR EACH eCustomer WHERE ROWID (eCustomer) = ?
Then add this document to the product documentation in a very, very, prominent location, all training material one of Progress Software's blogs and of course the new knowledge base, hoping that one day we'll all love the new system and will find what we are searching there. Not sure, if Larry will release a TechEdge newsletter any soon.
Thanks for the suggestions Mike.
Not exactly the scope of this initiative here: But add a word of warning about very strict version dependency between the developer and end user - both for source and r-code: Developers shouldn't be using a newer service pack than end users, IOW, end users should be updated with service packs as frequently as the developers does.
In 10.2B03 Progress added the MapNullToEmptyString propery to the BindingSource.
In 10.2B05 Progress added the UseFullFieldNames property to the BindingSource.
(and I'm glad to have both)
Other properties have been added in SP's to the Progress.Windows.Form
So when the developer references any of those new properties in his source, end users need to be on a close service pack level.
In the R-Code the Infragistics Version numbers (and Progress.NetUI.dll version numbers) are contained. Progress takes care of upgrading the end user to a higher service pack than the R-Code was created with thru the prowin32.exe.config file (assembly probing). However, I've seen a lot of surprised developers that tried the other way round: They were on a recent service pack and send individual r-code files to an end user on a lower service pack level (including no service pack at all) as a hot fix and got into huge trouble...
I tried to explain those dependencies on
and
In the past we've had pretty relaxed version dependencies on the R-Code, now we also have service pack level dependencies.
Per Laura, I made a small modification to the last paragraph of her document. When CREATE-RESULT-LIST-ENTRY is used to add a row directly to a query result set instead of reopening the query, RefreshAll() must be called on the binding source to synchronize it to the query. This step has to be done whether AutoSync is true or false.
[View:~/cfs-file.ashx/__key/communityserver-discussions-components-files/19/BindingSourceUsage2.rtf:550:0]
Thanks for the posting the paper, Laura!
Haven't had the time to read this and will not have until tomorrow, but I am just wondering if it is covering performanceissues?
Today we discovered a bug, that when fixed cuts 20 secs of startup time for our program, making it start instantly, that narrows down to how we defined our bindingsource.
We have inherited the ultrawingrid and assigned a bindingsource to a variable called tBS, we then do a
THIS-OBJECT:DataSource = tBS.
Which we narrowed down the 20 sec to. It seems it copies all of the rows in tBS as well (in which we have loaded some thousand rows previously), which makes it really really slow.
We fixed this by creating and initializing the grids before loading data from appserver to our temptables. (Actually, will be fixing, we have made lots of tests to make sure this is the actual bug by manipulating our system).
Is it really neccessary to copy whole rows? Shouldnt they be in the ultrawingrid, while the data to create the rows (temptable/query-handles etc) be in the datasource, which should give almost 0 overhead compared to this?
Thanks in advance!