Feature request

[Mike Joseph]

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

[mark smit]

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!

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

[Michael Mattias]

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

[mark smit]

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!

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

[Mike Joseph]

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.

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

[Lance Edmonds]

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>

[Steve Hutchesson]

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]

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

[Peter Manders]

> 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.


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

[Mike Joseph]

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

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