Hi thanks for the reply, but it doesn't really help me. I've read the MSDN articles pretty thoroughly and that function basically only works on threads which have created a window using CreateWindow or CreateWindowEx and have a message pump. Since I've created the window on a separate thread, GetKeyboardState() only actually works if it's called within that threads loop, but it won't work on another thread unless AttachThreadInput() is used to share the message processing. However, AttachThreadInput() cannot be attached from or to the system thread (which is the one i'm using for my app) and in any case it would need to be a thread that has created a window and uses a windows message pump as well, which it does not. Looks like what I'm after is quite low-level, raw device state reading functionality but all I'm seeing is Windows event driven solutions. There's got to be a way to bypass all this windows guff and read directly from whatever hardware is present..surely..? Cheers for trying tho :) Alan.

"When I left you I was but the learner, now I am the master" - Darth Vader

Hi all I'm wanting to retrieve the current keyboard and mouse state without having to wait for an event message. I basically have a main thread and a window thread. The window thread handles the windows message pump so that if my app locks up, it can still process close messages etc. The main thread is where I am wanting to do the device state reads. Everything I've looked at so far (RAWINPUT, SetWindowsHookEx) rely on an event message being posted before I am able to read the state from the device. This is no good to me. I've also looked at GetKeyboardState(..) but that only retrieves the keyboard state in the thread that is handling the windows messages, so calling it from the main thread does not work (but calling it from the window thread does). I'm starting to think the only way is to get access to the device driver and directly read from the device. Anyone know any decent articles on this? Thanks, Alan.

"When I left you I was but the learner, now I am the master" - Darth Vader

I'm guessing its because namespace functions have global linkage within the namespace but by default functions in a class only have local linkage via an object? "When I left you I was but the learner, now I am the master" - Darth Vader

I changed it to this but I still get the same error message from gcc : "error: parse error before `namespace'" Do you think its a compiler bug or is it just not supposed to be supported? Its a bit weird don't you think considering that a class is essentially a namespace and you can have nested class declarations and nested namespace declarations, but not this way round? class Outcome { public: enum Type { kHalt, kMove, kJump, }; namespace halt { void Low(void); void Medium(void); void High(void); }; namespace move { void Low(void); void Medium(void); void High(void); }; namespace jump { void Low(void); void Medium(void); void High(void); }; Outcome::Type m_type; }; "When I left you I was but the learner, now I am the master" - Darth Vader

Is there any particular reason why the following code won't compile? Thats very basically what I have got. I'm only doing this as a quick hack, so I'm not at all concerned with code design, but it really intrigued me as to why it won't let me declare a namespace within a class? All the things I've read on the internet deal only with class declarations within a namespace but not visa versa. Just wondering whether this the c++ standard leaves it up to the compiler or whether its officially illegal code? Seems a bit silly to me, but maybe theres a reason for it? Just wondered if anyone's knows what it is? class Outcome { public: enum Type { kHalt, kMove, kJump, }; Type m_type; namespace halt { void Low(void); void Medium(void); void High(void); }; namespace move { void Low(void); void Medium(void); void High(void); }; namespace jump { void Low(void); void Medium(void); void High(void); }; }; "When I left you I was but the learner, now I am the master" - Darth Vader

its typically used to 'pack' a structure into a certain byte alignment because otherwise the structure gets padded out automatically and things either use up more memory than necessary OR saving and loading mechanisms (particularly on cross platform code or tool development (e.g. 16 bit machines etc.)) end up reading in the wrong amount of data and so the struct it loads is full of rubbish. However, my experience with #pragma pack is that its the most idiotic compiler directive i have seen. You can specify a struct with size 16 bits (using bit fields of type 'unsigned') specify a #pragma pack directive of 2 bytes (so the size of the struct should be 2 bytes in memory) and yet it fails badly and instead aligns it on a 4 byte boundary ! ! Change the unsigned type to unsigned short and it chucks it on a 2 byte boundary, hooray ! ! My verdict : Its absolute rubbish. "When I left you I was but the learner, now I am the master" - Darth Vader

I take it back, when I make all the struct elements of 'unsigned' type instead of specifying the size (u16), it packs them on a four byte boundary which is just absolutely crap because its soooooooo obvious i want it on a two byte boundary - not only am i specifying the bitfields upto a size of 16bits I'm also TELLING the thing via #pragma pack(2) to shove it on a 2 byte boundary and yet it still cocks it up ! It never ceases to amaze me. "When I left you I was but the learner, now I am the master" - Darth Vader

