help with syntax please

[Mark Farrar]

I'm new to Windows GUI programming. Learning from the ground up and I have been looking at several great references, but this line of code still confuses me. I get it that hInstance is a variable and I understand what is being done, but the HINSTANCE followed by the variable hInstance has me stuck. Can anyone explain what this is really doing/saying etc? thanks...
HINSTANCE hInstance = GetModuleHandle(NULL);

[William Burns]

C/C++ allows you to define a variable and assign the value on the same line. The first HINSTANCE is defining what type of variable hInstance is. Then it is assigning a value that is being returned from the GetModuleHandle(NULL) api.

As a side note, the variable does not have to be named the same as the type. They could have also used something like this: HINSTANCE hInst = GetModuleHandle(NULL);

Since HINSTANCE is a handle, it would translate to a DWORD in basic. So the statement would be equal to this Basic style code:

Dim hInstance   as DWORD
hInstance = GetModuleHandle(ByVal %NULL)

Does that help?

[Rodney Hicks]

Open the help file for the SDK in PB. Click on the index tab and scroll down to 'Simple Types'.
You will find HINSTANCE listed alphabetically. I could be wrong on this part, but I believe it converts nicely to a DWORD for use in PB.

Rod

[Mark Farrar]

thanks

oh! perfect....thanks! It didn't sink in that, in this case, HINSTANCE was a type! I was thinking this was doing something else entirely. Sometimes the obvious in is the answer...most appreciated.

M Farrar

[George Deluca]

Don't worry Mark. I also am tired of seeing so called simple examples of code where the writer insists on using variable names EQUAL TO variable types. It's nothing but bloody confusion for someone who is struggling with the basics of a language.

I have always believed that compilers should NEVER allow variables to be named the same as ANY keywords. My God, how hard is it to come up with a simple non-ambiguous name.

George

[Kev Peel]

It is annoying, but since C is a case-sensitive language, these types are not the same to the compiler and don't directly translate to PB.

ie. PB once (v6 and earlier?) allowed this, and there are many code samples floating around that use:

DIM wndclass AS WNDCLASSEX

...but since it is no longer allowed (WNDCLASSEX is already defined), this old code will now fail.

[Mark Farrar]

windows is different

I have a working knowledge of several languages and have programmed quite a bit for console or DOS environments. Even work on the old VAX 11/780 back in college, but windows is different. The HINSTANCE thing seems obvious now, but it really had me stuck. I kept thinking it was some kind of compound command or something and couldn't fine a good reference. I agree that naming variables and types the same is....hmmm...what would be the politically sensitive term...oh yea...dumb. However, in this case it was more than that. I tend to think of types as being "system obvious" i.e. integer, byte, float, string, long integer etc etc (in a generic sense)...these mean something as there is a correlation to what the data actually looks like. In this HINSTANCE case I have found that it is among many task specific types that are all really just 32 bit unsigned integers...I think that is DWORD in PB right? So, I keep thinking, why do you need 20 different types that are really all the same only with different names depending on where you use them? gives me a headache!

but...thanks to all for helping out...once I knew where to look all the pieces fell into place.

Mark

[Fred Harris]

The basic idea is to help the C/C++ compiler to help you from blowing your foot off by plugging the wrong kind of variable into a function call. The C family of languages have an enormously tricky feature named the typedef (type definition). You can create a new name for a fundamental type such as an unsigned 32 bit integer with it. For example, 'unsigned int' is a lot to write, so typically this is done...

typedef unsigned int UINT;

Then, you can just do this...

UINT i,j,k;

That use is fairly benign, and for answering your question we don't need to go deeper into it, but, believe me, it gets much deeper.

So the way its used is that when a function is created that does some specific thing, and it takes parameters, the parameters may be the result of these typedefs so that if you place the wrong kind of parameter in the function call the compiler (preprocessor more likely) can catch the parameter mismatch, even though what you put in was an unsigned 32 bit value and what the function wants in an unsigned 32 bit value, but it wants a 'specific kind' of 32 bit unsigned value.

