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

Alan Chambers wrote: functions in a class only have local linkage via an object? member functions of a class receive the this pointer, which allow the functions to point directly the object that is using the function. a particular point is the static member functions -> no this pointer as implicit parameter TOXCCT >>> GEII power [toxcct][VisualCalc]

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

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

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 very much Joaquin, this code will cut down my development time immensely! Thankyou. I am looking into the autoexp.dat file thing so hopefully I'll be able to see whats in the string a bit easier too. Many Thanks (again) Alan. "When I left you I was but the learner, now I am the master" - Darth Vader

I wish I could swear at this point. I have AT LAST found the problem of ALL problems, and I managed to do it myself (where is the smiley for pat yourself on the back??). Do you want to know why my D3DDevice structure wasn't drawing a triangle on the screen? Well I'm gonna tell you anyway. You wil note my code in the previous message (above) where it says m_pD3DDevice->DrawPrimitive(...) ok? See the flag D3DVT_TLVERTEX? yeah? well change it to D3DFVF_TLVERTEX and the b*****d thing works! I have wasted 4 or 5 days on this crappy problem and if there is ever an excuse NOT to use Direct3D over OpenGL, that is it! That flag worked in v6, but not in v7, watch out for more nasty problems I run into on this very web site. "When I left you I was but the learner, now I am the master" - Darth Vader

Thanks for the suggestions. After a little thought I decided to go with the std::vector method, because it is dynamic and will only take up the required amount of precious memory. I can always set a limit to the number of modes I want to read in, but at least the memory allocation will be efficient... Thanks for the suggestion guys, very much appreciated. Alan. "When I left you I was but the learner, now I am the master" - Darth Vader

Cheers Michael, will keep my eyes peeled for it when I'm in Waterstones or Blackwells next:-D "When I left you I was but the learner, now I am the master" - Darth Vader

Alan Chambers wrote: I mean what has messagebox got to do with anything Well, if you are running DDraw windowed, you have to define clipping regions. Anyway, mixing GDI (i.e. messageBoxes) with DDraw is not trivial, so I suppose it is not anormal that sometimes strange things come out :-D ~RaGE();

throw (ifstream::failure) doesn't work That's expected. First you used a syntax that isn't anywhere close C++, then you tried to throw an exception of a class that needs an argument. You might try throw ifstream::failure("foo"); But I'd say you've got a design error if you want to throw an exception on behalf of someone else like this. Your code is then basically lying (even if it's you that catches that same execption). Step back a second and think: Would you want to maintain that code in two, five or ten years from now? If you're interested in failures, not just the ones that throw "ios_base<...>::failure", why not catch "exception" (as "const std::exception&" of course). Why does my DirecDraw primary surface back buffer throw up multi-coloured junk when I flip to it using a high resolution and 32 bit display? Because you haven't painted into the back-buffer! Check the return values of every call to DirectDraw.

Thanks for the reply Chris, your answers worked a treat. Sorry I didn't get back to sooner, but I went to bed straight after I posted the questions. I am just wondering how to pull out the system and graphics card name, clock speed, RAM etc.? I might find this information useful. I know you can get some of them through enumeration but this seems an awfully long way to go about getting information on the current spec. Again my thanks to you Chris. Alan. "When I left you I was but the learner, now I am the master" - Darth Vader

You will probably be better off going to teh GDI to do the color conversions for you. You can do this by asking your DirectDrawsruface for its DC then calling the GDI function. There is really no other way to do this in DirectDraw unless you want to do it yourself, but I am willing to bet that the GDI will still be faster than what you could create. Build a man a fire, and he will be warm for a day Light a man on fire, and he will be warm for the rest of his life!

Thanks for the reply Joaquin, I was wondering how to use the try catch exceptions without MFC (I have used CException but obviously can't if I'm not using MFC) and you have given it to me on a plate, so many thanks for that :). I also thank you for reaffirming the loading method, you know sometimes when you get that feeling when something doesn't quite feel right (thats what I got)? I think your example looks a lot sweeter, mind, with the try catch stuff in it, its exactly what I was looking for. Again, many thanks Joaquin, may the code be with you. Alan. "When I left you I was but the learner, now I am the master" - Darth Vader