dynapi-dev — List related to the current DynAPI Core development

Re: [Dynapi-Dev] This is my war

[Jordi 'I. M. <jmi...@or...>]

OK. This is the status of the events: I think they all work now but there is one case: imagine layer a, layerb child
of a and layer c child of b. All children are 0,0 placed so there's a common corner. Now do a mouseover on that
corner. What happens ?

IE sends the mouseover event only to the upper-most layer, that's 'c'. Then the API kicks in and bubbles it if you
allowed it to bubble. Everything works as expected. Now let's see what does netscape do: well all layers receive
their own mouseover event. It makes sense somehow because all layers were enetered by the mouse. Having this in mind,
the EventMethod does not bubble mouseover and mouseouts in NS because they will already be sent to the other layers,
then introciing  this line at the end of Eventmethod (just before bubbling):

 if (is.ns && (e.type=="mouseover" || e.type=="mouseout")) return false;

That is.ns was introduced by me because it was blocking IEs events (remember rollovers not happening in some menu
widgets ? )

But the events are received by layers from parent to child, not child to parent as we'd want. Therefore mouseovers
work in a different way IE-NS. What we should do is cancel a parent's mouseovers-mouseouts if we detect that that
same event affected one childlayer and have the child most inside of the hierarchy that received that mouseover
execute it and bubble it up.

I'm braindead, maybe tommorrow. I'll update CVS with what I have so far. Use at your own risk but it should be the
best version to date.

PS: I understood those lines:

if (e.type=="mouseout" && this.contains(e.toElement)) return true;
if (e.type=="mouseover" && this.contains(e.fromElement)) return true;

They must be there.

Jordi 'IlMaestro' Ministral wrote:

> Ok, eventlisteners can be added before layer creation again. Looks that I got IE5.5 to obey me as a marine, ( yes
> sir i'm a piece o'shit sir !! ) and now I only need to fix some stupid NS issues. Maybe I did cause some of these
> errors myself while fixing others but anyway.
>
> I'm commented out these lines:
>
> if (e.type=="mouseout" && this.contains(e.toElement)) return true;
> if (e.type=="mouseover" && this.contains(e.fromElement)) { return true; }
>
> which were causing trouble. If they need to be there please the author tell me why. I can't think of any
> circunstance where they should be in there.
>
> Jordi 'IlMaestro' Ministral wrote:
>
> > I think I'm almost there this time. The fix I posted on CVS was OK, but was not enought. It seems that adding
> > a listener before the layer is added to the document causes mouseover events to get lost. Click events work,
> > though.
> >
> > Weird as usual
> >
> > Jordi 'IlMaestro' Ministral wrote:
> >
> > > I'm discovering lots of things about the event model now that we have the precreation code. I don't really
> > > know if it has always been the same but I never realized.
> > >
> > > If you could just have a little patience I think I can beat it.
> > >
> > > Jordi 'IlMaestro' Ministral wrote:
> > >
> > > > I'm missing events... did I screw something ? First I thought but then going back to the latest code (
> > > > before my modifications ) I am missing those same events. Ohh please just a little luck from time to
> > > > time !!!!!
> > > >
> > > > In NS you can apply the same "for (each image in doc) img.lyrobj = myself" event trick to the links
> > > > array.
> > > >
> > > > Jordi 'IlMaestro' Ministral wrote:
> > > >
> > > > > I have updated CVS with a new events.js that should fix IEs event problems. All the example files
> > > > > worked fine. This is what happened ( at least this is something I found, maybe there are still
> > > > > other issues ):
> > > > >
> > > > > - All browser events in DynAPI are captured and passed to the same EventMethod. This eventMethod
> > > > > identifyes the physical layer, cancels browser event, searches for the appropiate DynmLayer object
> > > > > and invokes its event.
> > > > >
> > > > > - In IE, in order to access the DynLayer object we use the lyrobj property of the DIV itself. This
> > > > > property is set when creating a layer so from code executed within the DIV's scope we can still get
> > > > > to our DynLayer obj. The problem with our contents was that when clicking on a text, most of the
> > > > > times the srcElement of the event was not the DIV but a FONT, TD, TR, TABLE, UL,... element. That
> > > > > element did not have a pointer to the dynlayer and thus the API could not route the event properly.
> > > > >
> > > > > - This issue was partially solved for images by doing:
> > > > >
> > > > > if (is.ie) for (i in dlyr.elm.all.tags("img")) dlyr.elm.all.tags("img")[i].lyrobj=dlyr;
> > > > >
> > > > > So images had a pointer to the layer aswell. This we would have needed to do to all elements in our
> > > > > content, somethig really painful. Instead, I added this line inside eventmethod.
> > > > >
> > > > >  for(;is.ie && !realsrc.lyrobj && realsrc.parentElement &&
> > > > > realsrc.parentElement!=realsrc;realsrc=realsrc.parentElement);
> > > > >
> > > > > Which actually makes realsrc travel IE's object hierarchy until we find the lyrobj reference. By
> > > > > doing so I fixed events in IE5 and 5.5. I'm not that sure everything is fine now, but it is an
> > > > > improvement.
> > > > >
> > > > > There are several lines in that method such as that
> > > > >
> > > > > if (e.type=="mouseover" || e.type=="mouseout") return false;
> > > > >
> > > > > just before the bubbleEvent() call that I don't understand but I prefer not to touch them.
> > > > >
> > > > > By the way, it seems that when clicking on a selectable text, NS does not fire a click event.
> > > > > Mousedown and mouseup are fired, but click isn't. We could fire it manually but then when clicking
> > > > > outside a text we would get two onclicks.
> > > > >
> > > > > Tell me if I broke something. Sure I did.
> > > > >
> > > > > Cya
> > > > >
> > > > > _______________________________________________
> > > > > Dynapi-Dev mailing list
> > > > > Dyn...@li...
> > > > > http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
> > > >
> > > > _______________________________________________
> > > > Dynapi-Dev mailing list
> > > > Dyn...@li...
> > > > http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
> > >
> > > _______________________________________________
> > > Dynapi-Dev mailing list
> > > Dyn...@li...
> > > http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
> >
> > _______________________________________________
> > Dynapi-Dev mailing list
> > Dyn...@li...
> > http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/mailman/listinfo/dynapi-dev

Re: [Dynapi-Dev] DynAPI Reference...

[Richard :o <ma...@ri...>]

Hi,
Basically you're effort is great, but:
>the list takes 23 seconds to build on ...
That would be totally useless as a tool in that case, and you'd have to use
something else than treewidget.
But that's not the case, either you didn't read the documentation properly,
or I didn't explain it very well.
IE uses a lot of memory if it has to render a lot of layers, and it doesn't
flush the memory on reload.
So the point of my tree widget is, that the contentLayers, ie the ones with
all the links in them, are written together on one layer, only the nodes use
their own layer.
So once you have added  a node to the tree like this:

    main=DynRef.add('Dynapi');

you add all your links like this:

    main.addNodeContent("setLibraryPath")
    main.addNodeContent("mountplugin")
    main.addNodeContent("include")
    main.addNodeContent("onload")
    main.addNodeContent("onunload")
    main.addNodeContent("onresize")

And then tell the tree you've finished adding links like this:

    main.closeContent()

Now   main.addNodeContent("onresize")  has two more parameters, one is the
url, and one the image,
so in this case it might be nice to show some information about the node
onclick, instead of loading a link:

main.addNodeContent("onresize","javascript: showInfo(\'This event is'
+' fired when the browser is resized, and should recreateAll in NS, '
+'but doesn\'t always\'),"images/mainNode.gif");
../..
../..
etc

function showinfo(node){
infoLayer.setHTML(node)
}

So the infoLayer should display the info on each node, and there would be a
little icon infront of the link.
If you get what I mean.

Another thing is that you're using the latest release I suspect, instead of
the latest snapshot (or my one), so you are documenting some extensions that
don't exist any more, like sprite.js.
That's the down-side of a hard-coded reference, it's already out of date on
the day of release.
That's why I made DynAPIDiagnose, which is included on each example, and
gives you all the parameters available real-time. the problem is it gives
all
the browser-native properties as well, and I haven't as yet found how to
limit it to only DynAPI methods. It's also very buggy, I'll be rewriting it
with the fast-treeview widget once I understand all this precreation stuff,
and the new widgetmodel.

Of course if you are willing to update it regularly, I'd be more than happy
to put it on the site (or mirror it) if you want.

Oh, I almost forgot to say, I already rewrote it with the correct code, it
renders in about 4 seconds now (download time not included)
check here:

http://www.resass.f2s.com/?menu=examples&node=10

If you decide to finish this job, it might be worth considering if you can't
include the values from text files or something (or through php), so you
don't have to edit your html each time. This is what I did for my "examples"
tree, all the code is written on the fly by a php script, which checks the
contents of directories on the server, and adds the nodes it needs.

Cheers,
Richard  :o

ma...@ri...
www.richardinfo.com
(Everything running on, and ported to the 19/12/2000 snapshot of DynAPI2)

----- Original Message -----
From: "Nuno Ferreira" <nun...@wi...>
To: <dyn...@li...>
Sent: Thursday, January 11, 2001 5:52 PM
Subject: [Dynapi-Dev] DynAPI Reference...


> Hi people,
>
> Like I said in a previous posting, I started to compile
> a list of DynAPI methods and functions (and afterwords I
> will add the properties).
>
> For now I only have a list, based on the latest snapshot,
> using Richard's Fast Tree Widget.
>
> What I need now, is for you people in the know, to take
> a look a that list, and tell me about mistakes or incorrections.
>
> Also, I need some comments as to what items should be excluded
> from the list due to being internal methods or functions, because
> the main goal of the reference is to help beginners and not cause
> even more confusion.
>
> Comments are welcome!
>
> Of course, a downloadable version in PDF or TXT will be created
> when the deed is done :)
>
> The list is at http://www.wiz.pt/users/nf/dynapiref/dynapi_ref.html
>
>
> Best,
>
> NunoF
>
> ps. Richard, the list takes 23 seconds to build on my computer, probably
> because that's a lot of nodes, but each time I do a reload it takes longer
> each reload (i'm using IE 5.5 on Win2k).
> I concede it can be a mistake on my part, but it sure is weird, cause when
> I close all browser windows, open a new one and reload, it cames back to
> 23 seconds...
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
> ____________________________________________________________
> Get your free domain name and domain-based e-mail from
> Namezero.com. New!  Namezero Plus domains now available.
> Find out more at: http://www.namezero.com
>

RE: [Dynapi-Dev] DynAPI Reference...

[Nuno F. <nun...@wi...>]

	>Nice. The effect you mention has nothing to do with DynAPI. It is a
browser
	>issue. Hopefully using the new precreation code will speed things up.
	>Moreover, the SMI menu interface I just finished should be able to
optimize
	>this alot.

Send it on, Maestro!
I'm always game to try new stuff, particulary if it's faster! :)
NunoF

Re: [Dynapi-Dev] Issues, remaining

[Marc v. L. <ja...@ja...>]

At 12:52 10/01/2001, you wrote:
>Is there any other European guy/girl in this list appart from Pascal and 
>me ? I
>find it hard to keep a conversation when I'm awaken and then each morning 
>I find
>40 mails waiting for me....


