Sharing a proBindingSource

I have an ABL form that contains a proBindingSource

and an UltraGrid. I can review records, sort, search,

etc. and all is working fine. What I would like to do

is when the user double clicks on a record open

another ABL form that will be used for the actual

maintennace. I have created the maintenance ABL form

and dropped a proBindingSource and an

UltraNumericEditor.

In my code to open the department maintenance screen

I use the following:

NEW DeptMaint(bindingSource1:HANDLE).

When I double click the first record is always

displayed on the maintennace screen. How do I get the

proper record to be displayed? Can these two forms

share the same proBindingSource?

You're passing the binding source's data source around - the ProDataSet or buffer or whatever - and not the binding source itself. The PBS maintains currency, not the data source, and so the new PBS will have its own currency and so that starts at the first row.

You could pass a/the key in of the currently-selected record and reposition the datasource.

Or you could use the original binding source on the maintenance screen (instead of creating a new one). I've attached a very rough example of this using Sports2000.

[View:~/cfs-file.ashx/__key/communityserver-discussions-components-files/19/childform.cls:550:0]

[View:~/cfs-file.ashx/__key/communityserver-discussions-components-files/19/childform.resx:550:0]

[View:~/cfs-file.ashx/__key/communityserver-discussions-components-files/19/parentform.cls:550:0]

[View:~/cfs-file.ashx/__key/communityserver-discussions-components-files/19/parentform.resx:550:0]

-- peter

Okay, let me give it a shot.

Thanks for the reply.

Okay, that seems to work just fine. Thanks.

I do have another question. On some of our screesn today we have many widgets such as combo-box and selection-list that are populated from different tables. Should we drop a PBS for each control?

Okay, that seems to work just fine. Thanks.

np

I do have another question. On some of our screesn

today we have many widgets such as combo-box and

selection-list that are populated from different

tables. Should we drop a PBS for each control?

I assume you mean a PBS for each 'extended' control, like the Combo or Selection list.

You'll need a PBS for each of those. This will allow the independent navigation of those controls without affecting the 'main' view of the data.

You can use the same data source for all those PBS', especially if you're using a ProDataSet.

So if you've got a ProDataSet with Customer, Order, Orderline, Salesrep, Item, you can have one PBS on Salesrep for a combo, one PBS on Item for a popup lookup grid, one PBS on Customer for a grid and one PBS on Order for a bunch of editor controls, all getting their data from that one ProDataSet.

Obviously, this all depends on what the data source is of all those PBS'. And is a whole topic on its own ....

-- peter

Thanks Peter.

Peter,

Another question on the PBS for the 'extended' controls. I have a table in my database where we store options for different table records and associated values. These are hard coded and cannot be changed by the end user and are used to populate a combo-box, selection-list, radio-set, etc. It is possible that many controls on the same form will reference this table with each having a different subset of data.

For example,

This table is called CodeDef and I would need to extract the following records from the database for a particular file maintenance screen.

The following records will be used to populate a selection-list replacement (not sure what control yet) to allow the user to select what department options to enable.

"dept opt" 1 "Commission Items" 1 0 "1"

"dept opt" 2 "Food Stamp Items" 2 0 "2"

"dept opt" 3 "Non-Add Daily Sales" 3 0 "3"

"dept opt" 4 "Subtracting Dept" 4 0 "4"

"dept opt" 5 "Password Required" 5 0 "5"

"dept opt" 6 "Allow Neg Accumulation" 6 0 "6"

"dept opt" 7 "Requires Package Codes" 7 0 "7"

"dept opt" 8 "Data Entry Compulsion" 8 0 "8"

"dept opt" 9 "Validation Compulse" 9 0 "9"

"dept opt" 10 "TagPro Color Prompt" 10 0 "10"

"dept opt" 11 "TagPro Size Prompt" 11 0 "11"

"dept opt" 12 "Subdepartment Key Pricing" 12 0 "12"

"dept opt" 13 "Gift Card Activation" 13 0 "13"

"dept opt" 18 "TagPro Discountable" 18 0 "18"

"dept opt" 19 "Gift Card Recharge" 19 0 "19"

"dept opt" 20 "Significant Department" 20 0 "20"

The following records will be used to populate a selection-list replacement (not sure what control yet) to allow the user to select what tax itemizers to enable.

"tax" 1 "Default Tax" 1 5 "1"

"tax" 2 "Tax Itemizer 2" 2 3 "2"

"tax" 3 "Tax Itemizer 3" 3 1.5 "3"

"tax" 4 "Tax Itemizer 4" 4 .75 "4"

The following records will be used to populate a selection-list replacement (not sure what control yet) to allow the user to select what discount itemizers to enable.

"discount" 1 "Discount Itemizer 1" 1 10 "1"

"discount" 2 "Discount itemizer 2" 2 25 "2"

"discount" 3 "Discount Itemizer 3" 3 40 "3"

"discount" 4 "Discount Itemizer 4" 4 80 "4"

"discount" 5 "Discount Itemizer 5" 5 0 "5"

"discount" 6 "Discount Itemizer 6" 6 0 "6"

"discount" 7 "Discount Itemizer 7" 7 0 "7"

"discount" 8 "Discount Itemizer 8" 8 0 "8"

"discount" 9 "Discount Itemizer 9" 9 0 "9"

