Announcement

Collapse
No announcement yet.

Feature request

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

  • Feature request

    In the IDE it'd be very helpful if the declare for a function which the user was currently typing, would be displayed in the status bar. My memory must be lousy because I cant always remember the arguments for all of my user created functions let alone all those declared in the Wind32api.inc

    So it'd be very handy if while im typing out a function call, if the declare would appear in the status bar. (Even better would be if it appeared inline the way VB does... but that wouldnt be necessary. I'll gladly settle for the declare in the status bar or anywhere else you'd care to put it)

    Thanks
    -Mike

  • #2
    Hello Mike...

    Do you mean kinda like how Visual C++ does it when you start typing in and API function and a small TOOLTIP pops up with all the arguments for that function?

    If so, I would have to agree!

    What do you think about having global variables between all the callback function in PBDLL by default?


    Cheers!

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

    Comment


    • #3
      What do you think about having global variables between all the callback function in PBDLL by default?
      Speaking for myself, YECCHH!!!

      You know how long it took my to discipline myself AWAY from GLOBAL data? And how easy that made it to port my code from DOS to Windows?

      Don't go GLOBAL unless absolutely necessary.

      MCM
      Michael Mattias
      Tal Systems Inc. (retired)
      Racine WI USA
      [email protected]
      http://www.talsystems.com

      Comment


      • #4
        Well I think that you dont quite understand to what scope I mean GLOBAL...

        Using the DDT features provided with PBDLL you can subclass push buttons and the like into CALLBACK FUNCTIONS. The main CALLBACK would be the DIALOGPROC(). I just thought is would be handy to have semi-global variables but only global to each CALLBACK, NOT to the entire source. This would allow you to allocate arrays in the main CALLBACK and have them available for use in the PUSHBUTTON CALLBACKS. This would work much like CBHNDL,CBMSG,CBCTL, etc.. are semi-global to each CALLBACK.

        Cheers!

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

        Comment


        • #5
          Mark, thats exactly what I meant. I'm really missing those tooltip declare popups from VB ;-)

          Not sure about the global Callback functions variables though.

          Though i'd like to be able to have module level variables though. I'm finding it hard to avoid Global variables without module level variables.

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

          Comment


          • #6
            Your terminology is a bit unclear... a "module" is usually refers to a single compiled application (EXE) or library (DLL).

            GLOBAL's in a DLL are "private" to the code in that DLL. ie, they are not visible to the calling EXE (or any other code that is external to the DLL). The reverse is also true - GLOBAL's in an EXE are private to the EXE code, and not visible to any DLL's that the EXE may be linked to.

            Therefore, I guess that this is not what you mean by "module level variables"? Can you clarify your idea please? Thanks!


            ------------------
            Lance
            PowerBASIC Support
            mailto:[email protected][email protected]</A>
            Lance
            mailto:[email protected]

            Comment


            • #7
              The GLOBAL/LOCAL distinction is a very usefule one when designing modular
              code. PowerBASIC also has a STATIC statement where a variable behaves more
              or less like a GLOBAL but is only available within the function / sub
              where it is declared.

              There have been some dictates of fashion in the way that both are used but
              both have their place, depending on the code design. The very old versions
              of basic only had GLOBAL variables which made modular coding very
              difficult. An example of GLOBAL style code is the way many people code in
              TASM where everything was declared in the .DATA section.

              The alternative can often be a nuisance when you need to have a very
              complicated archipeligo of stack parameters to pass a value that is much
              better suited as a GLOBAL variable.

              Among the advantages when using LOCAL variables is that you can re-use the
              name in another function without any problems. If you need access to a
              variable across many different functions, it is a natural choice to make
              it into a GLOBAL variable as it is simply more efficient.

              As PowerBASIC has the three forms of variables, I don't see that there is
              a problem, it is a flexible way of declaring variables and is easy enough
              to use.

              [email protected]

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

              www.masm32.com

              Comment


              • #8
                > The alternative can often be a nuisance when you need to have a very
                > complicated archipeligo of stack parameters to pass a value that is much
                > better suited as a GLOBAL variable.

                I'd advise a global UDT holding all those variables in this case.
                You'd only have to pass the UDT address.


                Peter Manders.


                ------------------
                [email protected]

                Comment


                • #9
                  Sorry for the confusion. Im still stuck in a VB mindset it would seem. By "modular level variables" I was refering to having variables which were "global" to only a single .BAS file. In VB when you declare a variable using Dim X as Long in the declarations section of a .BAS it becomes available to all of the functions in that module. When you declare it as Public X as Long only then is it available to the entire program.

                  In that way you can create sort of a psuedo object whereby the module (.BAS) level variables had persistant values which served as object property values.

                  -Mike

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

                  Comment

                  Working...
                  X