Livre in France (warm south, in Nice), but I'm Dutch (as Pascal).
Using DynAPI2 for a web site to come. When some widgets I wrote are good 
enough (especially some (too) heavy-weighted collapseMenus (which are more 
like the one found in Dan's DynAPI 1) and more commented, I will post them...
Until then, I'm still sorting all those mails in the morning.


Marc

Re: [Dynapi-Dev] This is my war

[Jordi 'I. M. <jmi...@or...>]

Ok, eventlisteners can be added before layer creation again. Looks that I got IE5.5 to obey me as a marine, ( yes
sir i'm a piece o'shit sir !! ) and now I only need to fix some stupid NS issues. Maybe I did cause some of these
errors myself while fixing others but anyway.

I'm commented out these lines:

if (e.type=="mouseout" && this.contains(e.toElement)) return true;
if (e.type=="mouseover" && this.contains(e.fromElement)) { return true; }

which were causing trouble. If they need to be there please the author tell me why. I can't think of any
circunstance where they should be in there.


Jordi 'IlMaestro' Ministral wrote:

> I think I'm almost there this time. The fix I posted on CVS was OK, but was not enought. It seems that adding
> a listener before the layer is added to the document causes mouseover events to get lost. Click events work,
> though.
>
> Weird as usual
>
> Jordi 'IlMaestro' Ministral wrote:
>
> > I'm discovering lots of things about the event model now that we have the precreation code. I don't really
> > know if it has always been the same but I never realized.
> >
> > If you could just have a little patience I think I can beat it.
> >
> > Jordi 'IlMaestro' Ministral wrote:
> >
> > > I'm missing events... did I screw something ? First I thought but then going back to the latest code (
> > > before my modifications ) I am missing those same events. Ohh please just a little luck from time to
> > > time !!!!!
> > >
> > > In NS you can apply the same "for (each image in doc) img.lyrobj = myself" event trick to the links
> > > array.
> > >
> > > Jordi 'IlMaestro' Ministral wrote:
> > >
> > > > I have updated CVS with a new events.js that should fix IEs event problems. All the example files
> > > > worked fine. This is what happened ( at least this is something I found, maybe there are still
> > > > other issues ):
> > > >
> > > > - All browser events in DynAPI are captured and passed to the same EventMethod. This eventMethod
> > > > identifyes the physical layer, cancels browser event, searches for the appropiate DynmLayer object
> > > > and invokes its event.
> > > >
> > > > - In IE, in order to access the DynLayer object we use the lyrobj property of the DIV itself. This
> > > > property is set when creating a layer so from code executed within the DIV's scope we can still get
> > > > to our DynLayer obj. The problem with our contents was that when clicking on a text, most of the
> > > > times the srcElement of the event was not the DIV but a FONT, TD, TR, TABLE, UL,... element. That
> > > > element did not have a pointer to the dynlayer and thus the API could not route the event properly.
> > > >
> > > > - This issue was partially solved for images by doing:
> > > >
> > > > if (is.ie) for (i in dlyr.elm.all.tags("img")) dlyr.elm.all.tags("img")[i].lyrobj=dlyr;
> > > >
> > > > So images had a pointer to the layer aswell. This we would have needed to do to all elements in our
> > > > content, somethig really painful. Instead, I added this line inside eventmethod.
> > > >
> > > >  for(;is.ie && !realsrc.lyrobj && realsrc.parentElement &&
> > > > realsrc.parentElement!=realsrc;realsrc=realsrc.parentElement);
> > > >
> > > > Which actually makes realsrc travel IE's object hierarchy until we find the lyrobj reference. By
> > > > doing so I fixed events in IE5 and 5.5. I'm not that sure everything is fine now, but it is an
> > > > improvement.
> > > >
> > > > There are several lines in that method such as that
> > > >
> > > > if (e.type=="mouseover" || e.type=="mouseout") return false;
> > > >
> > > > just before the bubbleEvent() call that I don't understand but I prefer not to touch them.
> > > >
> > > > By the way, it seems that when clicking on a selectable text, NS does not fire a click event.
> > > > Mousedown and mouseup are fired, but click isn't. We could fire it manually but then when clicking
> > > > outside a text we would get two onclicks.
> > > >
> > > > Tell me if I broke something. Sure I did.
> > > >
> > > > Cya
> > > >
> > > > _______________________________________________
> > > > Dynapi-Dev mailing list
> > > > Dyn...@li...
> > > > http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
> > >
> > > _______________________________________________
> > > Dynapi-Dev mailing list
> > > Dyn...@li...
> > > http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
> >
> > _______________________________________________
> > Dynapi-Dev mailing list
> > Dyn...@li...
> > http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/mailman/listinfo/dynapi-dev

RE: [Dynapi-Dev] new f.a.q.

[Pascal B. <pa...@dy...>]

lol..

I took the "cheap" way, and updated the f.a.q. :-)
forgot the http:// bit :-)


Pascal Bestebroer
pa...@dy...
http://www.dynamic-core.net

> -----Oorspronkelijk bericht-----
> Van: dyn...@li...
> [mailto:dyn...@li...]Namens Richard :o
> Verzonden: donderdag 11 januari 2001 17:10
> Aan: dyn...@li...
> Onderwerp: Re: [Dynapi-Dev] new f.a.q.
>
>
> Hi,
> Thanks for adding a link to my site, there is however an error in
> the link,
> it refers to:
> http://www.dynamic-core.net/core/files/www.richardinfo.com
> instead of:
> http://www.richardinfo.com
> Now of course if you want to offer me free reliable webspace, we
> could keep
> the link like that ;o)
>
> Cheers,
> Richard  :o
>
> ma...@ri...
> www.richardinfo.com
> (Everything running on, and ported to the 19/12/2000 snapshot of DynAPI2)
>
> ----- Original Message -----
> From: "Pascal" <pb...@oi...>
> To: <dyn...@li...>
> Sent: Thursday, January 11, 2001 4:26 PM
> Subject: [Dynapi-Dev] new f.a.q.
>
>
> > Just uploaded a new modified f.a.q. (see
> > http://www.dynamic-core.net/core/files/faq.dynapi2.html)
> > did some quick editing and added a few new topics. I'll upload it to CVS
> > tonight.
> >
> > Planning on adding more to section 6 about working with the DynAPI..
> > so any questions I should add?
> >
> > cya,
> >
> > Pascal Bestebroer (pb...@oi...)
> > Software ontwikkelaar
> > Oberon Informatiesystemen b.v.
> > http://www.oibv.com
> >
> >
> > _______________________________________________
> > Dynapi-Dev mailing list
> > Dyn...@li...
> > http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
> > ____________________________________________________________
> > Get your free domain name and domain-based e-mail from
> > Namezero.com. New!  Namezero Plus domains now available.
> > Find out more at: http://www.namezero.com
> >
>
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
>

RE: [Dynapi-Dev] new f.a.q.

[Pascal B. <pa...@dy...>]

the DynObject is one of those things I just added to my own distribution
(only since the last release). I also believe it should be in the official
distro, but it requires some work and then testing to see if everything is
modified correctly (as I have done with my own code.. which took quite some
time :)

Ofcourse it's easier now that I know where the important problems can occur,
but I think we should focus on getting the current release out.. and then
implement that idea (if the other dev's agree).

cya,

Pascal Bestebroer
pa...@dy...
http://www.dynamic-core.net

> -----Oorspronkelijk bericht-----
> Van: dyn...@li...
> [mailto:dyn...@li...]Namens Jared Nuzzolillo
> Verzonden: donderdag 11 januari 2001 17:10
> Aan: dyn...@li...
> Onderwerp: Re: [Dynapi-Dev] new f.a.q.
>
>
> maybe I missed this in the last 400 mails, and I'm sure its been properly
> discussed, but can someone fill me in on why we are not using the
> Dynobject
> scheme Pascal came up with. What is the benefit of not doing it that way?
> I've really been trying hard to go through the code and get a
> better idea on
> how it all works, and it just seems that pascal's technique makes more
> sense...
>
> -jaredn
>
> btw, this crashes netscape 6 for some reason...i wonder why:
>
> gd=document.getElementById
> t=gd("a_valid_divs_id")
>
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
>

Re: [Dynapi-Dev] DynAPI Reference...

[Jordi 'I. M. <jmi...@or...>]

Nice. The effect you mention has nothing to do with DynAPI. It is a browser
issue. Hopefully using the new precreation code will speed things up.
Moreover, the SMI menu interface I just finished should be able to optimize
this alot.



Nuno Ferreira wrote:

> Hi people,
>
> Like I said in a previous posting, I started to compile
> a list of DynAPI methods and functions (and afterwords I
> will add the properties).
>
> For now I only have a list, based on the latest snapshot,
> using Richard's Fast Tree Widget.
>
> What I need now, is for you people in the know, to take
> a look a that list, and tell me about mistakes or incorrections.
>
> Also, I need some comments as to what items should be excluded
> from the list due to being internal methods or functions, because
> the main goal of the reference is to help beginners and not cause
> even more confusion.
>
> Comments are welcome!
>
> Of course, a downloadable version in PDF or TXT will be created
> when the deed is done :)
>
> The list is at http://www.wiz.pt/users/nf/dynapiref/dynapi_ref.html
>
> Best,
>
> NunoF
>
> ps. Richard, the list takes 23 seconds to build on my computer, probably
> because that's a lot of nodes, but each time I do a reload it takes longer
> each reload (i'm using IE 5.5 on Win2k).
> I concede it can be a mistake on my part, but it sure is weird, cause when
> I close all browser windows, open a new one and reload, it cames back to
> 23 seconds...
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/mailman/listinfo/dynapi-dev

[Dynapi-Dev] DynAPI Reference...

[Nuno F. <nun...@wi...>]

Hi people,

Like I said in a previous posting, I started to compile
a list of DynAPI methods and functions (and afterwords I
will add the properties).

For now I only have a list, based on the latest snapshot,
using Richard's Fast Tree Widget.

What I need now, is for you people in the know, to take
a look a that list, and tell me about mistakes or incorrections.

Also, I need some comments as to what items should be excluded
from the list due to being internal methods or functions, because
the main goal of the reference is to help beginners and not cause
even more confusion.

Comments are welcome!

Of course, a downloadable version in PDF or TXT will be created
when the deed is done :)

The list is at http://www.wiz.pt/users/nf/dynapiref/dynapi_ref.html


Best,

NunoF

ps. Richard, the list takes 23 seconds to build on my computer, probably
because that's a lot of nodes, but each time I do a reload it takes longer
each reload (i'm using IE 5.5 on Win2k).
I concede it can be a mistake on my part, but it sure is weird, cause when
I close all browser windows, open a new one and reload, it cames back to
23 seconds...

Re: [Dynapi-Dev] This is my war

[Jordi 'I. M. <jmi...@or...>]

I think I'm almost there this time. The fix I posted on CVS was OK, but was not enought. It seems that adding
a listener before the layer is added to the document causes mouseover events to get lost. Click events work,
though.

Weird as usual

Jordi 'IlMaestro' Ministral wrote:

> I'm discovering lots of things about the event model now that we have the precreation code. I don't really
> know if it has always been the same but I never realized.
>
> If you could just have a little patience I think I can beat it.
>
> Jordi 'IlMaestro' Ministral wrote:
>
> > I'm missing events... did I screw something ? First I thought but then going back to the latest code (
> > before my modifications ) I am missing those same events. Ohh please just a little luck from time to
> > time !!!!!
> >
> > In NS you can apply the same "for (each image in doc) img.lyrobj = myself" event trick to the links
> > array.
> >
> > Jordi 'IlMaestro' Ministral wrote:
> >
> > > I have updated CVS with a new events.js that should fix IEs event problems. All the example files
> > > worked fine. This is what happened ( at least this is something I found, maybe there are still
> > > other issues ):
> > >
> > > - All browser events in DynAPI are captured and passed to the same EventMethod. This eventMethod
> > > identifyes the physical layer, cancels browser event, searches for the appropiate DynmLayer object
> > > and invokes its event.
> > >
> > > - In IE, in order to access the DynLayer object we use the lyrobj property of the DIV itself. This
> > > property is set when creating a layer so from code executed within the DIV's scope we can still get
> > > to our DynLayer obj. The problem with our contents was that when clicking on a text, most of the
> > > times the srcElement of the event was not the DIV but a FONT, TD, TR, TABLE, UL,... element. That
> > > element did not have a pointer to the dynlayer and thus the API could not route the event properly.
> > >
> > > - This issue was partially solved for images by doing:
> > >
> > > if (is.ie) for (i in dlyr.elm.all.tags("img")) dlyr.elm.all.tags("img")[i].lyrobj=dlyr;
> > >
> > > So images had a pointer to the layer aswell. This we would have needed to do to all elements in our
> > > content, somethig really painful. Instead, I added this line inside eventmethod.
> > >
> > >  for(;is.ie && !realsrc.lyrobj && realsrc.parentElement &&
> > > realsrc.parentElement!=realsrc;realsrc=realsrc.parentElement);
> > >
> > > Which actually makes realsrc travel IE's object hierarchy until we find the lyrobj reference. By
> > > doing so I fixed events in IE5 and 5.5. I'm not that sure everything is fine now, but it is an
> > > improvement.
> > >
> > > There are several lines in that method such as that
> > >
> > > if (e.type=="mouseover" || e.type=="mouseout") return false;
> > >
> > > just before the bubbleEvent() call that I don't understand but I prefer not to touch them.
> > >
> > > By the way, it seems that when clicking on a selectable text, NS does not fire a click event.
> > > Mousedown and mouseup are fired, but click isn't. We could fire it manually but then when clicking
> > > outside a text we would get two onclicks.
> > >
> > > Tell me if I broke something. Sure I did.
> > >
> > > Cya
> > >
> > > _______________________________________________
> > > Dynapi-Dev mailing list
> > > Dyn...@li...
> > > http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
> >
> > _______________________________________________
> > Dynapi-Dev mailing list
> > Dyn...@li...
> > http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/mailman/listinfo/dynapi-dev

Re: [Dynapi-Dev] new f.a.q.

[Jared N. <ja...@aa...>]

as a followup to my last post:

gd=window.alert
t=gd("a_valid_divs_id")

does not crash NS6, while:

gd=document.createElement
t=gd("DIV")

does

Re: [Dynapi-Dev] new f.a.q.

[Jared N. <ja...@aa...>]

maybe I missed this in the last 400 mails, and I'm sure its been properly
discussed, but can someone fill me in on why we are not using the Dynobject
scheme Pascal came up with. What is the benefit of not doing it that way?
I've really been trying hard to go through the code and get a better idea on
how it all works, and it just seems that pascal's technique makes more
sense...

-jaredn

btw, this crashes netscape 6 for some reason...i wonder why:

gd=document.getElementById
t=gd("a_valid_divs_id")

Re: [Dynapi-Dev] new f.a.q.

[Richard :o <ma...@ri...>]

Hi,
Thanks for adding a link to my site, there is however an error in the link,
it refers to:
http://www.dynamic-core.net/core/files/www.richardinfo.com
instead of:
http://www.richardinfo.com
Now of course if you want to offer me free reliable webspace, we could keep
the link like that ;o)

Cheers,
Richard  :o

ma...@ri...
www.richardinfo.com
(Everything running on, and ported to the 19/12/2000 snapshot of DynAPI2)

----- Original Message -----
From: "Pascal" <pb...@oi...>
To: <dyn...@li...>
Sent: Thursday, January 11, 2001 4:26 PM
Subject: [Dynapi-Dev] new f.a.q.


> Just uploaded a new modified f.a.q. (see
> http://www.dynamic-core.net/core/files/faq.dynapi2.html)
> did some quick editing and added a few new topics. I'll upload it to CVS
> tonight.
>
> Planning on adding more to section 6 about working with the DynAPI..
> so any questions I should add?
>
> cya,
>
> Pascal Bestebroer (pb...@oi...)
> Software ontwikkelaar
> Oberon Informatiesystemen b.v.
> http://www.oibv.com
>
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
> ____________________________________________________________
> Get your free domain name and domain-based e-mail from
> Namezero.com. New!  Namezero Plus domains now available.
> Find out more at: http://www.namezero.com
>

[Dynapi-Dev] new f.a.q.

[Pascal <pb...@oi...>]

Just uploaded a new modified f.a.q. (see
http://www.dynamic-core.net/core/files/faq.dynapi2.html)
did some quick editing and added a few new topics. I'll upload it to CVS
tonight.

Planning on adding more to section 6 about working with the DynAPI..
so any questions I should add?

cya,

Pascal Bestebroer (pb...@oi...)
Software ontwikkelaar
Oberon Informatiesystemen b.v.
http://www.oibv.com

RE: Re[2]: [Dynapi-Dev] Making progress on a Java gui tool

[Pascal <pb...@oi...>]

With single widgets (prototyping from the dynlayer) there are indeed no
problems, but when you want to build another widget based on the first
widget.. things will start happening. The widget will have 2x the
eventlisteners needed.

I think the easiest way to explain is that you should take a look at the
addEventListener method of the DynLayer.. this checks to see if the
eventlistener is already attached.. if not, it attaches the specified one.

With prototyping the constructor is called multiple times first:

	this.Button=new Button
	this.Button()  <-- calls constructor, and thus creates first-widget's
eventlistener

then already defined for the prototype:

imgButton.prototype=new Button <--- calls the constructor ALSO, creating a
nother eventlistener.


By attaching the eventListener to the constructor, it's always the same
eventlistener:

Button.listener

..it's hard to explain, so probably harder to understand, but do some tests
with multiple-inheriting and you'll notice the eventlistener problems.

l8r,

Pascal Bestebroer (pb...@oi...)
Software ontwikkelaar
Oberon Informatiesystemen b.v.
http://www.oibv.com

> -----Oorspronkelijk bericht-----
> Van: dyn...@li...
> [mailto:dyn...@li...]Namens Jack_Speranza
> Verzonden: donderdag 11 januari 2001 15:51
> Aan: 'dyn...@li...'
> Onderwerp: RE: Re[2]: [Dynapi-Dev] Making progress on a Java gui tool
>
>
> Just an intellectual JS question on this subject... doesn't
> keeping the
> eventlistener in the prototype assure the code only exists in
> one place in
> memory (i.e. - each instantiated object points to the same
> code)?  Given the
> browser's poor memory handling, isn't this a good thing, and
> better than
> having multiple copies of the same code clogging things up?
> If the code is
> written properly, it seems to me that everything should work
> just fine and
> dandy for all insantiated objects, or am I missing something here?
>
> -----Original Message-----
> From: Pascal [mailto:pb...@oi...]
> Sent: Thursday, January 11, 2001 2:56 AM
> To: dyn...@li...
> Subject: RE: Re[2]: [Dynapi-Dev] Making progress on a Java gui tool
>
>
> Yes, the widgets should indeed now use the precreation system, and the
> eventlistener should not be attached using prototype (it's part of the
> object, not of the prototype chain).
>
> Also events should be invoked, and not be hard coded
> functions (can't recall
> if I ever did that).
>
> and, uhm, please drop the Master..
>
> cya,
>
> Pascal Bestebroer (pb...@oi...)
> Software ontwikkelaar
> Oberon Informatiesystemen b.v.
> http://www.oibv.com
>
> > -----Oorspronkelijk bericht-----
> > Van: dyn...@li...
> > [mailto:dyn...@li...]Namens Raymond Smith
> > Verzonden: donderdag 11 januari 2001 5:43
> > Aan: dyn...@li...
> > Onderwerp: Re: Re[2]: [Dynapi-Dev] Making progress on a
> Java gui tool
> >
> >
> > I've been dragging skinwindows just by attaching the
> > 'behavior' at creation
> > time.  When Master Pascal mentioned the need for updating I
> > think he was
> > refering to the need to convert them to the precreate system.
> >
> > ----- Original Message -----
> > From: "Doug Melvin" <do...@cr...>
> > To: <dyn...@li...>
> > Sent: Wednesday, January 10, 2001 11:16 PM
> > Subject: Re: Re[2]: [Dynapi-Dev] Making progress on a Java gui tool
> >
> >
> > > Window is now draggable..
> > > also, you can double click on the title bar to maximize/restore..
> > > Need to add a cover layer over caption text as caption text
> > blocks click
> > > events
> > > in the title bar..
> > >
> > > Doug Melvin
> > > ----- Original Message -----
> > > From: "Richard :o" <ma...@ri...>
> > > To: <dyn...@li...>
> > > Sent: Tuesday, January 09, 2001 4:33 PM
> > > Subject: Re: Re[2]: [Dynapi-Dev] Making progress on a
> Java gui tool
> > >
> > >
> > > > > correct, the widgets are not in the CVS. They would
> > also need work to
> > > make
> > > > > them work in the latest DynAPI2.. something I'm not
> > planning on for a
> > > > while.
> > > >
> > > > So Doug, please send your fixes over to me as I would
> > like to support
> > > these
> > > > great
> > > > widgets as long as possible, and the lack of draggability
> > under IE5.5
> > was
> > > a
> > > > long overdue fix.
> > > >
> > > > Regarding elastic, I apply this on my page by detecting browser
> > dimensions
> > > > like this:
> > > >
> > > > var winH,winW,w, h, ow, oh, q
> > > >
> > > > function findWH() {
> > > >  winW = (is.ns)? window.innerWidth :
> document.body.offsetWidth-20
> > > >  winH = (is.ns)? window.innerHeight :
> document.body.offsetHeight-4
> > > >                              //I'm not sure what the -20
> > and -4  was
> > > needed
> > > > for now
> > > >    ow= 1004/winW;
> > > >    oh= 648/winH;
> > > >    if(ow>oh){q=ow;}else{q=oh;}
> > > >  return q
> > > > }
> > > >
> > > > DynAPI.onLoad=function() {
> > > >     q=findWH()
> > > >
> > > > and then all sizes defined are divided by q, like this:
> > > >
> > > > statusMsg=new DynLayer(null,0,0,120/q,120/q);
> > > >
> > > > When done like this it means objects retain their
> > original shape; so if
> > > > someone's browser is letterbox
> > > > shaped, your page doesn't become squashed, but decreases
> > in width as
> > well.
> > > >
> > > > in the resize event you could put:
> > > > q=findWH()    //gets new dimensions
> > > > statusMsg.slideTo(120/q,120/q);
> > > >
> > > > I haven't done the resizing bit on my page right now,
> > because I wanted
> > to
> > > > animate the resizing
> > > > properly (ie the things fly to the new place, and
> > grow/shrink). Also
> > many
> > > > people resize the browser
> > > > while the page is loading, which could cause errors and
> > crashes, so I
> > only
> > > > let the onResize()
> > > > code execute (during testing) after a variable was set at
> > the end of my
> > > > preloading sequence.
> > > > Of course NS can't animate anything onResize(), as it
> > simply has to be
> > > > reloaded, at least I haven't
> > > > seen recreateAll() work properly without a reload.
> > > >
> > > > The only problem I run into was text size, you can change
> > the font size
> > > > using the same variable, ie:
> > > >
> > > > statusMsg.setHTML('<span style="font-size: '+16/q+'pt;">Blah
> > Blah</span>')
> > > >
> > > > but during testing NS gave a lot of problems, looking on
> > it now I think
> > > the
> > > > problem was that I had two stylesheets
> > > > applied to the same document, one directly and one
> > through a skinButton
> > > > widget, but I'm not sure.
> > > >
> > > > I hope there's something in there of use;
> > > >
> > > > Cheers,
> > > > Richard  :o
> > > >
> > > > ma...@ri...
> > > > www.richardinfo.com
> > > > (Everything running on, and ported to the 19/12/2000 snapshot of
> > DynAPI2)
> > > >
> > > > ----- Original Message -----
> > > > From: "Pascal Bestebroer" <pa...@dy...>
> > > > To: <dyn...@li...>
> > > > Sent: Wednesday, January 10, 2001 9:40 PM
> > > > Subject: RE: Re[2]: [Dynapi-Dev] Making progress on a
> > Java gui tool
> > > >
> > > >
> > > > > correct, the widgets are not in the CVS. They would
> > also need work to
> > > make
> > > > > them work in the latest DynAPI2.. something I'm not
> > planning on for a
> > > > while.
> > > > >
> > > > > cya,
> > > > >
> > > > > Pascal Bestebroer
> > > > > pa...@dy...
> > > > > http://www.dynamic-core.net
> > > > >
> > > > > > -----Oorspronkelijk bericht-----
> > > > > > Van: dyn...@li...
> > > > > > [mailto:dyn...@li...]Namens Robert
> > Rainwater
> > > > > > Verzonden: woensdag 10 januari 2001 21:35
> > > > > > Aan: DynAPI Development List
> > > > > > Onderwerp: Re[2]: [Dynapi-Dev] Making progress on a
> > Java gui tool
> > > > > >
> > > > > >
> > > > > >
> > > > > > As far as I know none of those widgets are in CVS.
> > Aren't those
> > > > > > Pascal's widgets?
> > > > > >
> > > > > > --
> > > > > > // Robert Rainwater
> > > > > >
> > > > > > On 1/10/2001, 6:02:56 PM EST, Doug wrote about "[Dynapi-Dev]
> > > > > > Making progress on a Java gui tool":
> > > > > >
> > > > > > > How do I get access to the CVS system..
> > > > > > > I've fixed a few bugs myself..
> > > > > > > Such as the 'movebility' of the skinwindow.
> > > > > > > I also updated the doDock mothod of the skintoolbar.
> > > > > > > Now calling doDock(0) will dock the toolbar at the top.
> > > > > > > (re-position it and set it's width)
> > > > > > > and passing a 1 instead will dock it at the bottom.
> > > > > > > I am also working on an elatic object..
> > > > > > > What this does is resizes and repositions the
> > content on your
> > > > > > page for any
> > > > > > > browser size.. and automatically does so when you
> > change the size
> > of
> > > > the
> > > > > > > browser..
> > > > > >
> > > > > >
> > > > > > > Assuming I do get access to CVS..
> > > > > > > Is the bug list at sourceforge complete?
> > > > > > > ----- Original Message -----
> > > > > > > From: "Raymond Smith" <dst...@or...>
> > > > > > > To: <dyn...@li...>
> > > > > > > Sent: Tuesday, January 09, 2001 1:54 PM
> > > > > > > Subject: Re: [Dynapi-Dev] Making progress on a
> Java gui tool
> > > > > >
> > > > > >
> > > > > > >> I was beginning to wonder where Dan went off to,
> > now we know.  It
> > > > does
> > > > > > >> appear that we've created a bit of a two headed
> > hydra here, as
> > > others
> > > > > > >> mentioned might happen.  Dan's off working on a
> > DynBuilder while
> > > > other
> > > > > > >> pontificate about the holy-grail of RAD tools to
> > speed up "the
> > > still
> > > > > > > bugged
> > > > > > >> version of DynAPI2" that hasn't had a refresh
> > since November of
> > > 2000.
> > > > > > >>
> > > > > > >> While I do my best to muddle thru this code and
> > help Robert debug
> > > > this
> > > > > > > stuff
> > > > > > >> I fear I submit about as much confusion as
> > contribution.  But I
> > get
> > > > the
> > > > > > >> feeling that others are not really 'actively
> debugging' the
> > > > > > current CVS.
> > > > > > >> Dan's working on a GUI which he will 'share'
> with us, thus
> > > > > > allowing us to
> > > > > > >> further defocus our efforts while other do grand
> > debate on what
> > > this
> > > > > > > "thing"
> > > > > > >> should be.
> > > > > > >>
> > > > > > >> It would be nice to, at a minimum, clean up the
> > current base
> > > > > > code in the
> > > > > > > CVS
> > > > > > >> before we defocus the limited masses even more.
> > > > > > >>
> > > > > > >> Sorry for the rant.  But ALOT of change was
> introduced with
> > > > > > precreate and
> > > > > > >> inline creation integration that still needs to be
> > cleaned up.
> > > > > >  It seems
> > > > > > > the
> > > > > > >> only really active debugger right now is Robert
> > and Pascal (on
> > > > > > a limited
> > > > > > >> basis).
> > > > > > >>
> > > > > > >>
> > > > > > >> _______________________________________________
> > > > > > >> Dynapi-Dev mailing list
> > > > > > >> Dyn...@li...
> > > > > > >> http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
> > > > > >
> > > > > >
> > > > > > > _______________________________________________
> > > > > > > Dynapi-Dev mailing list
> > > > > > > Dyn...@li...
> > > > > > > http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
> > > > > >
> > > > > >
> > > > > >
> > > > > > _______________________________________________
> > > > > > Dynapi-Dev mailing list
> > > > > > Dyn...@li...
> > > > > > http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
> > > > > >
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > Dynapi-Dev mailing list
> > > > > Dyn...@li...
> > > > > http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
> > > > > ____________________________________________________________
> > > > > Get your free domain name and domain-based e-mail from
> > > > > Namezero.com. New!  Namezero Plus domains now available.
> > > > > Find out more at: http://www.namezero.com
> > > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > Dynapi-Dev mailing list
> > > > Dyn...@li...
> > > > http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
> > >
> >
> >
> > _______________________________________________
> > Dynapi-Dev mailing list
> > Dyn...@li...
> > http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
> >
>
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
>

RE: [Dynapi-Dev] CVS updated

[Pascal <pb...@oi...>]

My widgets might work okay, but they need some changes to make them work
correctly with onprecreate events instead of oncreate events, and the
eventlisteners must be attached to the constructors, and not the prototypes
of the widgets (problem with all old widgets)

The precreation code will speed up the creation (and make netscape more
stable) of layers with many child layers. All child layers are now created
into one string (using the <div> tags and style properties) and that string
is then written into the parent layer.. then the parent layer is added to
the document, automatically creating ALL child layers and itself in one
single document write.

because of some browser checking for the precreation (to make the correct
strings) in the dynlayer, the browser file must be included before the
dynlayer.

l8r,

Pascal Bestebroer (pb...@oi...)
Software ontwikkelaar
Oberon Informatiesystemen b.v.
http://www.oibv.com

> -----Oorspronkelijk bericht-----
> Van: dyn...@li...
> [mailto:dyn...@li...]Namens Richard :o
> Verzonden: donderdag 11 januari 2001 15:14
> Aan: dyn...@li...
> Onderwerp: Re: [Dynapi-Dev] CVS updated
>
>
> Ok, i tried the latest snapshot with your two altered files
> from the cvs,
> it's basically ok, but:
> * Buttons are ok now regarding text/events, but if you double-click a
> text-button it selects bits of the  caption, so it needs a
> cover layer after
> all.
> * The list widget still doesn't mouse-over
> * Mouse-over doesn't seem to occur for a layer with image.
>
> I'm afraid it seems this whole precreation thing has somewhat
> passed me by,
> probably it happened when I was offline over Christmas, so
> I'll check the
> archives for relevant info. What I don't understand though is
> why Pascal
> keeps saying that his widgets will be obsolete under the new
> DynAPI, while
> they all work perfectly alright under the latest snapshot, with latest
> events + dynlayer files. Is it a question of not working ok
> under DOM maybe?
> The only widget I could not get working without altering was you're
> scrollbar, which gives out of stack error in scrollbar.js,
> line 137 which is
> a setSize(w,null) call.
>
> * Now browser.js has to be included in your page before
> dynlayer.js or error
> "is undefined dynlayer.js line 265", this was not the case a
> while ago. I
> guess that's due to the precreation changes.
>
> Keep up the war,
>
> Richard  :o
>
> ma...@ri...
> www.richardinfo.com
> (Everything running on, and ported to the 19/12/2000 snapshot
> of DynAPI2)
>
> ----- Original Message -----
> From: "Jordi 'IlMaestro' Ministral" <jmi...@or...>
> To: <dyn...@li...>
> Sent: Thursday, January 11, 2001 1:12 PM
> Subject: Re: [Dynapi-Dev] CVS updated
>
>
> > I'm missing events... did I screw something ? First I
> thought but then
> going back to the latest code (
> > before my modifications ) I am missing those same events.
> Ohh please just
> a little luck from time to
> > time !!!!!
> >
> > In NS you can apply the same "for (each image in doc)
> img.lyrobj = myself"
> event trick to the links
> > array.
> >
> >
> > Jordi 'IlMaestro' Ministral wrote:
> >
> > > I have updated CVS with a new events.js that should fix IEs event
> problems. All the example files
> > > worked fine. This is what happened ( at least this is
> something I found,
> maybe there are still
> > > other issues ):
> > >
> > > - All browser events in DynAPI are captured and passed to the same
> EventMethod. This eventMethod
> > > identifyes the physical layer, cancels browser event,
> searches for the
> appropiate DynmLayer object
> > > and invokes its event.
> > >
> > > - In IE, in order to access the DynLayer object we use the lyrobj
> property of the DIV itself. This
> > > property is set when creating a layer so from code
> executed within the
> DIV's scope we can still get
> > > to our DynLayer obj. The problem with our contents was that when
> clicking on a text, most of the
> > > times the srcElement of the event was not the DIV but a
> FONT, TD, TR,
> TABLE, UL,... element. That
> > > element did not have a pointer to the dynlayer and thus
> the API could
> not route the event properly.
> > >
> > > - This issue was partially solved for images by doing:
> > >
> > > if (is.ie) for (i in dlyr.elm.all.tags("img"))
> dlyr.elm.all.tags("img")[i].lyrobj=dlyr;
> > >
> > > So images had a pointer to the layer aswell. This we
> would have needed
> to do to all elements in our
> > > content, somethig really painful. Instead, I added this
> line inside
> eventmethod.
> > >
> > >  for(;is.ie && !realsrc.lyrobj && realsrc.parentElement &&
> > > realsrc.parentElement!=realsrc;realsrc=realsrc.parentElement);
> > >
> > > Which actually makes realsrc travel IE's object hierarchy
> until we find
> the lyrobj reference. By
> > > doing so I fixed events in IE5 and 5.5. I'm not that sure
> everything is
> fine now, but it is an
> > > improvement.
> > >
> > > There are several lines in that method such as that
> > >
> > > if (e.type=="mouseover" || e.type=="mouseout") return false;
> > >
> > > just before the bubbleEvent() call that I don't
> understand but I prefer
> not to touch them.
> > >
> > > By the way, it seems that when clicking on a selectable
> text, NS does
> not fire a click event.
> > > Mousedown and mouseup are fired, but click isn't. We could fire it
> manually but then when clicking
> > > outside a text we would get two onclicks.
> > >
> > > Tell me if I broke something. Sure I did.
> > >
> > > Cya
> > >
> > > _______________________________________________
> > > Dynapi-Dev mailing list
> > > Dyn...@li...
> > > http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
> >
> >
> > _______________________________________________
> > Dynapi-Dev mailing list
> > Dyn...@li...
> > http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
> > ____________________________________________________________
> > Get your free domain name and domain-based e-mail from
> > Namezero.com. New!  Namezero Plus domains now available.
> > Find out more at: http://www.namezero.com
> >
>
>
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
>

RE: Re[2]: [Dynapi-Dev] Making progress on a Java gui tool

[Jack_Speranza <jsp...@gr...>]

Just an intellectual JS question on this subject... doesn't keeping the
eventlistener in the prototype assure the code only exists in one place in
memory (i.e. - each instantiated object points to the same code)?  Given the
browser's poor memory handling, isn't this a good thing, and better than
having multiple copies of the same code clogging things up?  If the code is
written properly, it seems to me that everything should work just fine and
dandy for all insantiated objects, or am I missing something here?

-----Original Message-----
From: Pascal [mailto:pb...@oi...]
Sent: Thursday, January 11, 2001 2:56 AM
To: dyn...@li...
Subject: RE: Re[2]: [Dynapi-Dev] Making progress on a Java gui tool


Yes, the widgets should indeed now use the precreation system, and the
eventlistener should not be attached using prototype (it's part of the
object, not of the prototype chain).

Also events should be invoked, and not be hard coded functions (can't recall
if I ever did that).

and, uhm, please drop the Master..

cya,

Pascal Bestebroer (pb...@oi...)
Software ontwikkelaar
Oberon Informatiesystemen b.v.
http://www.oibv.com

> -----Oorspronkelijk bericht-----
> Van: dyn...@li...
> [mailto:dyn...@li...]Namens Raymond Smith
> Verzonden: donderdag 11 januari 2001 5:43
> Aan: dyn...@li...
> Onderwerp: Re: Re[2]: [Dynapi-Dev] Making progress on a Java gui tool
>
>
> I've been dragging skinwindows just by attaching the
> 'behavior' at creation
> time.  When Master Pascal mentioned the need for updating I
> think he was
> refering to the need to convert them to the precreate system.
>
> ----- Original Message -----
> From: "Doug Melvin" <do...@cr...>
> To: <dyn...@li...>
> Sent: Wednesday, January 10, 2001 11:16 PM
> Subject: Re: Re[2]: [Dynapi-Dev] Making progress on a Java gui tool
>
>
> > Window is now draggable..
> > also, you can double click on the title bar to maximize/restore..
> > Need to add a cover layer over caption text as caption text
> blocks click
> > events
> > in the title bar..
> >
> > Doug Melvin
> > ----- Original Message -----
> > From: "Richard :o" <ma...@ri...>
> > To: <dyn...@li...>
> > Sent: Tuesday, January 09, 2001 4:33 PM
> > Subject: Re: Re[2]: [Dynapi-Dev] Making progress on a Java gui tool
> >
> >
> > > > correct, the widgets are not in the CVS. They would
> also need work to
> > make
> > > > them work in the latest DynAPI2.. something I'm not
> planning on for a
> > > while.
> > >
> > > So Doug, please send your fixes over to me as I would
> like to support
> > these
> > > great
> > > widgets as long as possible, and the lack of draggability
> under IE5.5
> was
> > a
> > > long overdue fix.
> > >
> > > Regarding elastic, I apply this on my page by detecting browser
> dimensions
> > > like this:
> > >
> > > var winH,winW,w, h, ow, oh, q
> > >
> > > function findWH() {
> > >  winW = (is.ns)? window.innerWidth : document.body.offsetWidth-20
> > >  winH = (is.ns)? window.innerHeight : document.body.offsetHeight-4
> > >                              //I'm not sure what the -20
> and -4  was
> > needed
> > > for now
> > >    ow= 1004/winW;
> > >    oh= 648/winH;
> > >    if(ow>oh){q=ow;}else{q=oh;}
> > >  return q
> > > }
> > >
> > > DynAPI.onLoad=function() {
> > >     q=findWH()
> > >
> > > and then all sizes defined are divided by q, like this:
> > >
> > > statusMsg=new DynLayer(null,0,0,120/q,120/q);
> > >
> > > When done like this it means objects retain their
> original shape; so if
> > > someone's browser is letterbox
> > > shaped, your page doesn't become squashed, but decreases
> in width as
> well.
> > >
> > > in the resize event you could put:
> > > q=findWH()    //gets new dimensions
> > > statusMsg.slideTo(120/q,120/q);
> > >
> > > I haven't done the resizing bit on my page right now,
> because I wanted
> to
> > > animate the resizing
> > > properly (ie the things fly to the new place, and
> grow/shrink). Also
> many
> > > people resize the browser
> > > while the page is loading, which could cause errors and
> crashes, so I
> only
> > > let the onResize()
> > > code execute (during testing) after a variable was set at
> the end of my
> > > preloading sequence.
> > > Of course NS can't animate anything onResize(), as it
> simply has to be
> > > reloaded, at least I haven't
> > > seen recreateAll() work properly without a reload.
> > >
> > > The only problem I run into was text size, you can change
> the font size
> > > using the same variable, ie:
> > >
> > > statusMsg.setHTML('<span style="font-size: '+16/q+'pt;">Blah
> Blah</span>')
> > >
> > > but during testing NS gave a lot of problems, looking on
> it now I think
> > the
> > > problem was that I had two stylesheets
> > > applied to the same document, one directly and one
> through a skinButton
> > > widget, but I'm not sure.
> > >
> > > I hope there's something in there of use;
> > >
> > > Cheers,
> > > Richard  :o
> > >
> > > ma...@ri...
> > > www.richardinfo.com
> > > (Everything running on, and ported to the 19/12/2000 snapshot of
> DynAPI2)
> > >
> > > ----- Original Message -----
> > > From: "Pascal Bestebroer" <pa...@dy...>
> > > To: <dyn...@li...>
> > > Sent: Wednesday, January 10, 2001 9:40 PM
> > > Subject: RE: Re[2]: [Dynapi-Dev] Making progress on a
> Java gui tool
> > >
> > >
> > > > correct, the widgets are not in the CVS. They would
> also need work to
> > make
> > > > them work in the latest DynAPI2.. something I'm not
> planning on for a
> > > while.
> > > >
> > > > cya,
> > > >
> > > > Pascal Bestebroer
> > > > pa...@dy...
> > > > http://www.dynamic-core.net
> > > >
> > > > > -----Oorspronkelijk bericht-----
> > > > > Van: dyn...@li...
> > > > > [mailto:dyn...@li...]Namens Robert
> Rainwater
> > > > > Verzonden: woensdag 10 januari 2001 21:35
> > > > > Aan: DynAPI Development List
> > > > > Onderwerp: Re[2]: [Dynapi-Dev] Making progress on a
> Java gui tool
> > > > >
> > > > >
> > > > >
> > > > > As far as I know none of those widgets are in CVS.
> Aren't those
> > > > > Pascal's widgets?
> > > > >
> > > > > --
> > > > > // Robert Rainwater
> > > > >
> > > > > On 1/10/2001, 6:02:56 PM EST, Doug wrote about "[Dynapi-Dev]
> > > > > Making progress on a Java gui tool":
> > > > >
> > > > > > How do I get access to the CVS system..
> > > > > > I've fixed a few bugs myself..
> > > > > > Such as the 'movebility' of the skinwindow.
> > > > > > I also updated the doDock mothod of the skintoolbar.
> > > > > > Now calling doDock(0) will dock the toolbar at the top.
> > > > > > (re-position it and set it's width)
> > > > > > and passing a 1 instead will dock it at the bottom.
> > > > > > I am also working on an elatic object..
> > > > > > What this does is resizes and repositions the
> content on your
> > > > > page for any
> > > > > > browser size.. and automatically does so when you
> change the size
> of
> > > the
> > > > > > browser..
> > > > >
> > > > >
> > > > > > Assuming I do get access to CVS..
> > > > > > Is the bug list at sourceforge complete?
> > > > > > ----- Original Message -----
> > > > > > From: "Raymond Smith" <dst...@or...>
> > > > > > To: <dyn...@li...>
> > > > > > Sent: Tuesday, January 09, 2001 1:54 PM
> > > > > > Subject: Re: [Dynapi-Dev] Making progress on a Java gui tool
> > > > >
> > > > >
> > > > > >> I was beginning to wonder where Dan went off to,
> now we know.  It
> > > does
> > > > > >> appear that we've created a bit of a two headed
> hydra here, as
> > others
> > > > > >> mentioned might happen.  Dan's off working on a
> DynBuilder while
> > > other
> > > > > >> pontificate about the holy-grail of RAD tools to
> speed up "the
> > still
> > > > > > bugged
> > > > > >> version of DynAPI2" that hasn't had a refresh
> since November of
> > 2000.
> > > > > >>
> > > > > >> While I do my best to muddle thru this code and
> help Robert debug
> > > this
> > > > > > stuff
> > > > > >> I fear I submit about as much confusion as
> contribution.  But I
> get
> > > the
> > > > > >> feeling that others are not really 'actively debugging' the
> > > > > current CVS.
> > > > > >> Dan's working on a GUI which he will 'share' with us, thus
> > > > > allowing us to
> > > > > >> further defocus our efforts while other do grand
> debate on what
> > this
> > > > > > "thing"
> > > > > >> should be.
> > > > > >>
> > > > > >> It would be nice to, at a minimum, clean up the
> current base
> > > > > code in the
> > > > > > CVS
> > > > > >> before we defocus the limited masses even more.
> > > > > >>
> > > > > >> Sorry for the rant.  But ALOT of change was introduced with
> > > > > precreate and
> > > > > >> inline creation integration that still needs to be
> cleaned up.
> > > > >  It seems
> > > > > > the
> > > > > >> only really active debugger right now is Robert
> and Pascal (on
> > > > > a limited
> > > > > >> basis).
> > > > > >>
> > > > > >>
> > > > > >> _______________________________________________
> > > > > >> Dynapi-Dev mailing list
> > > > > >> Dyn...@li...
> > > > > >> http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
> > > > >
> > > > >
> > > > > > _______________________________________________
> > > > > > Dynapi-Dev mailing list
> > > > > > Dyn...@li...
> > > > > > http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
> > > > >
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > Dynapi-Dev mailing list
> > > > > Dyn...@li...
> > > > > http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
> > > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > Dynapi-Dev mailing list
> > > > Dyn...@li...
> > > > http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
> > > > ____________________________________________________________
> > > > Get your free domain name and domain-based e-mail from
> > > > Namezero.com. New!  Namezero Plus domains now available.
> > > > Find out more at: http://www.namezero.com
> > > >
> > >
> > >
> > > _______________________________________________
> > > Dynapi-Dev mailing list
> > > Dyn...@li...
> > > http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
> >
>
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
>


_______________________________________________
Dynapi-Dev mailing list
Dyn...@li...
http://lists.sourceforge.net/mailman/listinfo/dynapi-dev

Re: [Dynapi-Dev] CVS updated

[Richard :o <ma...@ri...>]

Ok, i tried the latest snapshot with your two altered files from the cvs,
it's basically ok, but:
* Buttons are ok now regarding text/events, but if you double-click a
text-button it selects bits of the  caption, so it needs a cover layer after
all.
* The list widget still doesn't mouse-over
* Mouse-over doesn't seem to occur for a layer with image.

I'm afraid it seems this whole precreation thing has somewhat passed me by,
probably it happened when I was offline over Christmas, so I'll check the
archives for relevant info. What I don't understand though is why Pascal
keeps saying that his widgets will be obsolete under the new DynAPI, while
they all work perfectly alright under the latest snapshot, with latest
events + dynlayer files. Is it a question of not working ok under DOM maybe?
The only widget I could not get working without altering was you're
scrollbar, which gives out of stack error in scrollbar.js, line 137 which is
a setSize(w,null) call.

* Now browser.js has to be included in your page before dynlayer.js or error
"is undefined dynlayer.js line 265", this was not the case a while ago. I
guess that's due to the precreation changes.

Keep up the war,

Richard  :o

ma...@ri...
www.richardinfo.com
(Everything running on, and ported to the 19/12/2000 snapshot of DynAPI2)

----- Original Message -----
From: "Jordi 'IlMaestro' Ministral" <jmi...@or...>
To: <dyn...@li...>
Sent: Thursday, January 11, 2001 1:12 PM
Subject: Re: [Dynapi-Dev] CVS updated


> I'm missing events... did I screw something ? First I thought but then
going back to the latest code (
> before my modifications ) I am missing those same events. Ohh please just
a little luck from time to
> time !!!!!
>
> In NS you can apply the same "for (each image in doc) img.lyrobj = myself"
event trick to the links
> array.
>
>
> Jordi 'IlMaestro' Ministral wrote:
>
> > I have updated CVS with a new events.js that should fix IEs event
problems. All the example files
> > worked fine. This is what happened ( at least this is something I found,
maybe there are still
> > other issues ):
> >
> > - All browser events in DynAPI are captured and passed to the same
EventMethod. This eventMethod
> > identifyes the physical layer, cancels browser event, searches for the
appropiate DynmLayer object
> > and invokes its event.
> >
> > - In IE, in order to access the DynLayer object we use the lyrobj
property of the DIV itself. This
> > property is set when creating a layer so from code executed within the
DIV's scope we can still get
> > to our DynLayer obj. The problem with our contents was that when
clicking on a text, most of the
> > times the srcElement of the event was not the DIV but a FONT, TD, TR,
TABLE, UL,... element. That
> > element did not have a pointer to the dynlayer and thus the API could
not route the event properly.
> >
> > - This issue was partially solved for images by doing:
> >
> > if (is.ie) for (i in dlyr.elm.all.tags("img"))
dlyr.elm.all.tags("img")[i].lyrobj=dlyr;
> >
> > So images had a pointer to the layer aswell. This we would have needed
to do to all elements in our
> > content, somethig really painful. Instead, I added this line inside
eventmethod.
> >
> >  for(;is.ie && !realsrc.lyrobj && realsrc.parentElement &&
> > realsrc.parentElement!=realsrc;realsrc=realsrc.parentElement);
> >
> > Which actually makes realsrc travel IE's object hierarchy until we find
the lyrobj reference. By
> > doing so I fixed events in IE5 and 5.5. I'm not that sure everything is
fine now, but it is an
> > improvement.
> >
> > There are several lines in that method such as that
> >
> > if (e.type=="mouseover" || e.type=="mouseout") return false;
> >
> > just before the bubbleEvent() call that I don't understand but I prefer
not to touch them.
> >
> > By the way, it seems that when clicking on a selectable text, NS does
not fire a click event.
> > Mousedown and mouseup are fired, but click isn't. We could fire it
manually but then when clicking
> > outside a text we would get two onclicks.
> >
> > Tell me if I broke something. Sure I did.
> >
> > Cya
> >
> > _______________________________________________
> > Dynapi-Dev mailing list
> > Dyn...@li...
> > http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
>
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
> ____________________________________________________________
> Get your free domain name and domain-based e-mail from
> Namezero.com. New!  Namezero Plus domains now available.
> Find out more at: http://www.namezero.com
>

RE: [Dynapi-Dev] [Bug #128263] PathAnimation.stopAnimation() bug (& patch)

[Pascal <pb...@oi...>]

I had already thought about something like this, making
functionality-widgets.

A button widget would then contain only a single layer (the canvas) with the
events linked to it (onmousedown, up, etc..).. the basic functionality of
the widget.

You could then extend on this widget to make

* normal 3D buttons (adding border layers to the main canvas)
  * image button (could extend 3D button, and add dynimage to the canvas as
well)
* skin button add background-image to the canvas, and possibly image-borders

this should then be done for all widgets, so that you basically have one
main widget that contains the functionality, and other widgets extend on it
to define the looks and style of the widget (skinable/not-skinable would be
the thing aiming for)

The only problem is that the basic-functionality widget should catch all
events, so it would need some tinkering with precreation events.. and maybe
add an onfinalise event to the function-widget or something.

Pascal Bestebroer (pb...@oi...)
Software ontwikkelaar
Oberon Informatiesystemen b.v.
http://www.oibv.com

> -----Oorspronkelijk bericht-----
> Van: dyn...@li...
> [mailto:dyn...@li...]Namens Raides J.
> Verzonden: donderdag 11 januari 2001 14:02
> Aan: dyn...@li...
> Onderwerp: Re: [Dynapi-Dev] [Bug #128263]
> PathAnimation.stopAnimation()
> bug (& patch)
>
>
> > Raymond Smith wrote:
> >
> > You know what we need.  A super button widget.  I just
> noticed I have for js
> > calls for differing button type.  The ideal button would:
> >
> > 1) Contain the ability to;
> > a) be defined and colored ala HTML (button.js)
> > b) pull in images (ala ButtonImage), but have three states:
> static, mouseover
> > and clicked
> > c) act as a 'href clicked marker", ie.... have a chnage
> state per session if
> > it has been clicked once.
> > d) perform as a check box (boolean toggle, imagebutton.js)
> > e) and have the abilty to be skined and defined by multiple themes.
> >
> > I have all this spread across 4 differing widgets, once I
> integrate this into
> > a super hacked version of what little I know I will contribute it.
> >
> > Later

Re: [Dynapi-Dev] [Bug #128263] PathAnimation.stopAnimation() bug (& patch)

[Raymond S. <dst...@or...>]

Richards our "codewhore", never ask.... just deliver!

Just kidding.

Night all

Ray
----- Original Message -----
From: "Richard :o" <ma...@ri...>
To: <dyn...@li...>
Sent: Thursday, January 11, 2001 5:42 AM
Subject: Re: [Dynapi-Dev] [Bug #128263] PathAnimation.stopAnimation() bug (&
patch)


> Of course you should attache the files, is there also a working example
> somewhere?
>
> Cheers,
> Richard  :o
>
> ma...@ri...
> www.richardinfo.com
> (Everything running on, and ported to the 19/12/2000 snapshot of DynAPI2)
>
> ----- Original Message -----
> From: "Raides J." <ra...@te...>
> To: <dyn...@li...>
> Sent: Thursday, January 11, 2001 2:02 PM
> Subject: Re: [Dynapi-Dev] [Bug #128263] PathAnimation.stopAnimation() bug
(&
> patch)
>
>
> > > Raymond Smith wrote:
> > >
> > > You know what we need.  A super button widget.  I just noticed I have
> for js
> > > calls for differing button type.  The ideal button would:
> > >
> > > 1) Contain the ability to;
> > > a) be defined and colored ala HTML (button.js)
> > > b) pull in images (ala ButtonImage), but have three states: static,
> mouseover
> > > and clicked
> > > c) act as a 'href clicked marker", ie.... have a chnage state per
> session if
> > > it has been clicked once.
> > > d) perform as a check box (boolean toggle, imagebutton.js)
> > > e) and have the abilty to be skined and defined by multiple themes.
> > >
> > > I have all this spread across 4 differing widgets, once I integrate
this
> into
> > > a super hacked version of what little I know I will contribute it.
> > >
> > > Later
> >
> > It's not just that, but I have two .js that I can send you under request
> > (different versions available, so you have to ask which one you choose)
> that
> > implement what I call an "active area", i.e. a region in web-page space
> which
> > responds to mouse events and generates its own event calls, and what I
> call an
> > "icon", which is a 4-state imagebutton (all 4 images can be the same).
> > The "Icono" (the name of the object icon) object has methods to activate
> it
> > (state=0), deactivate it (state=3) and change it's default state (0=on,
> > 1=mouseover, 2=click, 3=off). They generate just the "onClick" event
when
> > clicked and active with a parameter which is the index of the icon in
the
> "Area"
> > (the active area object) they MUST be contained on to work. This way you
> can
> > group them logically and assign the same method to the "onClick" event
of
> each
> > related group of buttons and then differentiate in code using a
"switch()"
> > statement. One interesting "side-effect" derived from the way I have
> implemented
> > the "Icono" is that you can have a different image in place of the icon,
> and it
> > gets replaced on the first mouse event on the icon. Other side-effect is
> that
> > you can have the area and the icon responding to mouse events in one
place
> of
> > the page and the associated image changing state in other part ;)
> > The "Area" object is rather different. One of the versions needs always
a
> > DynLayer 1.0 version of layer to attach itself to for the dimension
> information
> > (the older version). The other two versions can be created independent
of
> any
> > other object or attached to DynLayers 1.0 and DynAPI DynLayers
> respectively.
> > They have methods to change the size of the active area, to move the
> top-left
> > corner, to activate and deactivate them, and to dump it's internal
> information
> > as an "alert" method. The events fired are of a wide sort and ALL
provide
> the
> > mouse coordinates in RELATIVE or ABSOLUTE (page relative) vaues when the
> event
> > fired. Overimposed areas fire all at the same time if they are active,
so
> > multiple areas can react to a single mouse event at once. The mouse
events
> are:
> > onMouseIn --> Fires just when the mouse enters the area and just once
> > onMouseDown --> Fires on the mouse down phase of a button press (just
the
> left
> > button)
> > onMouseUp --> Fires on the mouse up phase of a button press (just the
left
> > button). This only fires IF the mouse is INSIDE the area. In case it's
> moved
> > outside while the mouse is down (dragging), the event fired will be the
> next
> > one.
> > onMouseOut --> Fires just once the mouse exits from the area and after
an
> > "onMouseIn" event has occurred. It can fire in the middle of an
> > "onMouseDown"-"onMouseUp" sequence.
> > onMouseOver --> Fires WHILE the mouse is INSIDE the area.
> > onClick --> Fires IF the "onMouseDown" AND the "onMouseUp" events occur
in
> > sequence and INSIDE the area. If the mouse gets out of the area before
the
> > button is up, no event is fired.
> >
> > The usual sequence for this events is: "onMouseIn" - "onMouseOver" (more
> than
> > once) - "onMouseOut" for the mouse movement events, and "onMouseDown" -
> > "onMouseUp" - "onClick" for the button mouse events. This more than
> extends the
> > standard behaviour and you can easily add an "onMouseUpOut" event to
> capture the
> > button release when it started inside and ended outside of the area, so
an
> > "Area.mueveA(x,y)" with the appropiate coordinates will effectively
"drag"
> the
> > area (and its related DynLayer, if any) to the new mouse coordinates.
> >
> > They also rely on two small "all-purpose" auxiliar files: "funcaux.js"
and
> > "funcesp.js" that give some general methods to simplify code. The
complete
> list
> > will be posted or sent on request, but I will just mention the
> cross-browser
> > compatible "BuscaImagen(nombre)" that searches for any image in any
layer
> of the
> > document by name, even in nested layers in NS4. Returns "null" on error
> and the
> > image object on success.
> >
> > I hope these (and other objects I have created) will help developers get
a
> more
> > interactive content to their DHTML pages.
> >
> > Raides J.
> >
> > _______________________________________________
> > Dynapi-Dev mailing list
> > Dyn...@li...
> > http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
> > ____________________________________________________________
> > Get your free domain name and domain-based e-mail from
> > Namezero.com. New!  Namezero Plus domains now available.
> > Find out more at: http://www.namezero.com
> >
>
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
>