So if I populate a prodataset with this data and then use one PBS can I filter the data based on the control?

Am I headed down the wrong path?

If I understand (other) Peter correctly, you can have one ProDataSet but you need a separate PBS for each control (where you want a different view on the data) since the PBS maintains currency. You could even have that ProDataSet reside in a singleton somewhere in your client app.

In other words, you can share the ProDataSet, but not the PBS (so that is the answer to the original thread question).

Message was edited by:

Peter van Dam

Okay, you need a PBS for each control. Thanks.

How would you filter the data in the PBS as to just show a subset of data?

Interesting question.

I suppose you would open a different query for each PBS. So you won't bind to the PDS but to a query. I suspect you would have to create a different buffer on the table for each query as well, but I am not sure.

Thanks for the input.

Looking back at your example, you might also want to split up the table in separate tables (one for each type) when you load the table in to your dataset. So if your database table contains 50 types, it results in 50 tables in your PDS. That would turn your physical model into a logical model and make your queries simpler. The amount of data would remain the same.

However, you would still have to watch for currency when you reference one table multiple times (either within the same screen or from different screens, possible multiple instances of the same screen) so the currency question remains open. Who can enlighten us?

Hmm, I think that is the way to. I am not sure currency would be an issue for me as this table is "read-only" and just used to load values/descriptions into combo's, etc. the values are then stored in a different table.

Thanks for the "insight".

Looking back at your example, you might also want to

split up the table in separate tables (one for each

type) when you load the table in to your dataset. So

if your database table contains 50 types, it results

in 50 tables in your PDS. That would turn your

physical model into a logical model and make your

queries simpler. The amount of data would remain the

same.

However, you would still have to watch for currency

when you reference one table multiple times (either

within the same screen or from different screens,

possible multiple instances of the same screen) so

the currency question remains open. Who can enlighten

us?

You could retrieve the data once (so now you're effectively caching the data), and build ProDataSets on the fly. You can then modify the datasets' TOP-NAV-QUERY PREPARE-STRINGs to do the filtering you need on the client side.

I'm not 100% sure of the impact on currency but

-- peter

So if I populate a prodataset with this data and then

use one PBS can I filter the data based on the

control?

I've done some experimentation with filtering data on the client*. I've attached some files showing this.

There's a DataCache class which contains data in a temp-table. This temp-table is populated (using data from an earlier post) in a static constructor, so there's only 1 instance of the data. It's got a static GetTT() method which returns a buffer handle.

I created a form (form7) with 3 grids and 3 binding sources on it. Each grid has its own binding source. Each binding source binds to a ProDataSet, which is dynamically constructed from the temp-table in the DataCache. The PDS' TOP-NAV-QUERY prepare string is modified to filter on "dept opt", "discount" or "tax". Now each grid show only that data. In order for this to work, I have to use a separate buffer - I can't re-use the default buffer from the temp-table. If I try to re-use the buffer, I get an error, so GetTT() does a CREATE BUFFER FOR ttData.

The form also has a button on it, which shows the current record in the buffer. This is different for each grid - so in other words, each temp-table buffer is pointed at the correct record.

There's also commented-out code showing how to do this with a query, rather than a PDS.

I also tried using 1 binding source for multiple (3) grids, in form8, and filtering the data in the grid rather than the dataset. In this example, you have to manually select the criteria to filter on, but you can certainly do this in code (left as an exercise for the reader :).

In this case, you can only click on one grid at a time. Clicking in another grid results in focus moving to that grid. Pressing the button shows only 1 record - which makes sense, because there's only 1 buffer involved.

Now this make sense in some cases, where you don't really need the buffer to always be in sync (this might be useful where only 1 of the bound UI elements is enabled at a time), but I think that the typical use would be the case(s) presented in form7. And I think that making sure the PDS contains the correctly filtered data is more SOA-y, if you will, since we can roughly equate a PDS with the concept of a Business Entity. Doing this filtering in UI means we can't really reuse that filtering logic elsewhere, and while it's simple in this case, it may not always be.

Note that the ProDataSet (its temp-table buffers actually) maintain data currency (or a cursor); the bindingsource ensures that the UI control and the data are in sync.

-- peter

• For this discussion, I take client to mean the UI client

[View:~/cfs-file.ashx/__key/communityserver-discussions-components-files/19/DataCache.cls:550:0]

[View:~/cfs-file.ashx/__key/communityserver-discussions-components-files/19/form7.cls:550:0]

[View:~/cfs-file.ashx/__key/communityserver-discussions-components-files/19/form7.resx:550:0]

[View:~/cfs-file.ashx/__key/communityserver-discussions-components-files/19/form8.cls:550:0]

[View:~/cfs-file.ashx/__key/communityserver-discussions-components-files/19/form8.resx:550:0]

This sounds like it may be what I need. I will take a look at it this weekend!!

Thanks.

Peter,

If I have a PDS with multiple TT and I create a xsd file should I not be able to import that into a PDS and see all the TT?

If I have a PDS with multiple TT and I create a xsd

file should I not be able to import that into a PDS

and see all the TT?

If the PDS has more than one top-level table, only the first one will be used.

If you have multiple top-level tables, you can generate an XSD from a temp-table and use that instead.

-- peter

Okay, thanks.