GLOBAL

[Eric Pearson]

Walt --

Interesting observation! Apparently GLOBAL currently requires a type identifier or an AS clause, even if a DEFtype is pertinent. It's surprising that this hasn't come up before, except that DEFtype is kind of an old-fashioned technique. In Windows programming it is much more common to use "Hungarian notation" where the first letter(s) of the variable tell you the type, like:

DIM glWhatever AS GLOBAL LONG

But you're right, this does look like something that needs to be addressed...

-- Eric


------------------
Perfect Sync: Perfect Sync Development Tools
Email: mailto:[email protected][email protected]</A>



[This message has been edited by Eric Pearson (edited June 04, 2000).]

[Walt Decker]

Thank you for your input. As for question 3 about the compiler not honoring DEFtype, what is the sense of having a DEFtype statement if it is not honored? Sounds like a bug in the compiler to me.

------------------

Hello Walt,

If I was in your shoes this is what I would do...

Create a structure that contains all the parameters you want to share with the DLL. Just before you load your DLL you should populate the structure with all the parameters and then pass a pointer to the structure to the DLL. I have used this method in the past and it worked like a charm!

Cheers!

------------------
Cheers

[Steve Hutchesson]

Walt,

It just happens to be the way windows comes, if you need to have a large number
of GLOBAL variables, keep them in the same application as the GLOBAL variables
in each application are only accessible from within it.

If you want to use DLL's which were not commonly available in DOS, you must pass
any value you need to it as either a parameter or as a member of a structure
(UDT). There are a number of ways you can pass a large number of variables but
in relation to porting a DOS app to windows, you are best to keep them in the
main app if thats how it was written in the first place.

For your declarations of variables, specify the data type and you will have no
problems, either by the type identifier,

GLOBAL var&

or

GLOBAL var as LONG

Good luck with it.

[email protected]

------------------

Walt,

Globals declared in DLLs are not visible to anything other than the actual DLL, the same goes for multiple programs - running two instances of the same application will result in each application having it's own variables.

If you want to pass lots of variables to a DLL function, then assign them to a UDT or just cut down on the number (PB has a limit of 16 - I think).

HTH

Regards,


------------------
Kev G Peel
KGP Software
Bridgwater, UK.
mailto:[email protected][email protected]</A>

[Walt Decker]

1. The manual states something to the effect that GLOBAL variables are not recognized by DLLs created by PB/DLL and that variables have to be passed to them even if the DLLs contain the same GLOBAL variables. If I have to pass, for example, 50 variables to a DLL, how would I go about doing that? Is there not a limit to the number of variables passed in the argument list?

2. Can GLOBAL variables be accessed by another app executing at the same time?

3. At compile time, the compiler does not honor DEFtype with variables in the GLOBAL section and issues an error that it expected "AS" type. It also issues an error that variables with the same name but different type are duplicate. I know that

Field% = CVI(Field$)

is poor practice ( although in this case it is descriptive) but when converting someone else's DOS app, it is better to leave his variables as they are so he can see what has been done without a great deal of written explanation. Anyway, the question is:

Is that a fluke of the compiler?