Hi Robert, Downloaded and tried out your both examples. Each of them simply proved your assumptions: they absolutely break. Executed each of the tests, made the projector.
D8.5.1, Win2K Cheers Peter ----- Original Message ----- From: "Robert Tweed" <[EMAIL PROTECTED]> To: "DirGames-L" <[EMAIL PROTECTED]>; "Lingo-L" <[EMAIL PROTECTED]>; "Direct-L" <[EMAIL PROTECTED]> Sent: Thursday, July 29, 2004 8:07 AM Subject: <lingo-l> XPOST: Bugs, bugs, bugs! > Originally posted on macromedia.director.lingo - replies to the NG where > possible, to keep everything in one place. > ------ > > Well, it's bug announcing time again. This message contains details of two > new (AFAIK) bugs. I'd be grateful if people could independently verify the > bugs on their systems before I forward this thread on to Macromedia. Please > say what results you get, what version of Director you are using, and what > your OS is. > > --[ BUG 1 ]-- > > Since Ziggi tested for the /new/ bug in the XML parser that had previously > been spotted, but was unverified, I can confirm that we have *both* now > independently verified the bug. I did some slightly more extensive tests > that Ziggi's, so I will give a bit more information. The repro movie is > here: > > http://www.killingmoon.com/director/bugs/xml_parser/xml_test.dir > (download: do not attempt to run from website; best run as a projector) > > My results (Windows 2000 only, so far): > > Test D85 MX2004 > 1 no OK > 2a no no > 2b no no > 3a OK OK > 3b no OK > > Details of these tests are in the movie. > > What this means is that in D85, you can call makeList as often as you like, > although it's unlikely you'll ever want to call it more than once without > parsing a new document. In DMX2004, the parseString memory leak *has* been > fixed, so you can parse as many XML documents as you like, and as long as > you stick to makeList and accessing the parsed XML as a list only, there is > no memory leak. However, if you access any element of the XML parser object, > such as child[1], etc., then this causes a memory leak. In short, if using > DMX2004, use makeList, do not access nodes through the XML object. > > --[ BUG 2 ]-- > > In doing this test, I turned up another, unrelated bug. It seems that if you > quit a movie by hitting the [X] button in Windows, endSprite is called in > the *middle* of whatever handler is running at the time, then control goes > back to that function (even though objects may have been destroyed or data > invalidated). As far as I can tell, none of the following causes this bug: > pressing ESC; pressing CTRL+F4; double-clicking on the control button. The > following movie demonstrates the problem: > > http://www.killingmoon.com/director/bugs/endsprite/endsprite_test.dir > (MUST be run as a projector to demonstrate the bug) > > Note: There are fairly detailed comments in the movie. > > BTW, I'd be interested to know if this is a Windows only thing, or even a > Win2K thing. I've verified the problem with D851 and the MX2004 trial on > Windows 2000. I'm pretty sure I've seen this bug occur intermittently with > CD-ROM projects in the past, but it's been so intermittent I haven't been > able to tell that this was what was causing it. > > - Robert > > [To remove yourself from this list, or to change to digest mode, go to http://www.penworks.com/lingo-l.cgi To post messages to the list, email [EMAIL PROTECTED] (Problems, email [EMAIL PROTECTED]). Lingo-L is for learning and helping with programming Lingo. Thanks!] > > [To remove yourself from this list, or to change to digest mode, go to http://www.penworks.com/lingo-l.cgi To post messages to the list, email [EMAIL PROTECTED] (Problems, email [EMAIL PROTECTED]). Lingo-L is for learning and helping with programming Lingo. Thanks!]
