Subject: Odd Delphi 1.02=>2.01 bug(?) Date: Mon, 03 Feb 1997 23:04:09 -0500 From: imti@panix.com To: r.p.sterkenburg@dataweb.nl Reinier: Before getting started, I'd just like to say I think you're doing a great job with the Delphi Bug List website -- invaluable resource! May it continue until the very last bug is swatted...whenever that may be. Anyhow, here's a problem I ran into porting an app in 1.02 to 2.01. It's based on (stolen from, more like it) something in the first edition of Pacheco & Teixeira's DELPHI DEVELOPER'S GUIDE, a section titled "Subclassing Forms" that begins on p. 540, if you have your copy handy. Basically, the idea is to create "fake" notebook pages out of forms, bringing them up so they fill the area of a panel on your main form. The only essential difference between the book's approach and mine is that they create all their child forms at the beginning and store them in an array of TForm, whereas I, because of the great number of forms involved in the app (too many to admit!), create and free them as needed. So, the module they call MPGLOBAL.PAS I use unaltered as CHILDFRM.PAS. I've attached as simplified a version of all this as I can come up with. The problem is that, although this works just fine under 1.02, when compiled with 2.01 some strange things happen: (1) The form only appears on ALTERNATE clicks of my activating button. (2) Actually, (1) is true only if you change the code NOT to disable the button after clicking, which makes sense when the app is working correctly, OR you change the FormChild.Show call to either FormChild.Visible := True by itself or FormChild.BringToFront and then FormChild.Visible := True (note the odd order). (3) So again, the Show method no longer works. (4) Ah, but when it DOES appear, the child form has ignored the SetBounds call and appears too high on the main form! (5) One fix for that seems to be omitting the line assigning the child form's parent to be the panel on the main form: then the child form appears in the right position. (6) But alas, it also allows the child form to disappear if you do an Alt+Tab to something else and then return to the app -- not a good feature. In short, then, something(s) got quite screwed up in the translation from 16 to 32 bits, and I haven't a clue as to what it is or what the best way around it might be; and part of the reason I've letting you in on this now is that neither does Borland technical support, and they've been looking at it (??) for a week or so. If you or the Bug List's readers can figure out what's going on, I'd certainly be thankful -- and it's probably a terrific bug, too! Regards, Michael imti@panix.com