www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Windows Header consts

reply "Prudence" <Pursuit Happyness.All> writes:
Windows headers contain a ton of global const's for the various 
messages. Seems like a very bad way to go about this.

Could one not simply put all these in an enum? e.g., enum WM { 
WM_CREATE = 1, etc... }?

If so, because there are so many and so many references to them, 
this can't be done easily by hand. Surely there is a way to 
automate this? But because the headers are not consistently 
written, a simple search and replace won't work well?

e.g.,

const WM_* -> add to enum WM;
else WM_* -> WM.*

because there is code like

static if (_WIN32_WINNT >= 0x500) {

	enum {
		WM_CHANGEUISTATE	=	0x0127,
		WM_UPDATEUISTATE	=	0x0128,
		WM_QUERYUISTATE		=	0x0129
	}

	// LOWORD(wParam) values in WM_*UISTATE*
	enum {
		UIS_SET			=	1,
		UIS_CLEAR		=	2,
		UIS_INITIALIZE	=	3
	}

	// HIWORD(wParam) values in WM_*UISTATE*
	enum {
		UISF_HIDEFOCUS	=	0x1,
		UISF_HIDEACCEL	=	0x2
	}

}

static if (_WIN32_WINNT >= 0x501) {

	// HIWORD(wParam) values in WM_*UISTATE*
	enum {
		UISF_ACTIVE		=	0x4
	}

}

(unless one can define partial enums or use static if in the 
enums directly(probably the case but parsing is more difficult))


I guessing one would need a D or C parser to deal with all this?
Sep 07 2015
next sibling parent "Prudence" <Pursuit Happyness.All> writes:
On that note, is there also any generic translation software for 
code that you can program a set of simple "rules"(matching and 
arranging) to translate source code?

e.g., match("const WM_", ";")->WM.add(%1 + ",")).

The above should be obvious but essentially it matches the first 
string until the second is found, adds it to the WM 
container(which, we can specify it it's type). %1 is just what 
was found inbetween the two bookends in the match. We add a comma 
for the next enum.

(such a line would put all the const WM's into the enum, it 
doesn't handle the outer static versioning, so would break 
headers... hence a more robust solution is needed)
Sep 07 2015
prev sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Monday, 7 September 2015 at 17:44:54 UTC, Prudence wrote:

 const WM_* -> add to enum WM;
 else WM_* -> WM.*


I'm against that. The documentation all says WM_* and we 
shouldn't muck with it.

const -> enum is a good idea though. These headers were all 
written waaaaay back when when const and enum had different 
meanings.


 I guessing one would need a D or C parser to deal with all this?


hackerpilot's dfix would be the starting point.
Sep 07 2015
parent reply "Prudence" <Pursuit Happyness.All> writes:
On Monday, 7 September 2015 at 17:59:43 UTC, Adam D. Ruppe wrote:

 On Monday, 7 September 2015 at 17:44:54 UTC, Prudence wrote:

 const WM_* -> add to enum WM;
 else WM_* -> WM.*


 I'm against that. The documentation all says WM_* and we 
 shouldn't muck with it.


huh?
Are you saying you don't like to use

WM.Create

because it is confusing and hard for you to understand over

WM_Create?

Did you do a lot of win32 programming back in the day?
Sep 07 2015
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Monday, 7 September 2015 at 18:42:59 UTC, Prudence wrote:

 because it is confusing and hard for you to understand over


Nope, I'm saying it is a pointless change. If you do that, EVERY 
time you want to look something up, you need to rewrite WM.* into 
WM_* since that's what the docs say. And then EVERY time you 
copy/paste code from C or, again, the docs, you need to change it 
the other way. (and moreover, it won't even work, since like you 
pointed out, some enums have static if in part)


That's a big hassle... and what's the benefit? What do you 
actually gain by doing this?


 Did you do a lot of win32 programming back in the day?


Yup, and I still do. The documented names have worked for twenty 
years, why change them now?
Sep 07 2015
parent reply "Prudence" <Pursuit Happyness.All> writes:
On Monday, 7 September 2015 at 18:58:08 UTC, Adam D. Ruppe wrote:

 On Monday, 7 September 2015 at 18:42:59 UTC, Prudence wrote:

 because it is confusing and hard for you to understand over


 Nope, I'm saying it is a pointless change. If you do that, 
 EVERY time you want to look something up, you need to rewrite 
 WM.* into WM_* since that's what the docs say. And then EVERY 
 time you copy/paste code from C or, again, the docs, you need 
 to change it the other way. (and moreover, it won't even work, 
 since like you pointed out, some enums have static if in part)


 That's a big hassle... and what's the benefit? What do you 
 actually gain by doing this?


It's called encapsulation. It prevents namespace pollution and 
identifier collision. It also makes intelligent easier, not to 
mention looks nicer, keeps everything tidy, and everything else 
that makes coding easier.

If you think mentally changing a . to a _ is a hassle then your 
in trouble! An apple a day simply won't help!

I understand porting code won't be as easy but a simple WM_ to WM 
replacement would fix 99% of the problems. Oh well, some people 
just don't like progress! Do you want to go back to using wooden 
wheels too? Is that better because it's easier to understand than 
the complexity of vulcanized rubber and carbon steel?



 Did you do a lot of win32 programming back in the day?


 Yup, and I still do. The documented names have worked for 
 twenty years, why change them now?


That's what I figured! Get out of the dark ages!
Sep 07 2015
next sibling parent anonymous <anonymous example.com> writes:
On Monday 07 September 2015 21:06, Prudence wrote:


 If you think mentally changing a . to a _ is a hassle then your 
 in trouble! An apple a day simply won't help!


[...]

 Oh well, some people 
 just don't like progress! Do you want to go back to using wooden 
 wheels too?


[...]

 Get out of the dark ages!


This is uncalled for. Please stay friendly.
Sep 07 2015
prev sibling next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Monday, 7 September 2015 at 19:06:48 UTC, Prudence wrote:

 It's called encapsulation. It prevents namespace pollution and 
 identifier collision.


This is already provided by the D module system. Even if you were 
to define a WM_CREATE in your code, it would not cause a major 
problem with the Win32 name because you can disambiguate via the 
imports. (That's also a minor hassle, but it is more rare for 
these long names than a short name like WM anyway!)

My editor already autocompletes WM_* names anyway, but again, the 
D module system can help with that too if you didn't want the 
keyword based completion I use for that.

I just don't see any advantage here to counterbalance the pain of 
changing it.
Sep 07 2015
parent reply "Prudence" <Pursuit Happyness.All> writes:
On Monday, 7 September 2015 at 20:55:25 UTC, Adam D. Ruppe wrote:

 On Monday, 7 September 2015 at 19:06:48 UTC, Prudence wrote:

 It's called encapsulation. It prevents namespace pollution and 
 identifier collision.


 This is already provided by the D module system. Even if you 
 were to define a WM_CREATE in your code, it would not cause a 
 major problem with the Win32 name because you can disambiguate 
 via the imports. (That's also a minor hassle, but it is more 
 rare for these long names than a short name like WM anyway!)

 My editor already autocompletes WM_* names anyway, but again, 
 the D module system can help with that too if you didn't want 
 the keyword based completion I use for that.

 I just don't see any advantage here to counterbalance the pain 
 of changing it.


Again, it's called progress. Why keep using the same defunct 
system for endless years simply because that's the way it was 
done?

It's like saying we should never upgrade the space shuttle(not 
that it matters any more) simply because the previous one was 
working?

