awd@dbase.A-T.COM (Alastair Dallas) (08/22/90)
If you've tried to make the hex calculator program from Petzold's "Programming In Windows" book work, you've probably seen the same problem which I ran into this weekend. It seems to run, but launching another app after shutting down hexcalc typically bombs. I was really motivated to get it working, because I was using the trick it illustrates (using a dialog as an app's only window) in the app I'm trying to write. Both hexcalc and my app failed in the same way. After hours of trying anything I could think of, I happened to look in 'tips.txt' which comes with the SDK. There, in the contents, was an entry something like "Dialog windows: How to make Hexcalc work." In seconds, hexcalc and my app were working and I was a happy camper again. Therefore, two points: 1) Don't ignore tips.txt! (And, by extension, browsing through windows.h doesn't hurt, either.) And, 2) The answer to making dialogs work as windows is to make their cbWndExtra values (in the WNDCLASS structure) DLGWINDOWEXTRA, not 0. This adds 30 bytes to your window structures which Windows assumes is there. Every problem should be this easy to solve. I've hit some annoying little problems that've stopped me for hours (for example, sizing an edittext control so that it exactly fills a sizeable popup window), but solving them is so satisfying, I'd say that I'm overall quite happy with Windows--this from a certified Macintosh developer! /alastair/ Disclaimer> My employer knows not whereof I speak--I work in character-mode MS-DOS for them :-) and in exchange they give me UseNet and SDKs and Petzold books and leave me alone.
press@venice.SEDD.TRW.COM (Barry Press) (08/22/90)
In article <674@dbase.A-T.COM> awd@dbase.A-T.COM (Alastair Dallas) writes: >[....] >Therefore, two points: 1) Don't ignore tips.txt! (And, by extension, >browsing through windows.h doesn't hurt, either.) And, 2) The answer Yea, verily. For instance, here's another one. It used to be that you could use the hPrevInstance parameter passed to WinMain to see if another copy of the app way running, and if you chose to only allow one to run exit if it was non-zero. You can't do that any more. hPrevInstance seems to hang around non-zero for at least a while (standard mode for the instances I'm seeing) after the previous copy is terminated. You also have to pay attention to the change that a second RegisterClass call while the class still exists (e.g. if hPrevInstance is non-zero) will FAIL. -- Barry Press Internet: press@venice.sedd.trw.com
rogerson@PEDEV.Columbia.NCR.COM (Dale Rogerson) (08/24/90)
In article <779@venice.SEDD.TRW.COM> press@venice.sedd.trw.com (Barry Press) writes: >Yea, verily. For instance, here's another one. It used to be that you could >use the hPrevInstance parameter passed to WinMain to see if another copy of >the app was running, and if you chose to only allow one to run exit if it was >non-zero. You can't do that any more. hPrevInstance seems to hang around >non-zero for at least a while(standard mode for the instances I'm seeing) after >the previous copy is terminated. You also have to pay attention to the change >that a second RegisterClass call while the class still exists (e.g. if >hPrevInstance is non-zero) will FAIL. I ran into some of these problems with my "practice" C++ class library. Ideally, I would like to be able to create a window with something like: SimpleWindow myWind; I would hope that this would do all of the needed Class registration in the contructor. One thing a good Windows class library should do is remove some of the "order" specific requirements of Windows programming. So I do not want to require the user of the SimpleWindow class to only create windows in the WinMain section of the program and also check hPrevInstance. Even if the constructor checks the hPrevInstance variable, it is only valid during WinMain. The solution I am using is to call the Windows function: BOOL GetClassInfo( hInstance, lpClassName, lpWndClass ); // This is from memory so check your 3.0 SDK. This function will get the WNDCLASS memory structure with the class name pointer to by lpClassName and place it into the lpWndClass buffer. It returns FALSE if it can't find the class. This should make up for some of the problems with hInstance. I have not seen the other problem you mentioned with hPrevInstance staying non-zero. I will have to look into this. -----Dale Rogerson-----