How about creating a "helper" to handle recursion.
"Object a" on delete sends a call to "helper". Says, "Hey, I'm fixing to
off myself!" Can you take care of a little referencial trash when I'm
gone?"
then "helper" finishes the reference clipping on behalf of deceased "object
a".
- Origi
This is where Mozilla messes everything up. Try doing any type of
recursiving deleting in Mozilla and it will hack up since it follows
all pointers to objects and since we use recursive pointers like:
dlyr.doc.lyrobj = dlyr it goes crazy. I would love to see a solution
for Mozilla.
--
Robert
I've been looking at Bob's code in more detail and the insight is revealing
when compared to the base constructs of the DynAPI. The first thing I
noticed is his use of interfaces, inner classes and upcasting (very Java,
C++ ish) in the creation of Objects. This allows a little distance between
The attached file now makes KeyEvents work with both layers and
documents.
The event also bubles in the same fashion as mouse events now.
--
Michael Pemberton
[EMAIL PROTECTED]
ICQ: 12107010
key.zip
The one or two people who may actually volunteer should have no
trouble registering at sourceforge. It takes about 2 minutes. If they
want to help out all they have to do is register at sourceforge and
let an admin know so we can add them. Nothing is stopping anyone from
contributing.
Several o
I fully respect the time restrictions. but this just re-enforces the need for
"syncronization" between the various parties.
Pascal Bestebroer wrote:
> > This raises an interesting issue though. If bugs are meant to be reported
> to the site and patches are also meant to be posted there, who is
i think we just need to have a system where by people can accept the resposibility
of tackling a bug without the need to register as a developer and gain
direct access to CVS. I think could also do with all bug fixes being
posted to the list instead of being posted between the admins.
Richard B
> This raises an interesting issue though. If bugs are meant to be reported
to the site and patches are also meant to be posted there, who is in charge
of keeping it up to date. I see that there are some bugs listed there that
are obviously fixed (PathAnimation.run() bug for eg.).
the bug/patch
e.pageX refers to the mouses x position in the page. e.src.getPageX
refers to the leftmost x postion of the layer. So they are not the
same.
--
Robert Rainwater
On 3/11/2001, 5:33:06 AM EST, Michael wrote about "[Dynapi-Dev] Last attempt: Fixed
bug in events.js for IE 5.5 (I will not post
That's what the patches section of sourceforge is for. It would be
much more helpful if people used it. Its hard to wade through several
hundred emails to find one single patch. In fact, I'm sure I probaly
miss half of them.
--
Robert Rainwater
On 3/11/2001, 11:05:48 AM EST, Richard wrote
It might help if we actually use the functions like
assigned to, priority, etc that are available at source-forge.
Then we would at least know if someone had taken it
on themselves to look into the bug, and that it was not being
forgotten.
Also, I've seen so many fixes for all kinds of
thing
glad to see that it was solved.
This raises an interesting issue though. If bugs are meant to
be reported to the site and patches are also meant to be posted there,
who is in charge of keeping it up to date. I see that there are some
bugs listed there that are obviously fixed (PathAnimation.run
glad to see that it was solved.
This raises an interesting issue though. If bugs are meant to
be reported to the site and patches are also meant to be posted there,
who is in charge of keeping it up to date. I see that there are some
bugs listed there that are obviously fixed (PathAnimation.run
this.doPos();
should be:
e.getTarget().doPos();
does that make any difference? I haven't been able to test it bacause it is causing
problems in my version of the API. From what I could see, this is the only major
defect : ) in the code.
"Henrik Våglin" wrote:
> Ouch... yeah, even with
uhm..
hehe, Robert fixed this yesterday for the new code.. man, this is scary!
:-)
it was
indeed the problem :)
Pascal Bestebroer[EMAIL PROTECTED]http://www.dynamic-core.net
-Oorspronkelijk bericht-Van:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]Namens Michael
Pemberto
Ouch... yeah, even without actually kicking myself (the acrobatics yo concieve that
would hurt even more :) that was simple enough to hurt. Oh, well, I think I'll be
updating the ccreation widget pack keyevents now - finally with NS6 support :)
BTW any chance anybody would care to take a look o
I've done it. and you'll kick yourself at how simple the solution
was.
KeyEvent had to be renamed!!
and, yes, that was all that was needed. It seems that the event
object triggered by NS6 was creating a KeyEvent method but because we had
overwritten it with our own, it was sending out the wrong
No, this does not work. :-) The e.x and e.y vars contain coordinates of the
mouse relative to the complete page. To get these values relative to the
layer, you have to subtract the layer's x/y-position relative to the
complete page.
I have tried
this.x=is.ie?e.x-this.src.pageX:e.layerX;
this
is it possible to use e.pageX / e.pageY as set on the previous lines instead of
calling getPageX for the layer?
Robert Rainwater wrote:
> It's now in CVS.
>
> --
> Robert Rainwater
>
> On 3/10/2001, 1:09:40 PM EST, Christof wrote about "[Dynapi-Dev] Last attempt: Fixed
>bug in events.js for IE
19 matches
Mail list logo