Re: [Dynapi-Dev] [Bug #128263] PathAnimation.stopAnimation() bug (& patch)

[Richard :o <ma...@ri...>]

Of course you should attache the files, is there also a working example
somewhere?

Cheers,
Richard  :o

ma...@ri...
www.richardinfo.com
(Everything running on, and ported to the 19/12/2000 snapshot of DynAPI2)

----- Original Message -----
From: "Raides J." <ra...@te...>
To: <dyn...@li...>
Sent: Thursday, January 11, 2001 2:02 PM
Subject: Re: [Dynapi-Dev] [Bug #128263] PathAnimation.stopAnimation() bug (&
patch)


> > Raymond Smith wrote:
> >
> > You know what we need.  A super button widget.  I just noticed I have
for js
> > calls for differing button type.  The ideal button would:
> >
> > 1) Contain the ability to;
> > a) be defined and colored ala HTML (button.js)
> > b) pull in images (ala ButtonImage), but have three states: static,
mouseover
> > and clicked
> > c) act as a 'href clicked marker", ie.... have a chnage state per
session if
> > it has been clicked once.
> > d) perform as a check box (boolean toggle, imagebutton.js)
> > e) and have the abilty to be skined and defined by multiple themes.
> >
> > I have all this spread across 4 differing widgets, once I integrate this
into
> > a super hacked version of what little I know I will contribute it.
> >
> > Later
>
> It's not just that, but I have two .js that I can send you under request
> (different versions available, so you have to ask which one you choose)
that
> implement what I call an "active area", i.e. a region in web-page space
which
> responds to mouse events and generates its own event calls, and what I
call an
> "icon", which is a 4-state imagebutton (all 4 images can be the same).
> The "Icono" (the name of the object icon) object has methods to activate
it
> (state=0), deactivate it (state=3) and change it's default state (0=on,
> 1=mouseover, 2=click, 3=off). They generate just the "onClick" event when
> clicked and active with a parameter which is the index of the icon in the
"Area"
> (the active area object) they MUST be contained on to work. This way you
can
> group them logically and assign the same method to the "onClick" event of
each
> related group of buttons and then differentiate in code using a "switch()"
> statement. One interesting "side-effect" derived from the way I have
implemented
> the "Icono" is that you can have a different image in place of the icon,
and it
> gets replaced on the first mouse event on the icon. Other side-effect is
that
> you can have the area and the icon responding to mouse events in one place
of
> the page and the associated image changing state in other part ;)
> The "Area" object is rather different. One of the versions needs always a
> DynLayer 1.0 version of layer to attach itself to for the dimension
information
> (the older version). The other two versions can be created independent of
any
> other object or attached to DynLayers 1.0 and DynAPI DynLayers
respectively.
> They have methods to change the size of the active area, to move the
top-left
> corner, to activate and deactivate them, and to dump it's internal
information
> as an "alert" method. The events fired are of a wide sort and ALL provide
the
> mouse coordinates in RELATIVE or ABSOLUTE (page relative) vaues when the
event
> fired. Overimposed areas fire all at the same time if they are active, so
> multiple areas can react to a single mouse event at once. The mouse events
are:
> onMouseIn --> Fires just when the mouse enters the area and just once
> onMouseDown --> Fires on the mouse down phase of a button press (just the
left
> button)
> onMouseUp --> Fires on the mouse up phase of a button press (just the left
> button). This only fires IF the mouse is INSIDE the area. In case it's
moved
> outside while the mouse is down (dragging), the event fired will be the
next
> one.
> onMouseOut --> Fires just once the mouse exits from the area and after an
> "onMouseIn" event has occurred. It can fire in the middle of an
> "onMouseDown"-"onMouseUp" sequence.
> onMouseOver --> Fires WHILE the mouse is INSIDE the area.
> onClick --> Fires IF the "onMouseDown" AND the "onMouseUp" events occur in
> sequence and INSIDE the area. If the mouse gets out of the area before the
> button is up, no event is fired.
>
> The usual sequence for this events is: "onMouseIn" - "onMouseOver" (more
than
> once) - "onMouseOut" for the mouse movement events, and "onMouseDown" -
> "onMouseUp" - "onClick" for the button mouse events. This more than
extends the
> standard behaviour and you can easily add an "onMouseUpOut" event to
capture the
> button release when it started inside and ended outside of the area, so an
> "Area.mueveA(x,y)" with the appropiate coordinates will effectively "drag"
the
> area (and its related DynLayer, if any) to the new mouse coordinates.
>
> They also rely on two small "all-purpose" auxiliar files: "funcaux.js" and
> "funcesp.js" that give some general methods to simplify code. The complete
list
> will be posted or sent on request, but I will just mention the
cross-browser
> compatible "BuscaImagen(nombre)" that searches for any image in any layer
of the
> document by name, even in nested layers in NS4. Returns "null" on error
and the
> image object on success.
>
> I hope these (and other objects I have created) will help developers get a
more
> interactive content to their DHTML pages.
>
> Raides J.
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
> ____________________________________________________________
> Get your free domain name and domain-based e-mail from
> Namezero.com. New!  Namezero Plus domains now available.
> Find out more at: http://www.namezero.com
>

