At 1:22 Uhr +0200 20.09.2003, Jakob Hede Madsen wrote:
I guess, at some point soon, I will fade away completely from these
lists, but maybe just for the social value keep 'hopping' at one.
Hi Jakob,
thank you for all the knowledge you shared with the community and the
things I learned from you.
19/09/2003 7:22:31 PM, Jakob Hede Madsen <[EMAIL PROTECTED]> wrote:
>You make me feel missed... you do all me miss right? ;-)
>I guess at least some of you must have noticed my 'absence'.
>
>I have just been on a two day 'camp trip'(or whatever it's called)
>with the whole "informatics" line of
>
>
> If you have a very complex app using Director, do you have any advice on
> tracking down MIAW/parent script leaks? We have various LDMs, MIAWs,
> parent scripts, etc, with data being shared between all of them, and we
> have some leaks that are being very difficult to track down.
My approac
On Friday, Sep 19, 2003, at 20:56 America/Chicago, Daniel Nelson wrote:
That's correct; the same thing happens with parent scripts as well. If
all their internal props aren't zeroed first,
An internal property only needs to be cleared if there is a circular
reference or in cases such as the one I
Howdy-Tzi wrote:
That may not be the best plan. That error surfaces because there's
something fundamentally wrong with the *code* trying to close or open
the MIAW file. It makes more sense to track down the location of the
code error (and this block a potential memory leak) than try to make the
>
>
> That's correct; the same thing happens with parent scripts as well. If
> all their internal props aren't zeroed first,
An internal property only needs to be cleared if there is a circular reference or in
cases such as the one I mentioned, in which an object reference points to another
obje
On Friday, Sep 19, 2003, at 19:38 America/Chicago, Bruce Mitchener
wrote:
Daniel Nelson wrote:
Just this morning, I solved a baffling bug related to this. If an
object in a MIAW passes its instance to an object held in another
window (or maybe if the window is referenced in some other window...I
Daniel Nelson wrote:
Just this morning, I solved a baffling bug related to this. If an
object in a MIAW passes its instance to an object held in another
window (or maybe if the window is referenced in some other window...I
didn't resolve which reference was actually causing the problem),
then all
Interesting. Late last month I asked the advice of a computer science professor whom
I followed through four courses back in college. He wrote two course books to taught
computer science through Java, yet he recommended that I stick with Director. He said
that Director has
enough of a user ba
On Friday, Sep 19, 2003, at 18:20 America/Chicago, Daniel Nelson wrote:
Just this morning, I solved a baffling bug related to this. If an
object in a MIAW passes its instance to an object held in another
window (or maybe if the window is referenced in some other window...I
didn't resolve which
At 14:19 -0500 19/09/03, Howdy-Tzi wrote:
Jakob's behavior is a groovy one, allowing MIAWs to close and forget
themselves without crashing director; however the original question
was whether a MIAW's variable needed to be zeroed after the MIAW was
closed and forgotten normally, or whether Direc
Just this morning, I solved a baffling bug related to this. If an object in a MIAW
passes its instance to an object held in another window (or maybe if the window is
referenced in some other window...I didn't resolve which reference was actually
causing the problem), then all
references to the
> When I test on my end the variable that used to refer to the window is set
> to zero, at least as far as put() is concerned the variable has a zero
> value. Are you sure the window continues to linger in memory? If so, how are
> you evidencing that it continues to exist? Just wanna be sure there
On Friday, Sep 19, 2003, at 13:23 America/Chicago, Agustín María
Rodríguez wrote:
Hi. Check this post from Jakob Hede Madsen:
Jakob's behavior is a groovy one, allowing MIAWs to close and forget
themselves without crashing director; however the original question was
whether a MIAW's variable n
At 11:07 Uhr -0700 19.09.2003, Thomas Higgins wrote:
(that don't currently exist AFAIK but may have in previous releases).
ah cool !!
when do WE get this version YOU are apparently using currently ?!
;-)
--
|||
a¿ex
--
[To remove yourself from this list, or to change to digest mode, go to
http:
At 11:04 AM -0700 9/19/03, you wrote:
> There is no need to void the variable, at least not from Director's point
of view. If you want to do it for the sake of cleanliness and/or
debugging, you could, but there's no technical need.
So there you have it, two directly contradictory answers. Aren'
Hi. Check this post from Jakob Hede Madsen:
"Here is a behavior which closes the MIAW it sits in, and properly
disposes of the MIAW, abiding common empirical experience of such
struggles.
Don't worry if you don't quite understand it, try it on anyway.
--miawCloserButtonBhv
property pWind
Super quick responses!
Thanks everyone. I appreciate it.
- Michael M.
[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 learnin
Kerry,
> Yes, you need to void it (or set it to 0, or "fido", or
> something else). Until
> you do, it contains the reference to the MIAW, and Director
> won't release its
> memory.
When I test on my end the variable that used to refer to the window is set
to zero, at least as far as put() is
Tom Higgins
Product Specialist - Director Team
Macromedia
...
MAX, the 2003 Macromedia User Conference
November 18-21, Salt Lake City, Utah
Register today at http://www.macromedia.com/go/max/
...
> -Original Message-
> From: Mendelsohn, Michael [mailto:[EMAIL PROTECTED]
> Sent: Friday
> There is no need to void the variable, at least not from Director's point
> of view. If you want to do it for the sake of cleanliness and/or
> debugging, you could, but there's no technical need.
So there you have it, two directly contradictory answers. Aren't these lists
wonderful?
Tab's p
On Friday, Sep 19, 2003, at 12:16 America/Chicago, Mendelsohn, Michael
wrote:
Hi list...
When closing a MIAW, is it necessary to void a global variable for it
after you do the close() and forget() methods on it?
Rather than void I use 0. I don't let uninitialized (void) variables
float around i
There is no need to void the variable, at least not from Director's point
of view. If you want to do it for the sake of cleanliness and/or
debugging, you could, but there's no technical need.
- Tab
At 01:16 PM 9/19/03, Mendelsohn, Michael wrote:
Hi list...
When closing a MIAW, is it necessary
> When closing a MIAW, is it necessary to void a global variable for it
> after you do the close() and forget() methods on it?
Yes, you need to void it (or set it to 0, or "fido", or something else). Until
you do, it contains the reference to the MIAW, and Director won't release its
memory.
Cor
Hi list...
When closing a MIAW, is it necessary to void a global variable for it
after you do the close() and forget() methods on it?
In other words...
-- gVow is a global referring to window("Garbage")
-- closing the MIAW:
gVow.close()
gVow.forget()
-- now, is this necessary:
gVow = VOID
-- .
25 matches
Mail list logo