Hey thankyou for the tip off. It came like a dose of paracetemol to me :). Here are my answers to some of your questions. 1. Because i didn't see the point in declaring a 16 bit type with a bitfield of less than 8 bits when the 8 bit type is nearer the size i wanted (well that was the thinking). 2. I was assuming the compiler would notice it was trying to pack a 16 bit struct and therefore pack it on a 2 byte boundary as I was requesting. 3. Mmm the weird thing was that I saw that you're supposed to use the 'unsigned' declaration with no size typing so the compilers can make the same choices in their different ways. I think I was just extremely tired, either that or ignorant :). I also never bother referencing the c++ standard when using a Microsoft compiler because its tends to break it at will, although the .NET 2003 Visual Studio one is much more compliant (and I'm hoping 2005 will be even better with platform independant project management yay :) ). I could see that the two compilers had implemented it in their different ways, I just wanted to know what I had to do to get the microsoft implementation to give me the same semantics as gcc. I was only trying to make a tool for my blinking program, but became frustrated as I wasted the entire evening after coming home from work at 9.30pm (long day) doing something simple like this until 2am (British time). Your response solved it in two seconds. I think it is a lesson learned now though, I shall use the 'unsigned' type declaration instead of a u16 or u8 declaration and leave the packing all up to the compiler. Thanks again though :) "When I left you I was but the learner, now I am the master" - Darth Vader

I return to the windows development community in need of some anger and frustration relieving guidance from you guru's. I have the following code : #pragma pack(push, 1) typedef struct { u16 _id : 10; u8 _hflip : 1; u8 _vflip : 1; u8 _palettetype : 4; } MAPDATA; Correct me if I'm wrong but 10 bits + 1 bit + 1 bit + 4 bits = 16 bits which equates to 2 f**king bytes, yet #pragma pack, push, pop every blinking piece of crap that microsoft has to offer returns 3 bytes when I call sizeof(MAPDATA) ! ! ! If I use #pragma push(2) sizeof then miraculously returns with a 4 byte alignment. This is completely messing up my quantize and save algorithm and I've been up until 2am in the morning trying to figure out why gcc's __attribute__ ((packed)) works like a dream and microsoft's pants #pragma pack counts like an epileptic monkey in a bright multi-coloured jacket. Thanks all, and apologies for the frustration. "When I left you I was but the learner, now I am the master" - Darth Vader

class A { public: const int My_some_const; int k; A(int k_) : k (k) {}; } class B : public A { B(int k) : k(k), My_some_const(1) { }; } Is that what your looking for? That initialises both member variables without going through the base constructor "When I left you I was but the learner, now I am the master" - Darth Vader

I eventually found this 'undocumented' function (well it is documented, but yet again its the last thing MSDN wants to pull out from its library) which does *exactly* what I want it to do. _futime(int, _utimbuf) allows you to modify the time accessed and modified of a file that you have currently loaded with a valid os descriptor handle (use _futime(char*, _utimbuf) for MFC or people who don't have an os descriptor handle - specify the filename and path of the file to change instead). The _utimbuf has two components (for access and modify sections of the file properties) that must both be valid for it to succeed. Its that easy! But yet again the absolute heap of crap that is MSDN pulls out a billion results that include everything BUT what your looking for. I only stumbled across this by complete and utter fluke. When are we gonna see a comprehensive and intelligent help engine with VS? I have .NET 2003 and its nowhere near as intelligent as Delphi v5 help engine which is now nearly 5 years old! But at least code project is cool. "When I left you I was but the learner, now I am the master" - Darth Vader

use the fgets() function to read each complete line into an array of char (or CString or whatever you use), then just trawl through it until you find a ';' character and set it to 0 or '\0'. Once you've done that add it the combo box and read in the next line... "When I left you I was but the learner, now I am the master" - Darth Vader

int _setmaxstdio(int newmax) is your friend :). On .NET 2003 fopen defaults to 512 simultaneously open files which can be increased to 2,048 using this method. fopen() etc. are low-level C routines that C++ fstream is built on top of, therefore it probably just sets the default to the upper limit when it initialises 'for maximum simplicity'. Hope that helps ya, Al. "When I left you I was but the learner, now I am the master" - Darth Vader

Hi Guys, Thanks for replying to my message so soon. Sorry about the vague message I was just leaving work. Basically, I'm creating my own make file generator that scans the current .vcproj file for dependencies - which it does. However, I don't want it to be generating a makefile *every* time it compiles because the dependencies probably wouldn't have changed (unless a new file had been added or removed, but then it gets saved and a new time stamp), so my idea was to check if the .mak and .vcproj date and time stamps were the same, if they weren't my utility would generate the .mak file and set the date and time stamps to be the same as the .vcproj. I know I could just check if the .mak file is older than the .vcproj but I wanted proper versioning to be linked in as well and am currently extending my io class so it can do pointless things like this for any future tasks I might have :). I'm using C++ (no MFC or anything) to do it, but google seems to give me a billion things I really don't want at all. Hope you can help, thanks for taking the time to look over this message, Al. "When I left you I was but the learner, now I am the master" - Darth Vader