Re: [Dynapi-Dev] Still talking to myself....

[<cam...@ya...>]

one or two things that can can wrong with images in
loadpanels using netscape.

for one, if you are using relative paths, the paths to
the image's must be relative to root document, not the
document you are loading into the loadpanel. I can't
remember if netscape works this way, or if it's ie, or
maybe both. the easiest thing to do is make your links
absolute.

if you are still having trouble, particularily with
netscape getting getting a transfer interuptted thing
part way through loading something into the loadpanel,
let me know.

--- Raymond Smith <dst...@or...> wrote: > Is
Netscape... inherently a lazy candyass? 
> Loadpanel works, it just forgets
> to render the images contained in html.
> Hope your right Cam.
> 
> Later all.
> ----- Original Message -----
> From: "Cameron Hart" <cam...@ya...>
> To: <dyn...@li...>
> Sent: Thursday, January 11, 2001 4:19 AM
> Subject: Re: [Dynapi-Dev] Still talking to
> myself....
> 
> 
> > > how to integrate a loadpanel into a window that
> > > doesn't really exist till
> > > you give birth to it.... and then have 'it'
> (once
> > > born) actually perform a
> > > call to load itself.
> >
> > That should work automatically, as loadpanel
> doesn't
> > load the url until the loadpanel has been created.
> if
> > you have a loadpanel in a window, it won't be
> created
> > (and thus load the url) until the window is. i'm
> > presuming that the window you are talking about is
> a
> > layer thing, rather than a browser window...
> >
> > cam.
> >
> >
> > > Later...
> > >
> > > ----- Original Message -----
> > > From: "Raymond Smith" <dst...@or...>
> > > To: <dyn...@li...>
> > > Sent: Thursday, January 11, 2001 1:45 AM
> > > Subject: [Dynapi-Dev] Getting into it, on a "
> lower
> > > " plane...
> > >
> > >
> > > > Ok, picking up on 'Ilmestro' here.  Just
> working
> > > on a slightly lower
> > > > intellectual plane.
> > > >
> > > > I got the loadpanels (via labels) working
> inside
> > > of pushpanels, kinda
> > > > <mutter>.  Unfortunately... , Pushpanel isn't
> > > smart enough to resize
> > > itself
> > > > after content 'insertion'.  I tried setContent
> > > from viewport but that
> > > failed
> > > > miserably.  I came up with a work around
> (reset
> > > does work and I have to
> > > > oversize the Label to accomodate "expected"
> > > content)  Not pretty I know..
> > > > but it will have to work til I figure out what
> you
> > > guys already know.
> > > >
> > > > DS
> > > >
> > > >
> > > >
> _______________________________________________
> > > > Dynapi-Dev mailing list
> > > > Dyn...@li...
> > > >
> > >
> >
>
http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
> > > >
> > >
> > >
> > > _______________________________________________
> > > Dynapi-Dev mailing list
> > > Dyn...@li...
> > >
> >
>
http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
> > >
> > >
> >
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Yahoo! Photos - Share your holiday photos online!
> > http://photos.yahoo.com/
> >
> > _______________________________________________
> > Dynapi-Dev mailing list
> > Dyn...@li...
> >
>
http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
> >
> 
> 
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
>
http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
> 
> 