Do you seriously think that your logic is the best? If you could 
prove that Bill Gates designed the best OS ever possible, that is 
one thing... But changes are they shit all over themselves while 
doing it because they didn't learn from there mistakes(how could 
they, they go in to the future to see what kinda crap came out).

Do you think computers in 100 years are still going to be using 
windows? Do you think the designers will still use the same 
programming techniques? Do you think they will worship Bill Gates 
because think they the messaging model of Windows was the 
ultimate gift to humanity?

It's one thing to say: "I'm just too lazy to want to waste all 
that time changing stuff to make it work". That's a valid 
argument! But it's quite different to say "We don't need to 
change because this model works best and any modification of it 
will only produce a poorer result". If you are going to use the 
second argument, you need to prove it. If you are going to use 
the first, don't expect to get anywhere.

I just wish when people say stuff like you have done, you would 
be honest and say what you really mean so we don't have to waste 
time beating around the bush. A simple "I'm don't care what 
others want, I think we should keep it the same because I'm happy 
with it". I'm OK with such a statement. At least it's honest and 
direct. I might not like the selfishness that it implies, but to 
each his own, I suppose.

Oh, and who says you couldn't keep both systems? But I'll never 
understand why people think keeping a junker around and NOT allow 
something better is a good idea. You can keep your rusted ol' 
ElCamino that's missing a tire and has no hood if you want. But 
why stop me from having a Ferrari? Is it jealousy? Selfishness? 
There's enough gas to go around you know? And if we both arrive 
at the gas station we can take turns, if your willing?
Sep 07 2015
next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Monday, 7 September 2015 at 22:02:47 UTC, Prudence wrote:

 Oh, and who says you couldn't keep both systems?


Nobody. There's absolutely nothing stopping you from defining 
your one constants and bindings. I think you should actually do 
it and see for yourself the pros and cons in practice.
Sep 07 2015
parent reply "Prudence" <Pursuit Happyness.All> writes:
On Monday, 7 September 2015 at 22:21:28 UTC, Adam D. Ruppe wrote:

 On Monday, 7 September 2015 at 22:02:47 UTC, Prudence wrote:

 Oh, and who says you couldn't keep both systems?


 Nobody. There's absolutely nothing stopping you from defining 
 your one constants and bindings. I think you should actually do 
 it and see for yourself the pros and cons in practice.


Which is why I asked is there is an easy way to do it, and you 
replied that essentially that it shouldn't be changed because it 
would change things.
Sep 07 2015
parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Monday, 7 September 2015 at 23:11:36 UTC, Prudence wrote:

 I asked is there is an easy way to do it, and you replied that 
 essentially that it shouldn't be changed because it would 
 change things.


I also said:


 I guessing one would need a D or C parser to deal with all 
 this?


 hackerpilot's dfix would be the starting point.


https://github.com/Hackerpilot/dfix
Sep 07 2015
prev sibling parent "Mike Parker" <aldacron gmail.com> writes:
On Monday, 7 September 2015 at 22:02:47 UTC, Prudence wrote:

 Again, it's called progress. Why keep using the same defunct 
 system for endless years simply because that's the way it was 
 done?


Any C library binding should maintain the same interface as the C 
library as much as possible. That way any existing C code can be 
directly ported to D with minimal modification. If you then want 
to build a wrapper on top of that to make it more D-like, that's 
perfectly fine, but the binding itself shouldn't be D-ified.
Sep 07 2015
prev sibling parent reply "NX" <no-reply mail.com> writes:
On Monday, 7 September 2015 at 19:06:48 UTC, Prudence wrote:


 It's called encapsulation.


Do you have any idea how much I struggled when I try to use enums 
in OpenTK library because they were "encapsulated" ?
Whenever I read OpenGL tutorials I have figure out which 
enum-name they used as container...
Sep 08 2015
parent "NX" <no-reply mail.com> writes:
On Tuesday, 8 September 2015 at 17:22:44 UTC, NX wrote:

  I have figure out


typo:
...I had to figure out...
Sep 08 2015