Subscribe via RSS
Toggle Submenu
  1. Categories
  2. Recent
  3. Tags
View Replies (3)

Resolved Datawindow with multiple rows & DDDW Issue

  1. How-to
0
Votes
Undo
  1. Michael Quintus
    Michael Quintus
  2. PowerBuilder
  3. Thursday, 11 July 2024 15:57 PM UTC

Okay, hopefully I can explain this correct enough that it makes sense.

 

TL/DR: Datawindow with multiple rows doesn't always show the DisplayColumn because of the where clause in the DDDW query.

We have a datawindow that returns multiple rows. In each of those rows has a dddw that needs to be filtered based on that row. The relationship to the dropdown is based on an ID field in the datawindow query, while the filter is based on a separate ID field.

Originally we had it set up so AutoRetrieve was off and the dddw query was retrieved on the rowfocuschanged event. This worked great, but I wanted to change the display value to a description rather than the ID. After doing so the dddw doesn't have the necessary values retrieved so the DataColumn would display rather than the DisplayColumn. Changing the row updates that rows dddw, so then the display works correctly when it's focused, but the other rows that lose focus don't display correctly.

Setup:

Window -> Datawindow (multiple rows) -> dddw for each row

DDDW filtered by ID1 but uses ID2 as the DataColumn.

Things I've tried:

  • 2 dddw that have visibility set to whether the row is focused.
    • This didn't work because users would have to double click on the dropdown for it to expand.
  • pbm_dwndropdown
    • Couldn't get this to trigger.
  • Removing the ID from the where clause of the DDDW and trying to set a filter in the rowfocuschanged event
    • Couldn't figure out how to reset the filter for all rows except the focuses row.

If I could get the entire dataset in the dddw it would be fine and show the DisplayColumn correctly; then I just need to figure out how to correctly filter the drop down when it expands.

  1. DataWindow
  2. PowerBuilder
Clipboard and DragQueryFile - Need DragFinish?
How to set the retrieval argument case sensitive f...
Accepted Answer
John Fauss
John Fauss Accepted Answer Pending Moderation
  1. Saturday, 13 July 2024 01:24 AM UTC
  2. PowerBuilder
  3. # Permalink

Attached please find a single-window example app that illustrates one way to accomplish this. All of the data is self-contained, so no database connection is used.

Here is a snapshot of the window:

By selecting a Color Group, the set of Color Values is filtered. There are two color value selection DDDW's: One that is intended to be filtered by the color group, and the other that is never filtered and thereby always lists all of the color values. These are the two column objects that are shown in mint green. These have a tab order of zero and are included so that you can see the effect that selecting a different color group has on them.

The first color value column object uses the DDDW that gets filtered. The second color value column object uses the DDDW that does NOT get filtered.

The last two color value column objects are nearly identical to the first two, except these have an expression for the "Visible" property ensuring that only the color value column object that is filtered is visible when the current row is displayed. By placing these last two on top of one another and by adding a small amount of code, it will appear to the user that only one color value column is being used.

Please note that all four of the color value column objects shown above relate to a single column definition named "color_value", so when a color value is selected, all four of these column objects reflect the newly-chosen color.

By unchecking the checkbox at the top of the window, you see how this works in practice:

Each of the color value drop-down lists is filtered to show only the colors that belong to the specified color group. Try it and I hope you'll agree that it works well.

To accomplish this, only a small amount of code is required:

  • A simple DW expression in the two color value column objects (previously mentioned).
  • A small window object function (in the example, it is named: of_Set_DDDW_Filter). Less than 40 lines of code, including empty lines and comments for readability.
  • Very small scripts in four DW events:
    • Clicked
    • Constructor
    • ItemChanged
    • RowFocusChanged

I re-discovered this technique on the Schultz's PowerBuilder Notes web site:

    https://pbbraindump.wordpress.com/2008/11/16/the-ol%e2%80%99-hidden-items-in-the-dddw-problem-part-ii/#more-267

This web site is chock full of handy tips and techniques, even though many of the posts are 15+ years old.

HTH. Good luck!

 

Attachments (1)
DDDW_Filtered_Rows.zip
Comment
Michael Quintus
  1. Michael Quintus
  2. Monday, 15 July 2024 13:19 PM UTC
THANK YOU!!!!! The cllicked event in the Datawindow is what I was missing. Thanks for the help John, going to bookmark that site.
  1. Helpful
There are no comments made yet.
Responses (3)
René Ullrich
René Ullrich Accepted Answer Pending Moderation
  1. Friday, 12 July 2024 05:00 AM UTC
  2. PowerBuilder
  3. # 1

 

I think the trick with the two column objects with two different dddws should be the best. One dddw for the current row and one for the other rows. You can use visible expressions for that. The two column objects could be for same selected column (column id) but you can also select the same column two times from DB (in this case you have to write code to copy value if it is changed!).

Another way with some limitation: Instead of filtering the dddw you could use the SetDetailHeight function to make the rows invisible you don't want to show. But If I remember right there is a problem if the user scrolls to the rows in dddw with the arrow keys.

Comment
There are no comments made yet.
John Fauss
John Fauss Accepted Answer Pending Moderation
  1. Friday, 12 July 2024 02:44 AM UTC
  2. PowerBuilder
  3. # 2

Hi, Michael -

This behavior is caused by the filtering of rows in the Drop-Down DataWindow (DDDW) when a value other than the underlying data column is displayed. This has been a limitation of DDDW behavior since... well, forever.

To quickly review: The use of a DDDW facilitates the display of an alternative value (such as a part name, for example) in place of a data value (say, the part ID or part number). Under normal conditions where no rows in the DDDW have been filtered, all of the data-value to display-value mappings are present in the DDDW, so the display value always appears in the "main" DW instead of the underlying data value.

When any rows in the DDDW are filtered (meaning row(s) get moved from the DDDW's primary buffer to the DDDW's Filter buffer), it is then possible that a particular data-value to display-value mapping may no longer be available. If this occurs for a row in the main DW, the only recourse the main DW has is to display the actual data value. This is what you are seeing.

All is not lost or hopeless, however. There is a technique by which you can fake/simulate the data-value to display-value mapping and make it appear to the user that the display values are always visible in the main DW even when the DDDW row is filtered. This technique has been around for a long time. As you can surmise, it's not used very often. I've used this work-around, but it has been a LONG time since I last used it, and I will have to see if I can find and provide you with a working example.

It may be several days before I can do so, therefore, if anyone else in the Community can supply you with a working example that illustrates this technique, I encourage them to do so.

Best regards, John

Comment
There are no comments made yet.
  • Page :
  • 1


There are no replies made for this question yet.
However, you are not allowed to reply to this question.