On Wed, 4 Feb 2004 19:23:30 -0600, Dan P <dan### [at] yahoocom> wrote:
> Also, I've been really diving
> deep into the Windows API and I've noticed two things: 1. it's really,
> really poorly documented, and 2. you have to do everything precisely the 
> way they want you to or it's going to crash and not pretty-like.

That's funny. I've always found the Windows API to have very extensive and 
detailed documentation; much better than most other APIs I've encountered. 
It takes a little while to get accustomed to the style of documentation 
though.
As for your second point, I can agree to some extent. For me the problem 
isn't so much the conseqeunces of doing something wrong, so much as the 
fact that the "right" way of doing things is sometimes unnecessarily 
complicated and archaic. Part of the price you pay for backwards 
compatibility I guess; the core of the API is very, very old.


> It only makes
> sense what those components are doing after you trace it using the 
> debugger.
> And even then, it's not obvious. I'm really worried about writing code 
> that
> works great on my PC but crashes elsewhere because of that. What I had 
> to do
> to handle window-resizing in an instant, efficient manner best not be 
> said
> in mixed company :-)

Actually, I'd be interested in hearing more about this. Just about the 
only reason I ever use the WinAPI directly these days is that I'm 
confident it will work as intended on other machines (running Windows). 
Problems arise only when using stuff like DirectX or OpenGL; differing 
hardware capabilities and driver versions can really wreak havoc then.


> What I'm really surprised about is that they haven't put all those 
> structs
> into convenient-to-use classes. I struggled for an entire night to get
> version info from my VS_VERSION_INFO resource. It turns out I have to 
> create
> two HGLOBALS, then lock the resource, and then use VerQueryInfo, and it
> /still/ didn't work -- I guess they just don't want you reading that
> resource directly, and I tried passing the executable file name and it
> didn't work /then/ either. I did massive searches on the net to see other
> people doing this and I couldn't find a single, consistent explanation of
> how to get this information.

Version info is supposed to be retrieved with GetFileVersionInfo & 
VerQueryValue, is it not?
The only time I've had to load a resource explicitly was when I had 
resources containing custom data. All the standard resource types have 
special functions for retrieving the data.


> Why the couldn't just make a class called
> CVersionInfo and throw the data in there it is beyond me.

The WinAPI is a C-based API. If you want class wrappers, you need to find 
a C++ framework, e.g. wxWindows, QT, FOX, gtkmm, etc.. Note that I do not 
include MFC in that list; I personally find MFC to be utterly useless.


> I also had to make
> some REALLY ugly code to read PNGs from the resource instead of a 
> seperate
> file. Here it is:
>
>      IStream *p_objStream;
>      HRSRC objResource;
>      HGLOBAL objSrc;
>      HGLOBAL objData;
>
>      // Load the about image.
>      objResource = FindResource(NULL,
> MAKEINTRESOURCE(IDR_TITLE_TRANSPARENT), "PNG");
>      objSrc = LoadResource(NULL, objResource);
>      objData = GlobalAlloc(GMEM_FIXED, SizeofResource(NULL, 
> objResource));
>      CopyMemory(LPVOID(objData), LockResource(objSrc), 
> SizeofResource(NULL,
> objResource));
>      CreateStreamOnHGlobal(objData, TRUE, &p_objStream);
>      m_imgAbout.Load(p_objStream);
>
> Why they create a CImage class and not enable it to load image data from 
> a resource like this:
>
>     m_imgAbout.Load(IDB_PNG_FILE);
>
> is beyond me.

As I said, I don't use MFC myself, but it seems to me that 
CImage::LoadFromResource would fit the bill. Did that not work for you?


> I've only been on this journey for a week now and already I can 
> understand
> why so many of my Windows programs crash. It isn't that the programmers 
> are
> bad, it's that Microsoft can't seem to get their act together. From what 
> TF
> said, I'm really expecting that to be true about DirectX as well.

If you think the regular WinAPI is bad, you'll really hate DirectX. It's 
more of the same, except now you have to deal with COM interfaces as well. 
If you intend to use DirectX, you'll want to write/find/steal some good 
wrappers to encapsulate the nitty-gritty stuff. I managed to get some 
fairly smooth usage out of DirectSound that way. DirectDraw/3D is a little 
tougher to wrap, mainly because those interfaces are pretty huge.


__
FE

Post a reply to this message