The Windows GDI (Graphics Device Interface) has a rich assortment of typedef'ed 32 bit integers such as FONTS, HDCs, HBRUSHs, HPENs, etc. If you put the wrong one in a function call the C compiler will catch that. Now in PowerBASIC it won't. Your program will compile and GPF as soon as it hits the bad call.

In my opinion the amount of errors actually caught through these typedefs aren't worth the lost time and grief they cause. I regularly switch between using C/C++ and PowerBASIC and I can tell you these things eat up time. However, I'm an application programmer, not a systems programmer. Perhaps folks who write operating systems and things like that have a different take on it.

[Chris Holbrook]

In my opinion the amount of errors actually caught through these typedefs aren't worth the lost time and grief they cause...etc

You hit the nail on the head there Fred. I was slowed to a crawl by writing Windows APIs in C, this must be one of the biggest things going for PB SDK over C for Windows programming.

[Kev Peel]

The usage of these TYPEDEFs not only allows for "stricter" checks by the compiler as mentioned by Fred, but also depends on the version (subsystem) of the Windows API in use - three versions are available: 16, 32 and 64 bit. So they are defined as follows:

Win16 HANDLE is 16-bit (WORD in PB)
Win32 HANDLE is 32-bit (DWORD in PB)
Win64 HANDLE is 64-bit (QUAD in PB)

But since there is currently only a 32-bit version of PB that will only support Win32, we always use DWORD, or a LONG if no arithmetic or equivalence checks are done.

Note: there was a 16-bit version of PBDLL 2 a long time ago, but it is no longer available. I never used it, having moved from VB6 to PBDLL 5 in 1998.

[Michael Mattias]

>there was a 16-bit version of PBDLL 2 a long time ago, but it is no longer available

Still installed here. You need a 16-bit Win/3 program? Contact my office.

And in one of those truly odd and highly immaterial factoids......

Although PB/DLL 2.0 can RUN on Win/3, and creates programs which run on Win/3, you could not install it on Win/3 .... because the installer was 32-bit!

[Bob Zale]

Note: there was a 16-bit version of PBDLL 2 a long time ago, but it is no longer available.

Please GOTO the PowerBASIC order page at:

https://www.powerbasic.com/shop/

...look at item 13, and you will find PB/DLL 2.0, our 16-bit Windows compiler. Competitively priced at just $59.00.

Best regards,

Bob Zale
PowerBASIC Inc.

[Kev Peel]

Please GOTO the PowerBASIC order page at:

https://www.powerbasic.com/shop/

...look at item 13, and you will find PB/DLL 2.0, our 16-bit Windows compiler. Competitively priced at just $59.00.

Best regards,

Bob Zale
PowerBASIC Inc.

Oops, sorry Bob, I thought it was discontinued! Didn't it come bundled with PB/DLL 5 once upon a time?

I don't have a need for it, however, having moved to 32-bit development over 10 years ago

[Michael Mattias]

There goes my semi-exclusive. Right down Ye Olde Toilette.

[Fred Harris]

I'm virtually sure about this, and that is that PB 6 offered the choice of installing either the 16 bit version or the 32 bit version or both. VB 4 was like that too. I guess most of the tools from that 1995 - 2000 era were.

Getting back to the topic of the original post though, and continuing on wth C's redefinition of the fundamental types with typedefs, the use of typedefs necessitated that other much loved C concept and that is, of course everybody's favorite - yes! Casting!!!

I kind of presumed the original thread starter might have been doing Petzold. It won't take too long until one hits that beloved HMENU parameter in the CreateWindowEx() call. It always struck me as extremely silly to have to do this sort of thing to pass the window control id parameter to the api...

(HMENU)IDC_WHATEVER

But there you have it. In that case that particular parameter to the function has been declared as a type HMENU through some typecast somewhere in that inpenetratable tangle of header files loaded by windows.h, and by doing the cast you are telling the compiler that...yes, yes, I know its not a handle to a menu, just go ahead and compile the blasted thing for me, and if anything bad happens I'll take responsibility.

I'd venture to say that what with the typedefs, casting issue, and lack of any high level string support the average programmer fluent in both languages even, will probably be somewhere in the vicinity of 25% more productive with PowerBASIC.