Pass parametiers to a dialog

[John Tate]

Is there a way to pass a parameter from one dialog to another? For example, I have a dialog1 with a list box where I select a customer. I have in the past stored the customer ID in a global variable, then in the dialog2, to edit the customer information, for example, I use that variable to retrieve the customer's info.
Is there a way to get around using the global variable?

I was thinking of having a text box beyond the boundaries of the next dialog2, and place the needed variable in it - it would not show, but be available for the dialog2 to extract. That would still take a global variable to get the info into the text box - the gHldg of the dialog2.

Is there another way?

Thanks for any suggestion,

John Tate

[Michael Mattias]

You don't "pass" parameters from one dialog to another dialog, you pass parameters to a procedure (SUB or FUNCTION).

If you are talking about a FUNCTION which CREATES a new dialog, then you can pass the parameter to that function.

From that new function (which is creating a new dialog/widnow) f you want to pass a value you can process in the new dialog on WM_INITDIALOG, you can use DialogBoxParam/ CreateDialogParam or DIALOG SET USER...

Note that you could pass the window handle to the (old) dialog, and get the value from the listbox in the new dialog/window. That is, you don't have to save the value of the selected customer: when you get to the new window, you can ask the old window what is currently selected.

Exact coding technique varies depending if you are using SDK or DDT coding methods. (not shown)

[Peter Lameijn]

If it's just a simple parameter, you can pass it throug a custom windows message, and use wParam or lParam as parameter...

[John Tate]

Thanks, Michael and Peter.

I am off and running on my new project. I will pass the needed parameters to the "function" that creates my dialog. I will try both passing the handle of the calling dialog, as well as the ID number or record number as needed.

I have gone to all kinds of gyrations in the past, using global variables to get the needed record number or whatever to the called dialog. The program works well (the customer likes it), but in the future, I can make my coding much more streamlined.

Thanks again,

John Tate

[John Tate]

I am still missing something. I can use the passed record number in the called dialog, but I need that record number for further use in the callback function.
How can I get the passed parameter to the callback function? The callback does not allow parameters.

John Tate

[David Roberts]

Dialog Set/get User

[Richard Angell]

The DIALOG GET/SET USER is useful for one to 8 parameters. However you can also use SetWindowLong/GetWindowLong for parameter passing as well. MCM recently discussed that in another thread, and in the near past there was a discussion about actually setting the length of the Windows storage area and passing parameters with other API's ... when the parameter was longer than 32 bits. I'll see if I can dig that thread up later.

[Richard Angell]

OK, This is what I had in mind as even another alternative with Get/SetWindowLong. It involves the "Extra Window Memory" (see topic in win32.hlp that comes with PB) and is concerend witth the 40 bytes of cbWndExtra. But as has been pointed out PB provides many different ways to make variables/values available to you in other functions. In a CALLBACK you will need to retrieve from a known location such as those mentioned here, or use a GLOBAL. When using the locations menioned in this thread, often you might be passing a pointer to the variable's data, or for dynamic strings to the string handle.

Search on cbWndExtra and you will find a fair amount of threads witth mention and/or examples.

http://www.powerbasic.com/support/pbforums/showthread.php?t=35036&highlight=cbWndExtra

[John Tate]

Thanks to all.
I now understand dialog set user and dialog get user. I have my program working as I wanted without using global variables to store the record number and the handle of the calling dialog. It is clean and neat!

I see that each control on the dialog also has 8 "storage bins". They also can be used to store the same information. Wow!

I think I need to study the manual some more. My old brain has had a short circuit concerning set and get user statements!

Thanks again, Michael, Peter, and Richard.

John Tate

[Michael Mattias]

When you need data which is greater than 32 bits but all you have in which to store it is an integer, you can always save a pointer or handle.

If you are not comfy allocating your own memory you can always use a dynamic string...

FUNCTION F1 () 
 [b]STATIC[/b] myString AS STRING 
 LOCAL pStr AS STRING PTR 
 LOCAL Param AS LONG

 ...
 MyString = UdtToString(UDT) & MKLS$(LongInteger) 
 param    = VARPTR (myString
 CALL         F2 (param) 
...
FUNCTION F2 (BYVAL param AS  STRING PTR) ...

   LOCAL myString AS STRING, UDT AS MyUDT, myLong AS LONG

   MyString = @param

   TYPE SET UDT = LEFT$(myString, SIZEOF(UDT) 
   MyLong           = PEEKL(STRPTR(MyString)+ SIZEOF(UDT))

....

Although personally I'd allocate my own memory: malloc, realloc, free for PB/Win32 September 20, 2002