Does anyone out there know where to start looking? I want it fairly flexible so I can update the version and time stamp etc. for building my own custom make files :) from Visual C++ Cheers all, Al. "When I left you I was but the learner, now I am the master" - Darth Vader

I'll post it on their wish list :) Thats a pretty good idea actually, cheers Michael. BTW: Thats exactly what I have at the minute :) except I put #ifdef _WIN32 tags around the OutputDebugString() stuff so it doesn't affect my linux compilations. Thanks again, Alan. "When I left you I was but the learner, now I am the master" - Darth Vader

Thanks for your response Michael. I was guessing VS was doing something narky like this. kDevelop under linux has an stdout and stderr listener in its debug output pane, so any printf() calls can be traced very easily. Its the same with ProDG for playstation development, the TTY window picks up stdout strings. This is the main reason I want to use the stdout method, because its very portable across different platform development. It seems to me that VS is just a bit crap not being able to listen to this output stream, especially since if you do console window programming you can use either cout << OR printf to send a string to stdout and it gets displayed on the console window, but if you do proper windows programming it just does nothing??? Thats just rubbish. Perhaps I should write my own listener window pane, thats the easy bit, but is there any way of integrating it with visual studio then? I'm sure there is cos ProDG is integrated, I'm just wondering how though? Any ideas Michael? "When I left you I was but the learner, now I am the master" - Darth Vader

Some header includes are now officially redundant in 2003 so Microsoft is more 'ANSI compatible' and portable. If these lib headers include some now redundant libraries, you will have problems. A colleague of mine had linker errors. If these circumstaces sound familiar then changing your projects build order is needed to remove them. Al. "When I left you I was but the learner, now I am the master" - Darth Vader

Hi all, Just wondered if there was a portable way to send strings to the debugger's output pane. For this reason I don't want to use OutputDebugString(). I'd ideally like a way to use freopen(), or such like, to switch stdout to the output pane of the .NET IDE. I could then only do this for windows debugging app's and leave the normal stdout for linux because the debugger picks it up. I'd even welcome a way of integrating an stdout viewer in the output window as a seperate tab. Any ideas on how to do this would be very welcome. Thanks, Alan. "When I left you I was but the learner, now I am the master" - Darth Vader

There are two ways to look at it, learning C++ via MFC is bad because it hides everything, or learning C++ via MFC is good because it hides everything. I think both are perfectly adequate. The C++ syntax is very confusing for a beginner because it is less like english than many high level languages (VB, delphi etc.) and MFC provides an entry point into the syntax. And I think because it is a high-level framework, much like VB, beginners can get into C++ and do things without seeing the enormity of the language and getting put off by the realisation of just how big a task it is to learn C++. For those who are curious, they will dig to the bottom of MFC to find how it works and is put together and start developing a proper C++ knowledge base. Doing it the other way around is very difficult because you are stepping into the cauldron of fire, where there is lots of code and little reward, many just get bored. However, it is as you say a very good way of learning, because you learn from the ground up. As you learn more, you will be able to see how MFC is put together without even looking at it. I'd say if your completely dedicated, start from the bottom and create some simple apps and figure out how it works. If your not sure about learning a language, check MFC out and see if you can get to grips with that, cos if you can't there's no point in pursing your hobby with C++. "When I left you I was but the learner, now I am the master" - Darth Vader