Announcement

Collapse
No announcement yet.

GLOBAL

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • GLOBAL

    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?
    Walt Decker

  • #2
    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>

    Comment


    • #3
      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]

      ------------------
      hutch at movsd dot com
      The MASM Forum

      www.masm32.com

      Comment


      • #4
        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

        Comment


        • #5
          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.

          ------------------
          Walt Decker

          Comment


          • #6
            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:

            Code:
            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).]
            "Not my circus, not my monkeys."

            Comment

            Working...
            X