here is the NMTVCUSTOMDRAW structure defined in CommCtl.h.
typedef struct tagNMTVCUSTOMDRAW {

#if (_WIN32_IE >= 0x0400)
int iLevel;

it does a check to see if im using internet explorer 4.0 and later: #if _WIN32_IE >= 0x0400 and if so go ahead and use int iLevel part of the structure. lets say im using an earlier version of internet explorer what adverse effects will i have if i define my structure this way:

clrText COLORREF ?
clrTextBk COLORREF ?
iLevel int ? ;should not be here since im using a lower version

so the size of the struture is actually larger than it should be with an extra entry.

below is what is really should look like:

clrText COLORREF ?
clrTextBk COLORREF ?
Posted on 2002-06-05 13:25:21 by smurf
you get alot of those conditional compilation stuff in the header files...
The only way of knowing what will happen is to try it and see...
other than that just ensure that IE is up to date....
Posted on 2002-06-05 13:33:45 by MArtial_Code
IE4 or better is not really a tall order to be asking for... IMO, i wouldnt worry about it... just put this requirement in the README.TXT and move on to bigger things :)

Posted on 2002-06-05 13:40:33 by NaN
bah!!. there are alot of structures that also check to see if your using windows 2000 and later.

what if i wanted to make an include and i made a masm compatable structure which includes everything in the structure including the windows 2000 part of the structure. then lets say someone with windows 95/98/me try using the structure... i was wondering if i would have any effect on anything at all? like use uneccessary memory etc?
Posted on 2002-06-05 14:10:45 by smurf
THen your do one of two things...

1) make your own Equates for version types. And program your source and structures with IF/ENDIF's based on these equates...

2) Check the version of OS at run time, and set an internal flag to follow, or link a dll, that will support the version...

Sorry, these are both overhead, i realize, but M$ made up the rules, not me... :rolleyes:

Best of luck..
Posted on 2002-06-05 14:22:05 by NaN
Nans first suggestion is the best bet...only thing is there won't be a standard...though I suppose we can follow the names which MS uses...
there must be others who are wondering the same thing ....
Shall we form a concensus on how to proceed then?
Posted on 2002-06-05 15:11:07 by MArtial_Code

yes i understand this is what needs to be done but i was wondering if there is any negative effects from doing it that way (having those extra members of the struture in there when they really arent suppose to be there.

hey MArtial_Code,

its sounds like a really good idea. the includes right now are basically a one man project ie Hutch and i dont think it needs to be that way. Hutch has stated he doesnt intend to add anything new to the includes because he wants to keep it stable.

well, so i have started converting the commctrl.h and im about half way through it. i was hoping maybe we can get a group of people together to set some standards and change the way the includes are made now and in the future. right now most of the equates and structures are all thrown into the file which it basically a big headache when trying to add additional stuff.

im gonna start a thread in the recruitment forum to see if we can come to some sort of concensus.
Posted on 2002-06-05 17:09:30 by smurf
Easy solution, leave the *.H files alone, and put your time into writing an MASM compatible assembler that supports reading *.H files. Or, maybe just a preprocessor to start with. I am curious if parsing *.PCH files would be easier? Those files will change with different versions.
Posted on 2002-06-05 18:11:57 by bitRAKE
in answer to your original question, i don't think declaring that extra member will make a difference in this case. The conditional compilation basically says "only IE4 and above will try to access this struct member".

What if you had to pass an array of structures to the API, and you had declared the extra member? I do not think this would matter either, as you would normally pass an array of pointers.

There is one scenario where it definately would matter: when the structures are in a dynamic buffer, like with some of the printer APIs (winspool.drv). In cases like this, you make a call to the API function, it then returns info to you to tell you how big a buffer it needs to store the info, you then create the buffer and call the API function again, which fills it with structures. Allocating too much memory for the buffer is fine, but if you are stepping through the buffer using a pointer, and incrementing the pointer by sizeof(ARRAY_WITH_TOO_MANY_MEMBERS), then your data will quickly become rubbish.
Posted on 2002-06-05 19:26:33 by sluggy
I think bitRAKE's idea is pretty good. I envy those gcc guys whose assembler can read C header files....It makes life so much easier.
Posted on 2002-06-06 03:17:06 by GogetaSSJ4
I think Smurf's idea is a good one. What I am stuck with is to try and get a stable WINDOWS.INC which is about win98 technology and for users who want the later stuff, use the extra include files.

Iczelion used to maintain the WINDOWS.INC file but his workload is too high to do it now and I have a limit on how much I can do so making later versions of OS include files is something that is needed by later OS users.

What I would really like to see is a core WIN32 include file and then have OS version add ons so you include the core WIN32 include then or or similar.

MASM can work with equates to do conditional assembly so it should be no big deal to have alternate or additional parts in structures.

Posted on 2002-06-06 10:29:04 by hutch--