Passing variables to a callback

[Scott Turchin]

Michael's got me on this thought process to get rid of some globals.

BUT it seems there is no way to pass variables to a call back function...

Would say, reading an INI file in be more appropriate to do when I do my WM_INITDIALOG ??

Say I've got 25 variables I need read in that are user options......

These have to be passed to an OPTIONS screen as well, thus yet ANOTHER callback requires these variables.

I should have asked this question, if I didn't already, about 9 years ago


So far I just use a global LONG integer as a flag, ie g_RunInSystemTray, or g_StartWithWindows etc etc.


Inquiring minds want to know...

[John Petty]

Michael's got me on this thought process to get rid of some globals.

BUT it seems there is no way to pass variables to a call back function...

Have already answered twice what your problem is in the original thread. Can't help you if you cant understand them.

[Michael Mattias]

Say I've got 25 variables I need read in that are user options......
..
These have to be passed to an OPTIONS screen as well, thus yet ANOTHER callback requires these variables.

Twenty-five total options for the user is fine, but needing ALL of them for support function calls tells me simply your support functions are not well-designed - they are too complex.

But even that you can get around: just put all the options into a UDT and now you only have one variable to manage. One variable = one stinking 32-bit integer - its address (pointer).


MCM

[John Petty]

Michael
Surprise I agree with you. In fact when it comes to using threads I seem to remember so does the PB manual.
John

[Richard Angell]

And probably in the original thread (which one?) you explained to Scott to pass the variable in one of the window's (or control's) USER memory slots?

[John Petty]

Rick
Sorry original thread is in the Internet forum and why he is not getting a simple web server to work (actually been a couple of threads there) please feel free to join in add some expertise.
John

[Michael Mattias]

I do believe Mr. Turchin has encountered the quasi-famous "you can pay me now or you can pay me later" rule, applying here to over-reliance on GLOBAL variables.

What was later is now now.

[Conrad Hoffman]

Later may have become now, but rest assured there are still things going on now that will bite me later.

I sometimes go through this "kill all the globals" phase, and am pretty pleased with myself when I succeed. OTOH, sometimes it's fast and convenient to use a few globals, and I can't really see the harm if not carried to excess. IMO, 25 globals isn't excessive.

[Richard Angell]

Ms

Global variables are part of the programming language features, not just in PB BASIC either. It is not a cardinal sin for rational people to use or not use them . it's been a long time, thankfully, since the last no-globals flame wars.

Since we are talking about option settings, using a global UDT variable would be just as nice as: stuffing them into a local UDT, storing the UDT's address in the windows storage area or the DDT accessed DIALOG SET USER slots and then in the dialog retrieving the value to a UDT pointer and accessing thee by pointers.

Me. I might also consider the approach to retrieve the file's values in the CALLBACK or other function since loading/saving 25 values should be a tiny time slice. In that case the file read/save could be it's own function, called from your callbacks, that you pass your local UDT to BYREF

SUB  GetOptions(BYREF UserSets as PgmOptions)
    'open the file in BINARY mode and load the whole UDT
    ... code ...
END SUB

SUB  PutOptions(BYREF UserSets as PgmOptions)
    'open the file in BINARY mode and save the whole UDT
    ... code ...
END SUB

[Dale Yarker]

"Passing variables to a callback"
In the callback make the variable STATIC, send the value via
DIALOG SEND/POST hDlg, %WM_USER + 500, wParam, lParam
putting numeric values in the params. For strings or UDTs put pointers in the params.

Cheers,

[Steven Pringels 3]

Plenty of options..

Create a linked list using the excellent routines of Paul Squires, Michael Mattias or Don Dickinson for that matter. You'll get a pointer variable. That pointer var should be global. Add the values to the linked list and get them whereever you
want.

Using dialogs ? Store the pointer var as user data in the dialog. No globals required.

Many (25) globals ? Make them a UDT and pass the address over.

It's all doable but requires some 'think before you begin'. Something I learned the hard way
\

[jcfuller]

Plenty of options..

Create a linked list using the excellent routines of Paul Squires, Michael Mattias or Don Dickinson for that matter. You'll get a pointer variable. That pointer var should be global. Add the values to the linked list and get them whereever you
want.

Using dialogs ? Store the pointer var as user data in the dialog. No globals required.

Many (25) globals ? Make them a UDT and pass the address over.

It's all doable but requires some 'think before you begin'. Something I learned the hard way
\

If you have 9/5 don't overlook using Class/Instance variables.

James

[Richard Angell]

Ms

It might help if we had an inkling of whether the 25 options were a mix of values and strings ... or 25 T/F settings ... the latter of which could be in one 32bit bit array (DWORD) with some extra bits left over ... How to get the bit array to the callbacks has already been highlighted in the previous posts.

[Michael Mattias]

It's all doable but requires some 'think before you begin'. Something I learned the hard way

I think "the hard way" is how we all learned.

[Michael Mattias]

???

