Menu
▾
▴
dynapi-help
|
From: Digital S. <dst...@or...> - 2001-06-26 21:07:40
|
layer1 is layer1. Not sure what your up too, human minds have a way of forging their own unique trails. Basically you set up layer1 and use either setHTML or the DynImage extensions to set the first image. Then any following image changes will be done via an eventhandler that triggers layer1.setHTML (image HTML and SRC information). You could also use setBgImage() but it has forces a full server reload on each trigger so setHTML is cleaner (IE less timedials).. Laters -----Original Message----- From: dyn...@li... [mailto:dyn...@li...]On Behalf Of Tom Wilcoxen Sent: Tuesday, June 26, 2001 1:00 PM To: dyn...@li... Subject: [Dynapi-Help] How to get the id of the current layer? I'm want to use this for an image swap: layer1.doc.images['someimg'].src = but I don't know what the value for 'layer1' will be in advance. Is there a way to find out? Thanks, Tom __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/ _______________________________________________ Dynapi-Help mailing list Dyn...@li... http://lists.sourceforge.net/lists/listinfo/dynapi-help --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.256 / Virus Database: 129 - Release Date: 5/31/2001 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.256 / Virus Database: 129 - Release Date: 5/31/2001 |
|
From: Tom W. <tom...@ya...> - 2001-06-26 21:15:24
|
Sorry, I wasn't very clear. I have a menu widget that I'll use to create any number of menus on the page. Each has a layer on it that has html placed with setHTML. So I'll have about 7 of these menus/layers and I don't know how to tell which one called the rollover function. -Tom --- Digital Strider <dst...@or...> wrote: > layer1 is layer1. Not sure what your up too, human minds have a way > of > forging their own unique trails. > > Basically you set up layer1 and use either setHTML or the DynImage > extensions to set the first image. Then any following image changes > will be > done via an eventhandler that triggers layer1.setHTML (image HTML and > SRC > information). > > You could also use setBgImage() but it has forces a full server > reload on > each trigger so setHTML is cleaner (IE less timedials).. > > Laters > > -----Original Message----- > From: dyn...@li... > [mailto:dyn...@li...]On Behalf Of Tom > Wilcoxen > Sent: Tuesday, June 26, 2001 1:00 PM > To: dyn...@li... > Subject: [Dynapi-Help] How to get the id of the current layer? > > > I'm want to use this for an image swap: > > layer1.doc.images['someimg'].src = > > but I don't know what the value for 'layer1' will be in advance. Is > there a way to find out? > > Thanks, > Tom __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/ |
|
From: Eytan H. <ey...@tr...> - 2001-06-26 21:16:21
|
Why don't you just use the this reference? |
|
From: jirka <li...@in...> - 2001-06-27 11:33:32
|
you can do it like this:
// event listeners for icon mouse events
function addEtoI(e) {
for (i=1; i<=5; i++) {
var L = eval ("i" +i+ "L")
eval ("i" +i+ "E = new EventListener(i" +i+ "L)")
var E = eval ("i" +i+ "E")
E.onmouseover=function(e) {iOver(e.getTarget());}
E.onmouseout=function(e){iOut(e.getTarget());}
E.onclick=function(e){iClick(e.getTarget())}
L.addEventListener(E)
}
}
i leave it up to you to figure out what the "e" passed to the function is.
mind the syntax, this code is from version 2000.01.21.
good luck,
jirka
::-----Original Message-----
::From: dyn...@li...
::[mailto:dyn...@li...]On Behalf Of
::Eytan Heidingsfeld
::Sent: Wednesday, June 27, 2001 12:20 AM
::To: dyn...@li...
::Subject: RE: [Dynapi-Help] How to get the id of the current layer?
::
::
::Why don't you just use the this reference?
::
::_______________________________________________
::Dynapi-Help mailing list
::Dyn...@li...
::http://lists.sourceforge.net/lists/listinfo/dynapi-help
::
|
|
From: Dougal C. <do...@gu...> - 2001-06-29 20:52:33
|
I've got some links defined that use href="javascript:..." to pop up some DynLayers. For (extreme) backwards compatibility, I wanted to change the hrefs to reference actual html files, and use the onclick event instead. I figured that this way, script-enabled browsers will get the mega gui version of my site, but somebody with lynx could still access content. I tried something like this: <a href="foo.html" onclick="showGuiWin(); return false;">Foo!</a> In a simple case, this would work fine. The "return false" would tell the browser to *not* actualy load the foo.html page. But it seems that DynAPI's events are passing the click through anyways, so what happens is that the showGuiWin() function is executed, but then the browser loads foo.html. How can I accomplish what I'm trying to do? -- Ernest MacDougal Campbell III, MCP+I, MCSE <do...@gu...> http://dougal.gunters.org/ http://spam.gunters.org/ Lumber Cartel Unit #1654 (tinlc): http://come.to/the.lumber.cartel/ This message is guaranteed to be 100% eror frea! |
|
From: Michael P. <mp...@ph...> - 2001-06-30 11:57:00
|
You could try putting this link on a "splash" page that does not use the dynapi mouse events. This will allow you to support the onclick method of the href. From my memoery, the current event structure overrides the user defined mouse events on links. This is the same problem that was being had with onload events being placed in the body tag being overridden the by the dynapi load handler. The code to get around this for NS4 href links would be too great a burden. It would require making a hook for each link in the page and then evaluating it as part of the dynapi event bubbling. Dougal Campbell wrote: > I've got some links defined that use href="javascript:..." to pop up > some DynLayers. For (extreme) backwards compatibility, I wanted to > change the hrefs to reference actual html files, and use the onclick > event instead. I figured that this way, script-enabled browsers will get > the mega gui version of my site, but somebody with lynx could still > access content. > > I tried something like this: > <a href="foo.html" onclick="showGuiWin(); return false;">Foo!</a> > > In a simple case, this would work fine. The "return false" would tell > the browser to *not* actualy load the foo.html page. > > But it seems that DynAPI's events are passing the click through anyways, > so what happens is that the showGuiWin() function is executed, but then > the browser loads foo.html. > > How can I accomplish what I'm trying to do? > > -- > Ernest MacDougal Campbell III, MCP+I, MCSE <do...@gu...> > http://dougal.gunters.org/ http://spam.gunters.org/ > Lumber Cartel Unit #1654 (tinlc): http://come.to/the.lumber.cartel/ > This message is guaranteed to be 100% eror frea! > > _______________________________________________ > Dynapi-Help mailing list > Dyn...@li... > http://lists.sourceforge.net/lists/listinfo/dynapi-help -- Michael Pemberton mp...@ph... ICQ: 12107010 |
|
From: Richard B. <ric...@sk...> - 2001-07-01 07:19:25
|
Hi, I didn't receive the original of this message, so I reply to this reply. I needed the same functionality, and came up with this solution: Remember, we are trying to use a link like this: <a href="http://www.cnn.com" onclick=alert("hi");return false;>click</a> This would normally only show the alert, as the navigation has been cancelled by the "return false". This doesn't work in DynAPI however. So, in mouse.js I added this: browserReturn = true at line 33 just after "DynMouseEvent.forceMouseUp = false" and changed line 64 from "evt.browserReturn=true" to evt.browserReturn=browserReturn; Now in links where you want to cancel the default navigation you do this: <a href="http://www.cnn.com" onclick=alert("hi");browserReturn=false;>click</a> And it works the same as "return false" would. All other links keep normal behavior. Note that you now no longer need to use "javascript:void(0)" it will work fine like this: <a href="" onclick=alert("hi");browserReturn=false;>click</a> This has not been thoroughly tested yet, so I'm not sure if this is the best solution, or if this should be in CVS or not... BTW, I'm also going to be making a backwards-compatible (readable in browsers without javascript, or javascript version 1.0) dynapi page soon, so any tips you (Ernest or others) have would be appreciated. Cheers, Richard Bennett ma...@ri... www.richardinfo.com (Everything running on, and ported to DynAPI2.53) visit the DynAPI homepage (and FAQ) :: http://dynapi.sourceforge.net/dynapi/index.php?menu=1 Browse (and search) the mailinglist here: http://www.mail-archive.com/index.php3?hunt=dynapi ----- Original Message ----- From: "Michael Pemberton" <mp...@ph...> To: <dyn...@li...> Sent: 30 June, 2001 13:56 Subject: Re: [Dynapi-Help] (no subject) > You could try putting this link on a "splash" page that does not use the > dynapi mouse events. This will allow you to support the onclick method of > the href. > > >From my memoery, the current event structure overrides the user defined > mouse events on links. This is the same problem that was being had with > onload events being placed in the body tag being overridden the by the > dynapi load handler. > > The code to get around this for NS4 href links would be too great a burden. > It would require making a hook for each link in the page and then evaluating > it as part of the dynapi event bubbling. > > Dougal Campbell wrote: > > > I've got some links defined that use href="javascript:..." to pop up > > some DynLayers. For (extreme) backwards compatibility, I wanted to > > change the hrefs to reference actual html files, and use the onclick > > event instead. I figured that this way, script-enabled browsers will get > > the mega gui version of my site, but somebody with lynx could still > > access content. > > > > I tried something like this: > > <a href="foo.html" onclick="showGuiWin(); return false;">Foo!</a> > > > > In a simple case, this would work fine. The "return false" would tell > > the browser to *not* actualy load the foo.html page. > > > > But it seems that DynAPI's events are passing the click through anyways, > > so what happens is that the showGuiWin() function is executed, but then > > the browser loads foo.html. > > > > How can I accomplish what I'm trying to do? > > > > -- > > Ernest MacDougal Campbell III, MCP+I, MCSE <do...@gu...> > > http://dougal.gunters.org/ http://spam.gunters.org/ > > Lumber Cartel Unit #1654 (tinlc): http://come.to/the.lumber.cartel/ > > This message is guaranteed to be 100% eror frea! > > > > _______________________________________________ > > Dynapi-Help mailing list > > Dyn...@li... > > http://lists.sourceforge.net/lists/listinfo/dynapi-help > > -- > Michael Pemberton > mp...@ph... > ICQ: 12107010 > > > > > _______________________________________________ > Dynapi-Help mailing list > Dyn...@li... > http://lists.sourceforge.net/lists/listinfo/dynapi-help > |
|
From: Richard B. <ric...@sk...> - 2001-07-01 07:32:45
|
Another thing, once that's working, you can also use the href property to
show custom statusbar messages, without using onmouseover, onmouseout (if
you don't need backward compatibility).
It seems however that you *must* define a protocol, or the browser shows the
whole path as well.
The browser seems to check if there's a word followed by a colon (:) in
which case it accepts that as a valid protocol, so this works nicely:
<a href="Message: Clicking this link will open an alert"
onclick=alert("hi");browserReturn=false;>click</a>
Cheers,
Richard Bennett
ma...@ri...
www.richardinfo.com
(Everything running on, and ported to DynAPI2.53)
visit the DynAPI homepage (and FAQ) ::
http://dynapi.sourceforge.net/dynapi/index.php?menu=1
Browse (and search) the mailinglist here:
http://www.mail-archive.com/index.php3?hunt=dynapi
|
|
From: Doug M. <do...@cr...> - 2001-06-30 23:26:33
|
Fro your description all you should needc to do is change href="foo.html" to href="javascript:void(null)" ----- Original Message ----- From: "Dougal Campbell" <do...@gu...> To: "DynAPI-Help" <dyn...@li...> Sent: Friday, June 29, 2001 1:52 PM Subject: [Dynapi-Help] (no subject) > I've got some links defined that use href="javascript:..." to pop up > some DynLayers. For (extreme) backwards compatibility, I wanted to > change the hrefs to reference actual html files, and use the onclick > event instead. I figured that this way, script-enabled browsers will get > the mega gui version of my site, but somebody with lynx could still > access content. > > I tried something like this: > <a href="foo.html" onclick="showGuiWin(); return false;">Foo!</a> > > In a simple case, this would work fine. The "return false" would tell > the browser to *not* actualy load the foo.html page. > > But it seems that DynAPI's events are passing the click through anyways, > so what happens is that the showGuiWin() function is executed, but then > the browser loads foo.html. > > How can I accomplish what I'm trying to do? > > -- > Ernest MacDougal Campbell III, MCP+I, MCSE <do...@gu...> > http://dougal.gunters.org/ http://spam.gunters.org/ > Lumber Cartel Unit #1654 (tinlc): http://come.to/the.lumber.cartel/ > This message is guaranteed to be 100% eror frea! > > > _______________________________________________ > Dynapi-Help mailing list > Dyn...@li... > http://lists.sourceforge.net/lists/listinfo/dynapi-help |
|
From: Joachim L. <lu...@ho...> - 2001-07-10 20:54:09
|
(This was an oldie)
At 2001-06-29 22:52, you wrote:
>I've got some links defined that use href="javascript:..." to pop up
>some DynLayers. For (extreme) backwards compatibility, I wanted to
>change the hrefs to reference actual html files, and use the onclick
>event instead. I figured that this way, script-enabled browsers will get
>the mega gui version of my site, but somebody with lynx could still
>access content.
>
>I tried something like this:
> <a href="foo.html" onclick="showGuiWin(); return false;">Foo!</a>
>
>In a simple case, this would work fine. The "return false" would tell
>the browser to *not* actualy load the foo.html page.
>
>But it seems that DynAPI's events are passing the click through anyways,
>so what happens is that the showGuiWin() function is executed, but then
>the browser loads foo.html.
>
>How can I accomplish what I'm trying to do?
I think alert() and other lengthy operations such as open new browser windows will cancel the return value (that was totally clear, wasn't it?) because the browser needs the return value ASAP (preferably sooner) and when the onclick event takes a long time the return value is scrapped. [I may be totally off track here, but that is how it appears to me.]
<a href="foo.html" onclick="setTimeout('showGuiWin();',0); return false;">Foo!</a>
should do the trick (and does for me).
/Lunna
|
|
From: Dougal C. <do...@gu...> - 2001-07-11 19:07:22
|
On Tue, 10 Jul 2001, Joachim Lundgren wrote:
[....]
> >But it seems that DynAPI's events are passing the click through anyways,
> >so what happens is that the showGuiWin() function is executed, but then
> >the browser loads foo.html.
> >
> >How can I accomplish what I'm trying to do?
>
>
> I think alert() and other lengthy operations such as open new browser windows will cancel the return value (that was totally clear, wasn't it?) because the browser needs the return value ASAP (preferably sooner) and when the onclick event takes a long time the return value is scrapped. [I may be totally off track here, but that is how it appears to me.]
>
> <a href="foo.html" onclick="setTimeout('showGuiWin();',0); return false;">Foo!</a>
>
> should do the trick (and does for me).
Nope, stil doesn't work for me. I've narrowed it down, and it has
something to do with DragEvents (I have draggable layers in my doc). I
set up a simple test case:
http://www.mentalcollective/test2.html
If you click the "stuff" link, it will display an alert. After you click
Okay, it loads the url from the link.
But look at:
http://www.mentalcollective/test3.html
The is the exact same code as test2, except I commented out the
DragEvent.enableDragEvents(myLayer)
line. And on this one, clicking the "stuff" link will *not* load the
url.
Something in the document is altered when DragEvents are enabled. And
even disabling them doesn't undo it (see the "Disable Dragging" link in
the blue layer).
--
Ernest MacDougal Campbell III, MCP+I, MCSE <do...@gu...>
http://dougal.gunters.org/ http://spam.gunters.org/
Lumber Cartel Unit #1654 (tinlc): http://come.to/the.lumber.cartel/
This message is guaranteed to be 100% eror frea!
|
|
From: Joachim L. <lu...@ho...> - 2001-07-11 20:46:02
|
At 2001-07-11 21:07, you wrote:
>[....]
>
>Nope, stil doesn't work for me. I've narrowed it down, and it has
>something to do with DragEvents (I have draggable layers in my doc). I
>set up a simple test case:
>
> http://www.mentalcollective/test2.html
>
>If you click the "stuff" link, it will display an alert. After you click
>Okay, it loads the url from the link.
>
>But look at:
> http://www.mentalcollective/test3.html
>
>The is the exact same code as test2, except I commented out the
> DragEvent.enableDragEvents(myLayer)
>line. And on this one, clicking the "stuff" link will *not* load the
>url.
>
>Something in the document is altered when DragEvents are enabled. And
>even disabling them doesn't undo it (see the "Disable Dragging" link in
>the blue layer).
Well, mouse.js is wrong - at the end of the DynMouseEvent.EventMethod function around line 147 it reads
// Click on links and form elements
if (e && e.target.handleEvent && e.target!=this) e.target.handleEvent(e);
It should be:
// Click on links and form elements
if(e && e.target.handleEvent && e.target!=this)
evt.browserReturn = e.target.handleEvent(e);
That change should of course be fully tested because it has global impact.
/Lunna
|
|
From: Dougal C. <do...@gu...> - 2001-07-11 21:29:13
|
On Wed, 11 Jul 2001, Joachim Lundgren wrote: [....] > >Something in the document is altered when DragEvents are enabled. And > >even disabling them doesn't undo it (see the "Disable Dragging" link in > >the blue layer). > > Well, mouse.js is wrong - at the end of the DynMouseEvent.EventMethod function around line 147 it reads > > // Click on links and form elements > if (e && e.target.handleEvent && e.target!=this) e.target.handleEvent(e); > > It should be: > > // Click on links and form elements > if(e && e.target.handleEvent && e.target!=this) > evt.browserReturn = e.target.handleEvent(e); > > That change should of course be fully tested because it has global impact. Aha! You almost had it! That particular line is inside an "if(is.ns4)". I moved it outside if the if() (to just before the return statement), and it's fixed the problem for me. Tested in NS4.75, NS6.1PR1, and IE5.5. Good catch! -- Ernest MacDougal Campbell III, MCP+I, MCSE <do...@gu...> http://dougal.gunters.org/ http://spam.gunters.org/ Lumber Cartel Unit #1654 (tinlc): http://come.to/the.lumber.cartel/ This message is guaranteed to be 100% eror frea! |
|
From: Joachim L. <lu...@ho...> - 2001-07-12 00:00:52
|
At 2001-07-12 00:13, you wrote:
>Well it looks like your right, but there are a few issues, firstly, this is
>only for NS4, the other browser code seems to be missing all together.
>I think the whole thing, crossbrowser should look like this:
>
>This replaces the line nr 147 in mouse.js:
>
>
>
> // Click on links and form elements
> if (e && e.target.handleEvent && e.target!=this)evt.browserReturn =
>e.target.handleEvent(e);
> }else{
> if(e&&e.srcElement!=this)evt.browserReturn =e.returnValue
>
>
>
>The closing bracket is already in the code.
>I tested this, and it solves the problem in IE5.5, Mozilla, and NS4.
>
>It does however cause NS4 to fire two onclick events over a regular
>dynlayer, I think this might be something Jordi could solve easily (?)
>
>Cheers,
>Richard Bennett
For some reason I thought the problem only appeared in NS4...
Now that this is being considered for inclusion in the codebase I suggest that the end of that function to be (indented so it looks better in email):
// Click on links and form elements
if(e && e.target.handleEvent && e.target!=this) {
evt.browserReturn = (e.target.handleEvent(e) == false)
? false
: evt.browserReturn;
}
}
else {
if(e && e.srcElement!=this)
evt.browserReturn = e.returnValue;
}
return evt.browserReturn;
}
The reason would be to allow the (in this case) onclick-handler to cancel the click with a "return false". If it instead returned "true" or nothing at all it should respect the evt.browserReturn value which is true by default unless changed by evt.cancelBrowserEvent().
This is, of course, untested. Haven't even checked what should be done in IE/Mozilla.
/Lunna
|
|
From: Joachim L. <lu...@ho...> - 2001-07-13 04:26:08
|
At 2001-07-13 00:52, you wrote:
>Yes, the NS changes would seem a good idea.
>I noticed that what I had suggested for IE was working by accident, I had
>expected e.returnValue to return the return value, but it doesn't, it
>returns undefined, which was being evaluated as false.
>The only way I found of retrieving the return value in IE was this:
>
>if(e.srcElement.attributes['on'+e.type].nodeValue.indexOf('return
>false')!=-1)
>
>which would return false if value = return false.
>I tried, but couldn't find how to get this value in Mozilla yet.
>Maybe I'm missing something obvious, as I hadn't expected it to be so hard
>to get hold of that value.
>
>I also added this:
>&& e.type!='mousemove'
>to the first if clause, for both IE and NS, otherwise the script is being
>executed constantly as the mouse moves over the page, or a link, and
>onmousemove never needs a return event that I know.
>Also without this check, NS4 started selecting text on the page while
>dragging a dynlayer.
>
>So now the whole thing looks like this:
>mouse.js from line 146:
>
> // Click on links and form elements
> if(e && e.target.handleEvent && e.target!=this&&
>e.type!='mousemove'){
> evt.browserReturn =
>(e.target.handleEvent(e)==false)?false:evt.browserReturn;
> }
> }else
>if(is.ie&&e&&e.srcElement!=this&&e.type!='mousemove'&&e.srcElement.attribute
>s['on'+e.type].nodeValue){
> evt.browserReturn =
>(e.srcElement.attributes['on'+e.type].nodeValue.indexOf('return
>false')!=-1)?false:evt.browserReturn;
> }
> return evt.browserReturn;
>}
>
>(mind line wraps)
>Like this, "return false" in the onclick listener of a hyperlink will cancel
>browser navigation, as it should. This works in IE and NS.
>I don't know if something simpler is possible for IE, and I haven't found
>the values for Mozila yet.
>
>Cheers,
>Richard Bennett
>
>ma...@ri...
>www.richardinfo.com
>(Everything running on, and ported to DynAPI2.53)
>visit the DynAPI homepage (and FAQ) ::
>http://dynapi.sourceforge.net/dynapi/index.php?menu=1
>Browse (and search) the mailinglist here:
>http://www.mail-archive.com/index.php3?hunt=dynapi
The nodeValue was (according to MS) first implemented in IE5.
But I tested what I had before and tweaked it a little bit:
// Click on links and form elements
if(e && e.target.handleEvent && e.target!=this && (e.target.handleEvent(e) == false))
evt.browserReturn = false;
}
else {
if(is.ie && e && e.srcElement!=this) // added is.ie so it doesn't run in moz
evt.browserReturn = e.returnValue;
}
if(is.dom && !evt.browserReturn) // these lines were missing before
e.preventDefault();
return evt.browserReturn;
}
(As you may have noticed I didn't include your e.type=="mousemove" test - with it too the handleEvent() wouldn't run.)
Now I got it working in IE and Mozilla (0.9.2), but not in NS4 where <A onclick> is never run but the click is cancelled anyway (the link isn't followed).
I suspect this fault is an interaction between the draglistener and EventMethod. The event listener calls cancelBrowserEvent both on mousedown and mouseup. Another observation is that IE and Mozilla call the <A onclick> first, then the eventlisteners. In NS4 it is the opposite.
It seems to me that a call to handleEvent is missing, but right now I can't find where it would be. Probably at the top of EventMethod. Another possible problem is the fact that the API-generated "click" event is invoked while the "mouseup" is. Maybe it's as easy as the "click" event changes some value that "mouseup" doesn't want changed (like the browserReturn value)?
I used this code to test the variations:
DynAPI.setLibraryPath("/dynapi/src/lib/");
DynAPI.include("dynapi.api.*");
DynAPI.include("dynapi.event.*")
var num=0;
DynAPI.onLoad = function() {
myLayer = new DynLayer();
DragEvent.enableDragEvents(myLayer);
myLayer.setHTML('<A href="misc.html" onclick="alert(1);return false">click</A>');
myListener = new EventListener();
myListener.onclick = function(e) {
DynAPI.document.setBgColor("#808080");
window.status = ++num;
}
myLayer.addEventListener(myListener);
DynAPI.document.addChild(myLayer)
}
That made it simple to test with/without enableDragEvents and returning true or false in the <A onclick>. Also indicates in which order the code is executed.
(In NS4: returning false for mousedown disables text selection, but not doing that gives you the option to return false for mousemoves which also disables text selection - more or less).
/Lunna
|
|
From: Richard B. <ric...@sk...> - 2001-07-11 22:17:07
|
Well it looks like your right, but there are a few issues, firstly, this is
only for NS4, the other browser code seems to be missing all together.
I think the whole thing, crossbrowser should look like this:
This replaces the line nr 147 in mouse.js:
// Click on links and form elements
if (e && e.target.handleEvent && e.target!=this)evt.browserReturn =
e.target.handleEvent(e);
}else{
if(e&&e.srcElement!=this)evt.browserReturn =e.returnValue
The closing bracket is already in the code.
I tested this, and it solves the problem in IE5.5, Mozilla, and NS4.
It does however cause NS4 to fire two onclick events over a regular
dynlayer, I think this might be something Jordi could solve easily (?)
Cheers,
Richard Bennett
ma...@ri...
www.richardinfo.com
(Everything running on, and ported to DynAPI2.53)
visit the DynAPI homepage (and FAQ) ::
http://dynapi.sourceforge.net/dynapi/index.php?menu=1
Browse (and search) the mailinglist here:
http://www.mail-archive.com/index.php3?hunt=dynapi
> Well, mouse.js is wrong - at the end of the DynMouseEvent.EventMethod
function around line 147 it reads
>
> // Click on links and form elements
> if (e && e.target.handleEvent && e.target!=this)
e.target.handleEvent(e);
>
> It should be:
>
> // Click on links and form elements
> if(e && e.target.handleEvent && e.target!=this)
> evt.browserReturn = e.target.handleEvent(e);
>
> That change should of course be fully tested because it has global impact.
>
> /Lunna
>
>
> _______________________________________________
> Dynapi-Help mailing list
> Dyn...@li...
> http://lists.sourceforge.net/lists/listinfo/dynapi-help
>
|
|
From: Benoit M. <mar...@ap...> - 2001-07-12 09:59:26
|
To come back to the initial point, I found out what in dragevent.js, onmousedown was making my form elements acting strangely in IE when I was clicking in the layer they are in, layer which is dragable. It's the onselectstart. I moved it to the onmousemove handler, just
before we fire the drag start event. I think it makes more sens, but It fixed my issues anyway !
Benoit Marchant
Joachim Lundgren wrote:
> At 2001-07-12 00:13, you wrote:
> >Well it looks like your right, but there are a few issues, firstly, this is
> >only for NS4, the other browser code seems to be missing all together.
> >I think the whole thing, crossbrowser should look like this:
> >
> >This replaces the line nr 147 in mouse.js:
> >
> >
> >
> > // Click on links and form elements
> > if (e && e.target.handleEvent && e.target!=this)evt.browserReturn =
> >e.target.handleEvent(e);
> > }else{
> > if(e&&e.srcElement!=this)evt.browserReturn =e.returnValue
> >
> >
> >
> >The closing bracket is already in the code.
> >I tested this, and it solves the problem in IE5.5, Mozilla, and NS4.
> >
> >It does however cause NS4 to fire two onclick events over a regular
> >dynlayer, I think this might be something Jordi could solve easily (?)
> >
> >Cheers,
> >Richard Bennett
>
> For some reason I thought the problem only appeared in NS4...
>
> Now that this is being considered for inclusion in the codebase I suggest that the end of that function to be (indented so it looks better in email):
>
> // Click on links and form elements
> if(e && e.target.handleEvent && e.target!=this) {
> evt.browserReturn = (e.target.handleEvent(e) == false)
> ? false
> : evt.browserReturn;
> }
> }
> else {
> if(e && e.srcElement!=this)
> evt.browserReturn = e.returnValue;
> }
>
> return evt.browserReturn;
> }
>
> The reason would be to allow the (in this case) onclick-handler to cancel the click with a "return false". If it instead returned "true" or nothing at all it should respect the evt.browserReturn value which is true by default unless changed by evt.cancelBrowserEvent().
>
> This is, of course, untested. Haven't even checked what should be done in IE/Mozilla.
>
> /Lunna
>
> _______________________________________________
> Dynapi-Help mailing list
> Dyn...@li...
> http://lists.sourceforge.net/lists/listinfo/dynapi-help
|
|
From: Richard B. <ric...@sk...> - 2001-07-12 22:55:32
|
Yes, the NS changes would seem a good idea.
I noticed that what I had suggested for IE was working by accident, I had
expected e.returnValue to return the return value, but it doesn't, it
returns undefined, which was being evaluated as false.
The only way I found of retrieving the return value in IE was this:
if(e.srcElement.attributes['on'+e.type].nodeValue.indexOf('return
false')!=-1)
which would return false if value = return false.
I tried, but couldn't find how to get this value in Mozilla yet.
Maybe I'm missing something obvious, as I hadn't expected it to be so hard
to get hold of that value.
I also added this:
&& e.type!='mousemove'
to the first if clause, for both IE and NS, otherwise the script is being
executed constantly as the mouse moves over the page, or a link, and
onmousemove never needs a return event that I know.
Also without this check, NS4 started selecting text on the page while
dragging a dynlayer.
So now the whole thing looks like this:
mouse.js from line 146:
// Click on links and form elements
if(e && e.target.handleEvent && e.target!=this&&
e.type!='mousemove'){
evt.browserReturn =
(e.target.handleEvent(e)==false)?false:evt.browserReturn;
}
}else
if(is.ie&&e&&e.srcElement!=this&&e.type!='mousemove'&&e.srcElement.attribute
s['on'+e.type].nodeValue){
evt.browserReturn =
(e.srcElement.attributes['on'+e.type].nodeValue.indexOf('return
false')!=-1)?false:evt.browserReturn;
}
return evt.browserReturn;
}
(mind line wraps)
Like this, "return false" in the onclick listener of a hyperlink will cancel
browser navigation, as it should. This works in IE and NS.
I don't know if something simpler is possible for IE, and I haven't found
the values for Mozila yet.
Cheers,
Richard Bennett
ma...@ri...
www.richardinfo.com
(Everything running on, and ported to DynAPI2.53)
visit the DynAPI homepage (and FAQ) ::
http://dynapi.sourceforge.net/dynapi/index.php?menu=1
Browse (and search) the mailinglist here:
http://www.mail-archive.com/index.php3?hunt=dynapi
----- Original Message -----
From: "Joachim Lundgren" <lu...@ho...>
To: <dyn...@li...>
Sent: 12 July, 2001 01:57
Subject: Re: [Dynapi-Help] NS4 link/event cancelling [Was: (no subject)]
> At 2001-07-12 00:13, you wrote:
> >Well it looks like your right, but there are a few issues, firstly, this
is
> >only for NS4, the other browser code seems to be missing all together.
> >I think the whole thing, crossbrowser should look like this:
> >
> >This replaces the line nr 147 in mouse.js:
> >
> >
> >
> > // Click on links and form elements
> > if (e && e.target.handleEvent && e.target!=this)evt.browserReturn
=
> >e.target.handleEvent(e);
> > }else{
> > if(e&&e.srcElement!=this)evt.browserReturn =e.returnValue
> >
> >
> >
> >The closing bracket is already in the code.
> >I tested this, and it solves the problem in IE5.5, Mozilla, and NS4.
> >
> >It does however cause NS4 to fire two onclick events over a regular
> >dynlayer, I think this might be something Jordi could solve easily (?)
> >
> >Cheers,
> >Richard Bennett
>
>
> For some reason I thought the problem only appeared in NS4...
>
> Now that this is being considered for inclusion in the codebase I suggest
that the end of that function to be (indented so it looks better in email):
>
> // Click on links and form elements
> if(e && e.target.handleEvent && e.target!=this) {
> evt.browserReturn = (e.target.handleEvent(e) == false)
> ? false
> : evt.browserReturn;
> }
> }
> else {
> if(e && e.srcElement!=this)
> evt.browserReturn = e.returnValue;
> }
>
> return evt.browserReturn;
> }
>
> The reason would be to allow the (in this case) onclick-handler to cancel
the click with a "return false". If it instead returned "true" or nothing at
all it should respect the evt.browserReturn value which is true by default
unless changed by evt.cancelBrowserEvent().
>
> This is, of course, untested. Haven't even checked what should be done in
IE/Mozilla.
>
> /Lunna
>
>
> _______________________________________________
> Dynapi-Help mailing list
> Dyn...@li...
> http://lists.sourceforge.net/lists/listinfo/dynapi-help
>
|
|
From: Richard B. <ric...@sk...> - 2001-07-14 09:08:37
|
This doesn't look correct to me, if you test for the value of e.returnValue;
in IE5.5, it will always return "undefined", which will of course seem to
work, but it is actually always returning false.
Also, shouldn't the dom test be inside the same "else" clause as the ie
test?
And using IE5+ wouldn't it first execute the IE clause, and then the dom
one?
I'm surprised the mousemove test affected handleEvent, as it seemed to work
ok here, and seemed to resolve some annoying textselection problems
especially in NS4, I'll give it a try with your sample code.
If you use this sample code, you'll see the textselection problem in NS4, as
you drag the blue layer:
DynAPI.onLoad = function() {
myLayer = new DynLayer('myLayer',0,50,50,50,'blue')
DragEvent.setDragBoundary(myLayer)
DragEvent.enableDragEvents(myLayer)
DynAPI.document.addChild(myLayer)
var clk=new EventListener()
clk.onclick=function(e) {
alert('hi')
}
myLayer.addEventListener(clk)
}
</script>
</head>
<body bgcolor="#000000">
<a href="Message: Click this to test" onclick="status='woot!';return
true;">stuff</a>
</body>
</html>
Richard.
> // Click on links and form elements
> if(e && e.target.handleEvent && e.target!=this &&
(e.target.handleEvent(e) == false))
> evt.browserReturn = false;
> }
> else {
> if(is.ie && e && e.srcElement!=this) // added is.ie so it doesn't
run in moz
> evt.browserReturn = e.returnValue;
> }
> if(is.dom && !evt.browserReturn) // these lines were missing before
> e.preventDefault();
> return evt.browserReturn;
> }
>
> (As you may have noticed I didn't include your e.type=="mousemove" test -
with it too the handleEvent() wouldn't run.)
>
> Now I got it working in IE and Mozilla (0.9.2), but not in NS4 where <A
onclick> is never run but the click is cancelled anyway (the link isn't
followed).
>
> I suspect this fault is an interaction between the draglistener and
EventMethod. The event listener calls cancelBrowserEvent both on mousedown
and mouseup. Another observation is that IE and Mozilla call the <A onclick>
first, then the eventlisteners. In NS4 it is the opposite.
>
> It seems to me that a call to handleEvent is missing, but right now I
can't find where it would be. Probably at the top of EventMethod. Another
possible problem is the fact that the API-generated "click" event is invoked
while the "mouseup" is. Maybe it's as easy as the "click" event changes some
value that "mouseup" doesn't want changed (like the browserReturn value)?
>
> I used this code to test the variations:
>
> DynAPI.setLibraryPath("/dynapi/src/lib/");
> DynAPI.include("dynapi.api.*");
> DynAPI.include("dynapi.event.*")
> var num=0;
> DynAPI.onLoad = function() {
> myLayer = new DynLayer();
> DragEvent.enableDragEvents(myLayer);
> myLayer.setHTML('<A href="misc.html" onclick="alert(1);return
false">click</A>');
> myListener = new EventListener();
> myListener.onclick = function(e) {
> DynAPI.document.setBgColor("#808080");
> window.status = ++num;
> }
> myLayer.addEventListener(myListener);
> DynAPI.document.addChild(myLayer)
> }
>
> That made it simple to test with/without enableDragEvents and returning
true or false in the <A onclick>. Also indicates in which order the code is
executed.
>
> (In NS4: returning false for mousedown disables text selection, but not
doing that gives you the option to return false for mousemoves which also
disables text selection - more or less).
>
> /Lunna
>
>
> _______________________________________________
> Dynapi-Help mailing list
> Dyn...@li...
> http://lists.sourceforge.net/lists/listinfo/dynapi-help
>
|
|
From: Richard B. <ric...@sk...> - 2001-07-14 09:15:17
|
You would of course need to change return true to return false in the sample code |
|
From: Joachim L. <lu...@ho...> - 2001-07-15 14:23:02
|
At 2001-07-14 11:05, you wrote:
>This doesn't look correct to me, if you test for the value of e.returnValue;
>in IE5.5, it will always return "undefined", which will of course seem to
>work, but it is actually always returning false.
Quite so, my error. I don't know why it worked here in my test-case, I can't make it do it again!
>Also, shouldn't the dom test be inside the same "else" clause as the ie
>test?
>
>And using IE5+ wouldn't it first execute the IE clause, and then the dom
>one?
Blaim that one on cut&paste - don't test for "is.dom" but "e.preventDefault".
>I'm surprised the mousemove test affected handleEvent, as it seemed to work
>ok here, and seemed to resolve some annoying textselection problems
>especially in NS4, I'll give it a try with your sample code.
>
>If you use this sample code, you'll see the textselection problem in NS4, as
>you drag the blue layer:
>
>
>DynAPI.onLoad = function() {
> myLayer = new DynLayer('myLayer',0,50,50,50,'blue')
>
> DragEvent.setDragBoundary(myLayer)
> DragEvent.enableDragEvents(myLayer)
> DynAPI.document.addChild(myLayer)
>
> var clk=new EventListener()
> clk.onclick=function(e) {
> alert('hi')
> }
> myLayer.addEventListener(clk)
>}
></script>
></head>
><body bgcolor="#000000">
><a href="Message: Click this to test" onclick="status='woot!';return
>true;">stuff</a>
></body>
></html>
>
>Richard.
The textselection shouldn't happen since the draglistener does a cancelBrowserEvent() on mousedown and mousemoves (I think the latter is superfluous - it is here at least).
I haven't made any changes to dragevent.js, all my checking/testing is done on mouse.js. If I remove the cancelBrowserEvent() in dragevent's onmousedown I too have the textselection bug.
I will try to make this work during the next few days (I've given up on a simple solution - or at least an easy-to-find one). I'll let you know what I come up with (in DynAPI-dev instead).
/Lunna
|
|
From: Bill Z. <bil...@ho...> - 2001-10-17 19:10:40
|
<html><div style='background-color:'><DIV>
<DIV>
<DIV>Hello all I am trying to create a layer that slides when the user mouses over some text. This is what I have come up with so far and it works onclick but not on mouseover. </DIV>
<DIV> </DIV>
<DIV>Help! Please</DIV>
<DIV> </DIV>
<DIV><script language="Javascript" src="../src/dynapi.js"></script><BR><script language="Javascript"><BR>DynAPI.setLibraryPath('../src/lib/');<BR>DynAPI.include('dynapi.event.*');<BR>DynAPI.include('dynapi.api.*');<BR>DynAPI.include('dynapi.event.*')<BR>DynAPI.include('dynapi.util.thread.js');<BR>DynAPI.include('dynapi.util.pathanim.js');<BR></script><BR><script language="Javascript"></DIV>
<DIV>DynAPI.onLoad=function() { </DIV>
<DIV> myLayer = new DynLayer(null, 100, 100, 100, 100, '#cc0000')<BR> <BR> var listener = new EventListener(myLayer)<BR> var listener2 = new EventListener(myLayer)<BR> <BR> listener.onmouseover = function (e) {<BR> listener2.onpathstart = function(e) {<BR> status = "start";<BR> }<BR> }<BR> listener.onmouseout = function (e) { <BR> listener2.onpathrun = function(e) {<BR> var o = e.getSource();<BR> status = "play "+o.x+" "+o.y;<BR> } <BR> }<BR> myLayer.addEventListener(listener2);<BR> myLayer.addEventListener(listener);<BR> <BR> </DIV>
<DIV> DynAPI.document.addChild(myLayer)<BR>}</DIV>
<DIV></script> </DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV><br>(<a href="javascript:myLayer.slideTo(100,100)">100,100</a>)<BR><br>(<a href="javascript:myLayer.slideTo(200,100)">200,100</a>)</DIV></DIV></DIV></div><br clear=all><hr>Get your FREE download of MSN Explorer at <a href='http://go.msn.com/bql/hmtag_itl_EN.asp'>http://explorer.msn.com</a><br></html>
|
|
From: Byrne, G. (euler:eti) <Ger...@eu...> - 2001-11-06 17:10:17
|
Hello, New to DynAPI. Very impressed with what I've seen. The help centre refers to the Form widget in Michael Pemberton's AfroAPI.. This is exactly what I need, but the link (<http://mpember.d2g.com/afroapix/> ) is no longer working. Does anybody know where I can get hold of the AforAPI? Thanks Ged. |
|
From: Doug M. <do...@cr...> - 2001-11-06 17:29:42
|
The main site is here: http://members.evolt.org/mpember/afroapix/ The latest release can be downloaded directly here: http://members.evolt.org/mpember/afroapix/archive/afroapix.2001.11.01.zip ----- Original Message ----- From: "Byrne, Gerald (euler:eti)" <Ger...@eu...> To: <dyn...@li...> Sent: Tuesday, November 06, 2001 12:09 PM Subject: [Dynapi-Help] (no subject) > Hello, > > New to DynAPI. Very impressed with what I've seen. > > The help centre refers to the Form widget in Michael Pemberton's AfroAPI.. > > This is exactly what I need, but the link > (<http://mpember.d2g.com/afroapix/> ) is no longer working. > > Does anybody know where I can get hold of the AforAPI? > > Thanks > > Ged. > > > _______________________________________________ > Dynapi-Help mailing list > Dyn...@li... > https://lists.sourceforge.net/lists/listinfo/dynapi-help |
|
From: Quang N. <ye...@ho...> - 2001-11-09 23:03:48
|
What is the techinical reason why we need DynAPI to display a layer? I
throught DynAPI was only to handle the library.
For example, why do we write like this
...
DynAPI.onLoad = function()
{
myLayer = new DynLayer()
myLayer.setSize(100,100)
myLayer.setBgColor('#c0c0c0')
myLayer.moveTo(100,100)
DynAPI.document.addChild(myLayer)
}
...
Instead of
...
myLayer = new DynLayer()
myLayer.setSize(100,100)
myLayer.setBgColor('#c0c0c0')
myLayer.moveTo(100,100)
...
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X