1. David Vasconcelos
  2. PowerBuilder
  3. Tuesday, 30 October 2018 11:29 AM UTC

I would like to get some ideas on how others are handling the following situation, I am sure many have dealt with this.

You have a drop down datawindow that displays codes, the drop down has the code value and its description.  The code value is what is saved to the database and the description is what the user sees on the screen.  The codes also have an active/inactive flag used for indicating if the code is valid/invalid or used/no longer used.  In the parent datawindow ideally you would like to display the description regardless if it is active or not which means on the dddw side all codes would need to be retrieved. (If its not retrieved then the code value and not the description is what shows on the parent datawindow) The issue is when a user changes the code they should only be able to select "active" codes OR the current code (regardless if it was Active/In Active) that was originally retrieved in case they changed the code and need to revert back to the original one.  Ideally it would be great to see only "active" codes and the original code in the DDDW.  I know there are several ways to achieve this but what would be the simplest solution without a lot of coding and make it automated so that it can be part of some inheritance so that your not coding for every dddw situation.

I would like to here how people have come up with solutions to this issue.

Thanks for everyone's time and looking forward to seeing different ideas.

Dave V.

Adding an additional issue.  The parent datawindow may display 1 to many rows so that if you retrieve/filter for a row it may effect what is displayed on the other rows.

Matthew Balent Accepted Answer Pending Moderation
  1. Tuesday, 30 October 2018 11:55 AM UTC
  2. PowerBuilder
  3. # 1

I would structure the WHERE clause in the SQL which retrieves the code like this:

 

WHERE activeCode = 'Y' OR codeId = :xyz

 

Where the parameter 'xyz' is the code value on the record you are displaying.

alternatively you can retrieve all rows and then apply a filter like the 'WHERE' clause above.

Comment
There are no comments made yet.
René Ullrich Accepted Answer Pending Moderation
  1. Tuesday, 30 October 2018 12:47 PM UTC
  2. PowerBuilder
  3. # 2

You may insert two column objects for the same column in the datawindow:

One column make visible for the current row. Show here only values that are valid for selection. You have to change the list if the current row changes, so you need a little bit coding. You could retrieve as Matthew suggested or you may simple use a filter.

One column make visible for rows that are not the current row. Use a DDDW that contains all values. So you can always see description even if you filter the DDDW of the other column.

 

Comment
There are no comments made yet.
Chris Pollach @Appeon Accepted Answer Pending Moderation
  1. Tuesday, 30 October 2018 13:29 PM UTC
  2. PowerBuilder
  3. # 3

Hi David;

    Yes, this seems easy but it can be a bit interesting from the historical reporting perspective. That is, you often need to older deprecated values so that the column information displays correct, yet in update mode - you need to restrict what the user sees selection wise.

   To make sure that the users see the current value (regardless of its status) just let the AutoRetrieve feature handle the DDDW value set with no restrictions. This will allow older assigned codes to display correctly. However, when the user wants to change a DDDW value you need to only show them the active codes. Here is what I do in this case ...

  1. Add a DDDW "drop" and "Close" event to the DC
  2. On the "Drop" - use  a GetChild() command to get a reference to the DDDW
  3. Now filter the DDDW result set to display only the "active" codes
  4. On the DDDW "Close" event, remove the filter

With the above approach you can now handle historical code display and active code assignment to the column in question.

HTH

Regards ... Chris

 

 

Comment
  1. Chris Pollach @Appeon
  2. Thursday, 29 November 2018 20:38 PM UTC
PS: My framework change to fire the DDDW's close event is also working in PowerServer Web as well! :-)
  1. Helpful
  1. David Vasconcelos
  2. Friday, 7 December 2018 14:15 PM UTC
Good news, Chris and Thanks. If Possible can you post your change so can steel I meant copy it? Dave V.
  1. Helpful
  1. Chris Pollach @Appeon
  2. Friday, 7 December 2018 15:37 PM UTC
David;

I just uploaded the latest "beta" version of the framework to SourceForge attached to the example OrderEntry App. The DDDW fixes are included in the Integrated Framework that is attached to the example OrderEntry application. You can download the OE example with the DDDW event fixes from here ...

https://sourceforge.net/projects/stdfndclass/files/Applications/PowerBuilder/OrderEntry/Beta/

Borrow away - enjoy - LOL!

Regards ... Chris
  1. Helpful
There are no comments made yet.
David Vasconcelos Accepted Answer Pending Moderation
  1. Tuesday, 30 October 2018 13:38 PM UTC
  2. PowerBuilder
  3. # 4

Chris those would handle the "dropping down' of the dddw but how do you handle the use of scrolling using the keyboard?  Would you also create a key event and prevent it?

Comment
  1. Chris Pollach @Appeon
  2. Tuesday, 30 October 2018 13:44 PM UTC
Hi David;

No, even if you use the keyboard, the DDDW "Drop" & "Close" events are fired the same as the mouse initiated ones. Therefore, you have the same PowerScript control.

Regards ... Chris
  1. Helpful
There are no comments made yet.
Chris Pollach @Appeon Accepted Answer Pending Moderation
  1. Tuesday, 30 October 2018 13:57 PM UTC
  2. PowerBuilder
  3. # 5

    I was thinking that the column would be protected and thus no updating for users that have display only authorization or where the data is "historical" only and thus logically "locked" from updating. For an example, a PO that has been processed and thus the data is "historical" only.

    Where the data represents an active business transaction and can still be modified, allowing the user to have the DDDW "Drop" and then scroll through the values would not be an issue IMHO. However, I have also seen the case where certain subsets of the DDDW result set are applicable based on the state of the business transaction or context of the surrounding data. Thus a second filtering may be required to further restrict what the user sees (or scrolls through) when the DDDW "Drop" occurs.

HTH

Comment
There are no comments made yet.
Olan Knight Accepted Answer Pending Moderation
  1. Tuesday, 30 October 2018 14:46 PM UTC
  2. PowerBuilder
  3. # 6

A simple answer would be to examine the ACTIVE flag in the selected row of the DDDW.
If the value is ACTIVE, proceed as normal.
If the value is INACTIVE, display an error message and do NOT proceed as normal.

Olan

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.