FUCNTION MainFunction 

   LOCAL pUDT AS myudt PTR 
   ...
    GLOBALMEM ALLOC SIZEOF(myUDT) TO hMem
    DIALOG SET USER hdlg, 1 , hMem
    GLOBALMEM LOCK hMem TO pUDT
    @pUDT.Member =  whatever 
    ...

    GLOBALMEM UNLOCK  hMem

    DIALOG SHOW  ....
    IF modeless messageLoop here 

    GLOBALMEM FREE hMem

END FUNCTION    


CALLBACK FUNCTION MyCallBack() AS LONG 
 LOCAL hMem AS LONG, pUDT as myudt PTR 

       CASE %WM_MESSAGE_OF INTEREST 
          DIALOG GET USER  CBHNDL, 1 TO hMem 
          GLOBALMEM LOCK  hmem to pUDT 
          myParam =   @pUDT.memberName 
          GLOBALMEM UNLOCK hMem
          Do stuff with myparam 


....

???

[Gösta H. Lovgren-2]

I think "the hard way" is how we all learned.

Not me. I religiously follow all advice I get on programming on this forum. I never have a hard time.

==============================================
"Thank you for sending me a copy of your book
I'll waste no time reading it."
Moses Hadas (1900-1966)
==============================================

[Scott Turchin]

So Michael had some good points, this is portable code and I would like to reuse this some day.

BUT - I'm having issues- my Options dialog box (See far below) does NOT have the icon on it - which means I am not passing it correctly.....
My main dialog HAS the icon as I did a LoadIcon and attached it - Need to see if my pop up menu works...brb..

Type WindowHandles
    hIcon           As Long
    hInst           As Long
    hMenu           As Long
    pMenu           As Long
End Type   
'-------------------------------------------------------
'In Winmain

hMem = GlobalAlloc(%GMEM_FIXED,SizeOf(WindowHandles))
'if isfalse hMem Then There was a meltdown
pWin = GlobalLock(hMem)
@pWin.hMenu = hMenu
@pWin.pMenu = pMenu
@pWin.hInst = hInstance
@pWin.hIcon = hIcon
pWin = GlobalUnLock(hMem)
Dialog Set User BBSDown.hDlg , 1 , hMem
Dialog Show Modal BBSDown.hDlg Call DialogProc
GlobalFree hMem
CloseHandle hMutex
Call WSACleanup()
End Function  


'-------------------------------------------------------
In DialogProc

Local pWin             As WindowHandles Ptr
Local hMem             As Long


Select Case CbMsg
    Case %WM_INITDIALOG
        Dialog Get User  CbHndl, 1 To hMem
        hMem = GlobalAlloc(%GMEM_FIXED,SizeOf(WindowHandles))
        pWin = GlobalLock(hMem)
        hIcon = @pWin.hIcon
        hMenu = @pWin.hMenu
        pMenu= @pWin.pMenu
        hInst = @pWin.hInst
        pWin = GlobalUnLock(hMem)
        GlobalFree hMem

    Case %WM_COMMAND
      Select Case LoWrd(CbWParam)
         Case %IDM_OPTIONS
             Call Options(CbHndl,hIcon)

'-------------------------------------------------------
In Options Function
Function Options(hWnd As Long,hIcon As Long) As Long
Local oDlg As Long


Dialog New hWnd, "",,, 210,275, %WS_MINIMIZEBOX Or %WS_CAPTION Or %WS_SYSMENU To oDlg
Dialog Send oDlg, %WM_SETICON, %ICON_BIG,hIcon
Dialog Show Modal oDlg Call OptionsProc

[Michael Mattias]

>hMem = GlobalAlloc(%GMEM_FIXED,SizeOf(WindowHandles))

GLOBALMEM [ALLOC | LOCK | SIZE | UNLOCK |FREE ] ==> CC5 or Win9 help file

If no CC5/Win9: GMEM_FIXED not best choice IMO, use %GHND (=GMEM_MOVEABLE | GMEM_ZEROMEMORY) . (IMO= you may debate; IMNSHO you may not).

No icon? No LoadImage()/LoadIcon() ==> no valid hIcon.

MCM

[Michael Mattias]

Type WindowHandles
    hIcon           As Long
    hInst           As Long
    hMenu           As Long
    pMenu           As Long
End Type

FWIW, theres no need to store these in a parameter block ...

hIcon you can always get with WM_GETICON message

hInst you can always get from GetWindowLong (hWnd, %GWL_HINSTANCE)

hMenu you can always get with GetMenu()

I have no clue what "pmenu" is but fifty-two cents says it's redundant.

There may or may not be 'DDT' equivalents for these functions/messages.

[Richard Angell]

So Michael had some good points, this is portable code and I would like to reuse this some day.

Reusable code can also use Globals, but reommending that approach, well, it all depends. Example: a set of routines for developing information sets from an application with a known type of information such as a CAD database, an Excel spreadsheet with a standard form, etc.,etc.. If it is not so easily don, consider COM for a wide portability.

"Portable" can suggest a wider scope than just "reusable' for a set of target application types. I have used globals in this way without problems, but in any case it is very important to comment our code. Otherwise when we come back to the code for some reason, sometime downstream, we are not likely toremeber the whys and wherfors of the code in the firstplace.