__________________________________________________
Do You Yahoo!?
Yahoo! Photos - Share your holiday photos online!
http://photos.yahoo.com/

Re: [Dynapi-Dev] Still talking to myself....

[Michael P. <mp...@ph...>]

I'm not using a method of "talking" between Java and JS.  I am using
Java Classes as JS Objects.  This requires no compiling of my own applet
and also requires no external files at all.

See the attached file.  I have allowed for html files to be used by
extracting specific sections (title and body for starters).  This will
eventually allow you to load an external html file into a SkinWindow and
have the title of the window set according to the html page.

I'm working on a method of also extracting JS source code from the file
and executing it.  It currently working if you load a .js file.  The
whole file is then eval()ed.

Cameron Hart wrote:

> I found a few documents on talking to java using js in
> ie, but they're all on my computer in another office.
> have you seen the ticker thing on builder.com? it was
> using jscript to control a java ticker, it worked in
> ie using activex. someone posted the url to this list
> a while ago (maybe it was you?). if you haven't seen
> the builder.com article let me know, i'll try and
> track down the link.
>
> the only downside on this solution is there is no
> liveconnect, and no activex in ie on the mac, so it's
> unlikely that a java solution would work for mac ie
> users. then again loadpanel doesn't work on mac ie
> either...
>
> --- Michael Pemberton <mp...@ph...> wrote: >
> If someone is willing to give me some help with the
> > JScript component, I've
> > found a way of retieving the content of a URL to
> > then put it into a layer using
> > .setHTML().  It doesn't need any extensive code such
> > as the LoadPanel and will
> > work with any standard layer.
> >
> > BTW, the NS version that uses Java works fine.  It
> > is only IE that won't allow
> > me to use Java objects in the actual code.  I need
> > to find an object that works
> > with web files the way that the FileSystemObject
> > works for local files.
> >
> > Also, because I am using Java / ActiveX to download
> > the files, there is no need
> > for queues or separate loading of files.
> >
> > Raymond Smith wrote:
> >
> > > Fatigue setting in, things are running smooth as I
> > continue to debug the
> > > "trivial".  Going let you European lads finish the
> > balance of  "your day" in
> > > peace.  I think a few hours of sleep to recharge
> > the Brain Calories is in
> > > order.  Tomorrow I have to tackle Pascal "my
> > mother named me after a
> > > computer language" Bestebroer's dynamic skinwindow
> > and hopefully figure out
> > > how to integrate a loadpanel into a window that
> > doesn't really exist till
> > > you give birth to it.... and then have 'it' (once
> > born) actually perform a
> > > call to load itself.
> > >
> > > Later...
> > >
> > > ----- Original Message -----
> > > From: "Raymond Smith" <dst...@or...>
> > > To: <dyn...@li...>
> > > Sent: Thursday, January 11, 2001 1:45 AM
> > > Subject: [Dynapi-Dev] Getting into it, on a "
> > lower " plane...
> > >
> > > > Ok, picking up on 'Ilmestro' here.  Just working
> > on a slightly lower
> > > > intellectual plane.
> > > >
> > > > I got the loadpanels (via labels) working inside
> > of pushpanels, kinda
> > > > <mutter>.  Unfortunately... , Pushpanel isn't
> > smart enough to resize
> > > itself
> > > > after content 'insertion'.  I tried setContent
> > from viewport but that
> > > failed
> > > > miserably.  I came up with a work around (reset
> > does work and I have to
> > > > oversize the Label to accomodate "expected"
> > content)  Not pretty I know..
> > > > but it will have to work til I figure out what
> > you guys already know.
> > > >
> > > > DS
> > > >
> > > >
> > > > _______________________________________________
> > > > Dynapi-Dev mailing list
> > > > Dyn...@li...
> > > >
> >
> http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
> > > >
> > >
> > > _______________________________________________
> > > Dynapi-Dev mailing list
> > > Dyn...@li...
> > >
> >
> http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
> >
> >
> >
> > _______________________________________________
> > Dynapi-Dev mailing list
> > Dyn...@li...
> >
> http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
> >
> >
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Photos - Share your holiday photos online!
> http://photos.yahoo.com/
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/mailman/listinfo/dynapi-dev

