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