But our requirement is to have it in a dropdown list box. So can you help?

You need to push back on those requirements and explain that a DDLB is for static values, and a DDDW is the proper solution if you need to add values.  Users would not see any difference between the 2.  The requirement should be to have a dropdown that displays valid values.  Business should not be dictating whether to use a listbox or dw, that's your job.  Same thing with my wife.  You can tell me to do something and what needs to be done, but don't tell me how to do it, lol!  The problem is also about storing valid values and maintenance.  Sounds like these values should be stored in a code table that can be modified, although again, you haven't really explained what's going on, so it's hard to say.

A DataWindow with a DDLB looks exactly like a DDDW. The person writing the requirements obviously has no idea what the difference is so just implement it using a DDDW and they will not know the difference.

Honestly we need to know more about what is going on here to be able to answer.  Need to know what the values are, why they are changing, when they are changing, and where/how the new values are obtained.  You can't really just add an item every time the user clicks the dropdown.  You'd have to check all of the values every time to see if the new value is already there, or else you're just going to keep adding the same value every time you click the dropdown.  Again, this is why you use a dddw from a code table for values that will change.  Just my $.02

pbm_cbndropdown: That´s a great tip Chris! I´m going to apply it to w_filterSimple of the pfc's.



(I've made it possible to use the filter window with datawindows which have a stored procedure as a data source, but population can be slow, as I'm simply reading all different values from the column on the source datawindow. The use of this event will make it possible for a user to not populate and simply type what he/she wants to filter on.)

Hi Miguel;



      I have had such extra events in my frameworks for over a decade now. Changing your DDLB / DDDW approach as to when the data list gets populated can really save your App's a ton of over-head (thus negative performance). Especially, when these are nested in a plethora of Tab Pages too. Changing your approach to program design like this for subordinate data, can really help your data instantiation times.



    Remember too when you do have to go after a large result set to ...



a) provide some entertainment value to the user (ie: progress bar)



b) pop-up a physiologically challenging message (ie: checking security - who would argue on that one - LOL) 



c) cache high activity DDLB / DDDW datum in data stores for later access by various other DDLB's and/or DWO's.



Enjoy!



Regards ... Chris