--
Michael Pemberton
mp...@ph...
ICQ: 12107010

Re: [Dynapi-Dev] [Bug #128263] PathAnimation.stopAnimation() bug (& patch)

[Raides J. <ra...@te...>]

> Raymond Smith wrote:
> 
> You know what we need.  A super button widget.  I just noticed I have for js
> calls for differing button type.  The ideal button would:
> 
> 1) Contain the ability to;
> a) be defined and colored ala HTML (button.js)
> b) pull in images (ala ButtonImage), but have three states: static, mouseover
> and clicked
> c) act as a 'href clicked marker", ie.... have a chnage state per session if
> it has been clicked once.
> d) perform as a check box (boolean toggle, imagebutton.js)
> e) and have the abilty to be skined and defined by multiple themes.
> 
> I have all this spread across 4 differing widgets, once I integrate this into
> a super hacked version of what little I know I will contribute it.
> 
> Later

	It's not just that, but I have two .js that I can send you under request
(different versions available, so you have to ask which one you choose) that
implement what I call an "active area", i.e. a region in web-page space which
responds to mouse events and generates its own event calls, and what I call an
"icon", which is a 4-state imagebutton (all 4 images can be the same).
	The "Icono" (the name of the object icon) object has methods to activate it
(state=0), deactivate it (state=3) and change it's default state (0=on,
1=mouseover, 2=click, 3=off). They generate just the "onClick" event when
clicked and active with a parameter which is the index of the icon in the "Area"
(the active area object) they MUST be contained on to work. This way you can
group them logically and assign the same method to the "onClick" event of each
related group of buttons and then differentiate in code using a "switch()"
statement. One interesting "side-effect" derived from the way I have implemented
the "Icono" is that you can have a different image in place of the icon, and it
gets replaced on the first mouse event on the icon. Other side-effect is that
you can have the area and the icon responding to mouse events in one place of
the page and the associated image changing state in other part ;)
	The "Area" object is rather different. One of the versions needs always a
