home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / os / mswindo / programm / tools / 696 < prev    next >
Encoding:
Internet Message Format  |  1992-08-12  |  1.5 KB

  1. Path: sparky!uunet!sun-barr!decwrl!deccrl!news.crl.dec.com!pa.dec.com!nntpd2.cxo.dec.com!nntpd.lkg.dec.com!amber!jisuzu.athena.lkg.dec.com!mills
  2. From: mills@athena.lkg.dec.com (George Mills)
  3. Newsgroups: comp.os.ms-windows.programmer.tools
  4. Subject: Re: Has anyone seen this OWL problem?
  5. Message-ID: <mills.713642422@jisuzu.athena.lkg.dec.com>
  6. Date: 12 Aug 92 18:00:22 GMT
  7. References: <1992Aug12.080756.28348@leland.Stanford.EDU>
  8. Lines: 23
  9.  
  10. kmh@leland.Stanford.EDU (khanhmy hoang) writes:
  11.  
  12.  
  13. >    My program using Borland's OWL (statically linked) worked perfectly
  14. >    in Windows 3.0 and 3.1 when built using BC++ 3.0.
  15. >    When built using BC++ 3.1, the program crashes in Windows 3.0 but
  16. >    still works fine in Windows 3.1.
  17.  
  18. >    I did define WIN30 during compilation, and this should give me backward
  19. >    compatibility. But this is not what I get.
  20.  
  21. >    Specifically, the Attr data member of a TListBox control has valid
  22. >    values in Windows 3.1 but has 0's in Windows 3.0 (as watched in TDW).
  23. >    Apparently Attr has an invalid address in 3.0 and this gives me the UAE.
  24.  
  25. >    Your help is much appreciated.
  26.  
  27. I've been having weirdness with TC++ 3.1 for 3.0 windows but not on the
  28. TListBox. All works perfectly well on 3.1 windows. Some MetaFile calls
  29. and some BitBlt's just unexplainably UAE. The problem is more releated to
  30. 3.0 being less robust than 3.1. I suspect perhaps in both yours and my case
  31. that there is a minor bug in our code (or windows 3.0) that is floating around
  32. and a different compiler can hide or show it up.
  33.