Address of data being modified by a control

Bill

Here is a new set of DLLs for you to try....

https://www.dropbox.com/s/9wl57uvg1ct9hp8/newDLLs28.zip?dl=0

Paul,

YEAH! This works well. Thank you!

One note: The way I constructed my winio@() calls, except for the first one, used %ob to force formatting. The %ud was then AFTER the %cb. What this did was attach the User Data to the %cb (maybe?).

I restructured my winio@() calls to place the %cb after the %ud, and all is now well.

Just a programming note perhaps for the on-line help.

Again, many thanks. Bill

Thanks Bill. I can probably fix the problem with %ob/%cb in the ClearWin+ coding.

Thanks, Paul!

I just wanted to give an update on the use and utility of %ud.

I have a selection that consists of a list select that identifies the category of the data the user can select, then a list view of the data already existing for that category. The functions provided allow for selection of a data item from the list view (fills in specific data into the calling program), edit one or more existing items in the list view, delete one or more existing items in the list view, and add a new item to the current category. It is one of the more complicated sets of controls because there is a generalized ENABLE for the functionality as well as allowing only the data fields for the selected category to be enabled via the list select. Also, the list view can sort on the individual data fields to provide the user with greater functionality. Unfortunately, I have to cobble together a wrapper for applying these data functions to different data, compounding the debugging process.

The old code used labeled COMMON extensively to pass back and forth the various grey controls, data items, etc. And it was limited to only labeled COMMON. 895 lines of code. Getting the code to act only a different set of data required an entirely new set of interface and callback routines.

Using the %ud, I have been able to recreate all that functionality in 733 lines of code. Not much of a reduction really. But, it is much cleaner, more easily read (and debugged). And here is the best part, I am no longer constrained by the code to ask for one set of data that gets stored in one location. I can define a TYPE and its elements to point to whatever target data I need to populate. It is almost as if this complex set of data controls is now acting as a single control, driven by the TYPE associated with the control(s).

So, Paul and the folks at Silverfrost, thanks for providing such a useful new feature. It has and will save me countless hours of debugging time.

Bill

I can't see why %ud is not working correctly relative to %cb.

If you want to post a sample that illustrates the failure then I might be able to fix it.

Paul, I'll try to construct something that is simple. It was so long ago, I've forgotten what module it was in! It will likely be a few to several days (unless the grandchildren stay asleep a while longer!).

Bill

Well, I cannot replicate the issue either with a %rd or a %ls control followed by the %ud either before or after a %cb. Until I have something else to confirm, I think you can take it off of your list.

Bill