DynLayer 1.0 version of layer to attach itself to for the dimension information
(the older version). The other two versions can be created independent of any
other object or attached to DynLayers 1.0 and DynAPI DynLayers respectively.
They have methods to change the size of the active area, to move the top-left
corner, to activate and deactivate them, and to dump it's internal information
as an "alert" method. The events fired are of a wide sort and ALL provide the
mouse coordinates in RELATIVE or ABSOLUTE (page relative) vaues when the event
fired. Overimposed areas fire all at the same time if they are active, so
multiple areas can react to a single mouse event at once. The mouse events are:
	onMouseIn --> Fires just when the mouse enters the area and just once
	onMouseDown --> Fires on the mouse down phase of a button press (just the left
button)
	onMouseUp --> Fires on the mouse up phase of a button press (just the left
button). This only fires IF the mouse is INSIDE the area. In case it's moved
outside while the mouse is down (dragging), the event fired will be the next
one.
	onMouseOut --> Fires just once the mouse exits from the area and after an
"onMouseIn" event has occurred. It can fire in the middle of an
"onMouseDown"-"onMouseUp" sequence.
	onMouseOver --> Fires WHILE the mouse is INSIDE the area.
	onClick --> Fires IF the "onMouseDown" AND the "onMouseUp" events occur in
