keith@uhccux.uhcc.hawaii.edu (Keith Kinoshita) (04/28/89)
I just ran into a problem while trying to compile an application with GetNewCWindow. I couldn't isolate the type conflict of operands error until I looked into the Windows.p interface file. According to that, GetNewCWindow returns a WindowPtr (NOT CWindowPtr) and the behind parameter is also a WindowPtr. Clearly this is a contradiction to IMV in whichboth the returning function and the behind variable should be a CWindowPtr. Can someone tell me wether this is an error with the Windows.p file or whether MPW v3.0 is actually built to pass WindowPtrs as opposed to CWindowPtrs? If it's a Windows.p error I'll just change that. Thanks in advance. -- Keith Kinoshita, UHCC Macintosh Programmer & Interactive Systems Assistant INTERNET: keith@uhccux.UHCC.HAWAII.EDU ARPA: uhccux!keith@nosc.MIL BITNET: keith@uhccux UUCP: ...!ucsd!nosc!uhccux!keith "Rise, Sir Pooh de Bear, most faithful of all my Knights." -Christopher Robin
shebanow@apple.com (Andrew Shebanow) (04/29/89)
The change in the definition of NewCWindow is not a bug: it was a decision the MPW group made (with some prodding) to make the libraries easier to use. There is almost no difference between a CWindowPtr and a WindowPtr, except for the use of a few fields which should never be accessed by your application (let QuickDraw do it!). If we had kept the definitions the way they were specified, you would have to do a cast anytime you called a trap that returned a WindowPtr as a result, or took a WindowPtr as an argument. Early versions of MPW 3.0 (alphas) actually had these routines defined to take CWindowPtrs, and it was a major pain in the butt. Count your blessings.... Andrew Shebanow MacDTS - All Opinions Are Mine, and Mine Alone -