Thanks Chris,

I tried changing the focus as suggested but it didn't work.  I find that I just can't get the ItemChanged event to give me the latest value with a GetItemXXX.  It always returns the previous, original value as the buffer hasn't been updated.

Doing two linked dddws is a snap since the <Data> variable holds the value of the key chosen from the first dddw and can be used to retrieve the correct data for the second dddw.  Of course, you know all this.

Its trying to get the value from the 2nd dddw to use for the 3rd that's the problem.  Posting an event or changing column focus doesn't work regardless of Retrieve or Filter.

Is there no way to get the key from the 2nd dddw?  I've got about 3 days into this and am stymied.

Hi James;

  FYI ... The other way to approach the issue is not using the ItemChanged event but the DDDW Closed event (which I normally use).

  Here is how this approach works.

1) Declare a User event on the DC and map this to "pbm_dwCloseddropdown" event ID.

2) On the UE from Step #1, code for example ...

  The result will be ...

Food for thought. Also, now you're Apps will always know when the DDDW collapsed.  ;-)

Regards ... Chris

I've tried all the various permutations I can think of.    Whichever column is changed by the ItemChanged code, the correct key is chosen but the display value will never show until the user actually clicks on the DDDW column.

• I'm using a retrieve method, sending a variable to the SQL for the DDDWs. 
• I've tried the get/set on the key value after the retrieve in the ItemChanged event, no luck. I also tried setting focus on the column but again, no luck. 
• Doing a describe / evaluate on the column results in returning the key value, not the display value.

It appears that the code to swap the display for the key value in the DDDW only fires when someone clicks on the column.  Makes sense, but not here.

I'm wondering whether filtering would work rather than retrieving.  It seems like it could be a lot to filter at some point, but I could try it.

Thanks Michael.

The code I have works except for...

Of the 3 dddw, Vendor, Make, Model, changing vendor will change the available makes (selecting for that vendor), and changing the Make will similarly change the list of available Models for that Make - Vendor.  I get the right result, but the display value of the dddws shows the key initially.  When I click on the key (number), then the appropriate text displays in the dddw.  I'm doing this from the ItemChanged event in a Tabpage.

I tried posting an event from the itemchanged but PB doesn't like it.  The Boolean result is 'False' and the event won't trigger.  The same posting code works if I put it in a different object, like the window.

So the data is correct but the display lags for some reason.

Hey James,

Chris refers to how you can obtain DISPLAY value related to CURRENT DATA value in an item = <row, column>.
NOTE: In ItemChanged that code would obtain display value for OLD data value. Reason why ItemChanged has triggered is that the OLD value is most probably replaced by a NEW value - and your code probably wants to work on the NEW value. ==> So, it's complicated!

During ItemChanged new value hasn't reached the DW buffer yet, so any GetItemXxx stuff still refer to former value in current item = current <row, column>.

When some function (same for event) reads data from DW buffers it only works within ItemChanged if you do explicit SetItem before calling that function.

When you have AllowEdit = true you have to handle case where user entered DISPLAY value instead of DATA value. Typically, use dddw.Find to check for data value. If not found, do dddw.Find to check for display value on the display column. That is the order that DW engine's internal logic uses.

This kind of logic you probably want to write generic and encapsulate in ancestor class because it quickly becomes complex and repetitious. Remember display value's datatype may differ from data value's datatype -and- data parameter itself in ItemChanged is string whereas data column in buffer quite often is numeric!

I found the easiest way to resolve this is to POST whatever consequential action from ItemChanged to ensure data arrived safely in DW buffer before acting on it. Quite often that POST solves the issue. Other times, you have to handle all validation + conversions in-flight ==> complex data/display lookup + datatype conversions.

NOTE: PFC's logic for DDDW handling during ItemChanged has most of the code you probably need. So may the framework your app is already using. Even if your app uses different framework the PFC framework's DDDW handling may inspire you.

HTH /Michael

Hi James;

  On the ItemChanged event, use the following ...

ls_display = dw_1.describe("evaluate(l'ookupdisplay(column)',row)")

HTH

Regards ... Chris