sequence and INSIDE the area. If the mouse gets out of the area before the
button is up, no event is fired.

	The usual sequence for this events is: "onMouseIn" - "onMouseOver" (more than
once) - "onMouseOut" for the mouse movement events, and "onMouseDown" -
"onMouseUp" - "onClick" for the button mouse events. This more than extends the
standard behaviour and you can easily add an "onMouseUpOut" event to capture the
button release when it started inside and ended outside of the area, so an
"Area.mueveA(x,y)" with the appropiate coordinates will effectively "drag" the
area (and its related DynLayer, if any) to the new mouse coordinates.

	They also rely on two small "all-purpose" auxiliar files: "funcaux.js" and
"funcesp.js" that give some general methods to simplify code. The complete list
will be posted or sent on request, but I will just mention the cross-browser
compatible "BuscaImagen(nombre)" that searches for any image in any layer of the
document by name, even in nested layers in NS4. Returns "null" on error and the
image object on success.

	I hope these (and other objects I have created) will help developers get a more
interactive content to their DHTML pages.

	Raides J.

Re: [Dynapi-Dev] This is my war

[Jordi 'I. M. <jmi...@or...>]

I'm discovering lots of things about the event model now that we have the precreation code. I don't really
know if it has always been the same but I never realized.

If you could just have a little patience I think I can beat it.



Jordi 'IlMaestro' Ministral wrote:

> I'm missing events... did I screw something ? First I thought but then going back to the latest code (
> before my modifications ) I am missing those same events. Ohh please just a little luck from time to
> time !!!!!
>
> In NS you can apply the same "for (each image in doc) img.lyrobj = myself" event trick to the links
> array.
>
> Jordi 'IlMaestro' Ministral wrote:
>
> > I have updated CVS with a new events.js that should fix IEs event problems. All the example files
> > worked fine. This is what happened ( at least this is something I found, maybe there are still
> > other issues ):
> >
> > - All browser events in DynAPI are captured and passed to the same EventMethod. This eventMethod
> > identifyes the physical layer, cancels browser event, searches for the appropiate DynmLayer object
> > and invokes its event.
> >
> > - In IE, in order to access the DynLayer object we use the lyrobj property of the DIV itself. This
> > property is set when creating a layer so from code executed within the DIV's scope we can still get
> > to our DynLayer obj. The problem with our contents was that when clicking on a text, most of the
> > times the srcElement of the event was not the DIV but a FONT, TD, TR, TABLE, UL,... element. That
> > element did not have a pointer to the dynlayer and thus the API could not route the event properly.
> >
> > - This issue was partially solved for images by doing:
> >
> > if (is.ie) for (i in dlyr.elm.all.tags("img")) dlyr.elm.all.tags("img")[i].lyrobj=dlyr;
> >
> > So images had a pointer to the layer aswell. This we would have needed to do to all elements in our
> > content, somethig really painful. Instead, I added this line inside eventmethod.
> >
> >  for(;is.ie && !realsrc.lyrobj && realsrc.parentElement &&
> > realsrc.parentElement!=realsrc;realsrc=realsrc.parentElement);
> >
> > Which actually makes realsrc travel IE's object hierarchy until we find the lyrobj reference. By
> > doing so I fixed events in IE5 and 5.5. I'm not that sure everything is fine now, but it is an
> > improvement.
> >
> > There are several lines in that method such as that
> >
> > if (e.type=="mouseover" || e.type=="mouseout") return false;
> >
> > just before the bubbleEvent() call that I don't understand but I prefer not to touch them.
> >
> > By the way, it seems that when clicking on a selectable text, NS does not fire a click event.
> > Mousedown and mouseup are fired, but click isn't. We could fire it manually but then when clicking
> > outside a text we would get two onclicks.
> >
> > Tell me if I broke something. Sure I did.
> >
> > Cya
> >
> > _______________________________________________
> > Dynapi-Dev mailing list
> > Dyn...@li...
> > http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/mailman/listinfo/dynapi-dev