A way to reduce using GLOBAL, or a use for USER variables.

[Dale Yarker]

Maybe I'm late catching on, but I've not seen it mentioned either. {If a GLOBAL is best, then use it. I disagree with avoiding GLOBALs at all costs.} Anyway:

To change menu text I needed the menu's handle, hMenu, created in a FUNCTION with the DIALOG and CONTROLs, to be available in the CALLBACK FUNCTION. An obvious (and least thinking applied ) choise is a GLOBAL.

Somehow it occurred to me that dialog USER variables were accessable in both functions. The only additional thing needed is the dialog handle. So hDlg any time after DIALOG NEW, and CB.HNDL in the callback.

Specific example code lines:

'
  ...
  DIALOG NEW 0, "Caption text", x, y, xx, yy TO hDlg
  ...
  MENU NEW BAR TO hMenu
  DIALOG SET USER hDlg, 1, hMenu
  ...

'in callback
...
  CASE %WM_INITDIALOG
    STATIC hMenu as long
    DIALOG GET USER CB.HNDL, 1 TO hMenu
...
  CASE some_ event
    MENU SET TEXT hMenu, position_or_BYCMD_ID, new_text
    'menu strings have position and ID, popups only position
    MENU DRAW BAR CB.HNDL
...

DIALOGs and CONTROLs each have 8 USER variables. LISTBOXes, COMBOBOXes and LISTVIEWs also have one USER variable per line/row. In Help see DIALOG GET USER, DIALOG SET USER, CONTROL GET USER, CONTROL SET USER, COMBOBOX GET USER, COMOBOX SET USER, LISTBOX GET USER, LISTBOX SET USER, LISTVIEW GET USER and LISTVIEW SET USER.

Cheers,

[Stuart McLachlan]

Yep, there are all sorts of uses for control/dialog user variables as long as you only need to store integer values.
It's well worth keeping them in mind,
Listbox/Listivew row user variables are particularly useful ( in additiomn to the 8 control variables)

You'll find quite a few ideas if you Google: site: forum.powerbasic.com "get user"

[Dale Yarker]

. . . as long as you only need to store integer values.

Thanks, I didn't mention that POINTERs to other types can be in a USER variable.

[Eric Pearson]

Dale, your example code sets hMenu in the callback function but never uses it.

[Stuart McLachlan]

Dale, your example code sets hMenu in the callback function but never uses it.

Typo?
MENU SET TEXT CB.HNDL,
should be
MENU SET TEXT hMenu,

[Dale Yarker]

Corrected above.

[Kurt Kuzba]

You can make it all more convenient by using a single global UDT.
Call it GlobalVariables.
Then, when you access GlobalVariables.hmenu, there is no question about what is going on, and no opportunity for accidents.

[Dale Yarker]

Uh ... okay, that works. But:

The goal was to copy one handle to the callback function (which cannot be called by user code); a globally available variable is not needed. So how is a GLOBAL UDT more convenient and less error prone?

[Mike Doty]

I agree with Kurt

This uses threaded records so it is thread safe and values can also be used in the callback.
This would make things simple no matter how many dialogs or values.
If on a network would want to keep the dialogs.txt file unique for each station occurance.

#DIM ALL
#UNIQUE VAR ON

TYPE MyRecord   'threadedrecord.bas
 caption AS STRING * 11
 hdlg    AS DWORD
 values  AS STRING * 32
END TYPE
THREADED trec AS MyRecord,thFile,tDialogNum AS DWORD

FUNCTION PBMAIN AS LONG

 thFile = FREEFILE
 OPEN "dialogs.txt" FOR RANDOM SHARED AS #thfile LEN=LEN(MyRecord)

 tDialogNum = 1
 trec.caption = "Dialog One"
 trec.hdlg    = 12345
 trec.values  = "Other values"
 PUT #thfile,tDialogNum,trec

 GET #thfile,tDialogNum,trec
 ? USING$("&&#&&",trec.caption,trec.hdlg,trec.values),,"Dialog"+STR$(tDialogNum)

 CLOSE #thfile

END FUNCTION

[Dale Yarker]

THREADED is simpler?

Which part of ONE variable to ONE NON callable function is hard to understand?

UDTS MORE COMPLICATED THAN NEEDED. THREADED MORE COMPLICATED SQUARED. [braille seat cushions not available]

You two should start another thread to add user defined messages to make it more complicated cubed.

[Stuart McLachlan]

You can make it all more convenient by using a single global UDT.
Call it GlobalVariables.
Then, when you access GlobalVariables.hmenu, there is no question about what is going on, and no opportunity for accidents.

I fail to see how that is any clearer or less "accident prone" than GLOBAL ghMenu AS DWORD.

It does exactly the same thing, but is just more cumbersome to use in the source code.

[Stuart McLachlan]

OPEN "dialogs.txt" FOR RANDOM SHARED AS #thfile LEN=LEN(MyRecord)
tDialogNum = 1
trec.caption = "Dialog One"
trec.hdlg = 12345
trec.values = "Other values"
PUT #thfile,tDialogNum,trec​

Seriously?
Storing internal system values values (threaded?) in an external file and access them in a non-threaded function? Can you say "accident prone"?

[Mike Doty]

The file is not required nor the get and put.
It was only testing the UDT to disk. Thought more globals might be involved.

[Dave Biggs]

OTOH GetMenu(CB.HNDL)

[Dale Yarker]

Yes, that will get hMenu in the callback.

I dislike re-requesting known information.

[Dave Biggs]

Ask once - use many

    CASE %WM_INITDIALOG
     STATIC hMenu AS DWORD
      hMenu = GetMenu(CB.HNDL)

[Dale Yarker]

MENU NEW BAR TO hMenu is once.

Generically, it may not always be hMenu.

[Michael Mattias]

>> as long as you only need to store integer values.
> Thanks, I didn't mention that POINTERs to other types can be in a USER variable

OR a Global Memory Handle ("GLOBALMEM ALLOC 1024. TO hMem"). Can be handy for strings or UDTs

[Stuart McLachlan]

MENU NEW BAR TO hMenu is once.

Generically, it may not always be hMenu.

Interesting idea.
If you want dynamic menus, that change according to what the user is doing at the time, instead of adding and deleting menu items, you could create up to eight different menus per dialog during intitalisation and store all of their handles as dialog user variables.

Then:
'Switch to menu 4
menuid = 4
DIALOG GET USER CB.HNDL,menuid TO hmenu
MENU ATTACH CB.HNDL, hmenu

[Michael Mattias]

THREADED is simpler?

THREADED variables can be simpler (than using Thread Local Storage). Multi-Threaded programs are not; there's more to them than simply using THREADED variables!.

Demo of what is less simpler, from the days before PB had THREADED variables:

Terminate Worker Threads Using Windows Events (and Using Thread Local Storage) Demo Dec 23 2005