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

[Michael Mattias]

BTW, you can thank me for the USER variables. I asked for ONE, as I had been using SetWindowLong (DWL_USER or GWL_USER).

Mr. Zale expanded on this by supplying eight. Ask for an inch, get a mile?

[Dale Yarker]

Has obviously not read the posts before making post 20!

[Stuart McLachlan]

Has obviously not read the posts before making post 20!

Colour me surprised
(Sees word "thread" and drags up yet another irrelvant ancient post )

[Kurt Kuzba]

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.

The USER long variables are perfect for the job, of course.
I've use them where I need a long or a string that has scope where ever a control or dialog is found.
And you do have eight of them for each control or dialog, which is quite a few.
But, for clarity in coding, a global, defined as a global in its name, can be quite a bit easier to remember
when you get four hundred lines down the program and don't have a list of handy notes for quick referral.
And a single global variable, the UDT does reduce the number of global variables.
Some people, not mentioning any names, can get caught up in the immediate task, and not have immediate
recall of things that they did five minutes, half an hour, or two days ago. The global UDT makes recall of
the global less bothersome. Of course, one could always do that with the USER values, by assigning
presets to the numbers one through eight.
DIALOG SET USER hwin, %hMenu, menuhandle
As a matter of convenience, and to reduce having to look back at previous code to remember.

[Stuart McLachlan]

> But, for clarity in coding, a global, defined as a global in its name, can be quite a bit easier to remember
So does a simple consistent naming convention
My Globals are always prefiex with a "g" before the variable type descriptor.

It's fairly obvious that gwsCurrentCountry and gwsCountries() are global wide strings storing country data.

Unfortunately, neither of those fit well in a UDT (no dynamic strings, array must be pre-dimensioned) so you then need a mixture of UDT specified globals and individually specified ones.

I still don't see any advantage in using GlobalVariables.hMenu compared to ghMenu.

>And a single global variable, the UDT does reduce the number of global variables.
It only appears to do so. You still have the same number of variables with global scope and defining them is more cumbersome:

Type GLOBALS
    hMenu as DWORD
    lngCurrentID as LONG
    wsCurrentName as WSTRING * 20
END TYPE
GLOBAL GlobalVariables as GLOBALS
GLOBAL gwsCountries() AS WSTRING

versus

GLOBAL ghMenu as DWORD
GLOBAL glngCurrentID as LONG
GLOBAL gwsCurrentName as WSTRING
GLOBAL gwsCountries() AS WSTRING

[Dale Yarker]

The point:

DO NOT NEED GLOBAL

I use most of the suggestions here about globals when they are appropriate. Else subject of this thread applies.

Further:

DO NOT NEED UDTs

NOT DISCUSSING THREADS AT ALL

I put wrong handle in one line of post 1, fixed it when I saw post 4.

Half of page 1 should have been more than enough; here we are at post 26.

[Michael Mattias]

The goal was to copy one handle to the callback function (which cannot be called by user code

Actually you CAN manually CALL a callback function from user code. Get the CODEPTR() of the procedure and use CALL DWORD if a direct call-by-name is not supported in the version of PB you are using.

I do not recommend doing this.... but you CAN do it. I'd be especially wary of calling DDT 'CALLBACK FUNCTION's, as the arguments passed to the function are "hidden" to the user.

[Dale Yarker]

I do not recommend doing this....

Then keep it to yourself, or start another thread.

While your method may work, it goes directly against Help!

It may never be called directly from your code.

The line of mine that you quoted in post 27 was part of an explanation to someone else that said something not relevant to the subject of this thread.

Adam!!!! [polite mode nearly exhausted] Also see post 22 response to post 20. added: I'm also quoted in posted 18 and he brings up GLOBALMEM.
ENOUGH, ENOUGH, ENOUGH

[Michael Mattias]

I'm also quoted in posted 18 and he brings up GLOBALMEM .ENOUGH, ENOUGH, ENOUGH

You referred to using the USER vars to store Pointers. I pointed out another possible thing for which they could be used. You apparently never thought of this.

, it goes directly against Help!

Note that I explicitly qualified 'DDT Callback Functions" in this sentence

Meaning another thing you apparently never thought of are other callback functions, e.g....
PB/WIN: Write your own ENUM functions to callback September 23, 2002

And why do you think I do not recommend direct calling DDT callback functions? The main reason is, the help says not to.

The line of mine that you quoted in post 27 was part of an explanation to someone else that said something not relevant to the subject of this thread

It was not only irrelevant, it was grossly in error. I thought you should know. Hell, I thought everyone should know.

I only took the time to build this post because you gave members two (2) "I never thought of that" and one (1) "grossly in error" in the same thread.

Perhaps you need to think about the old adage which starts, "People who live in glass houses..." before you start criticizing the posts of other members.

I'm pretty sure Adam will either politely remind me of the rules or chew me a new one or something in between, but you are not the only one who has had ..

ENOUGH, ENOUGH, ENOUGH