By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,827 Members | 2,211 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,827 IT Pros & Developers. It's quick & easy.

Attaching "onClick" javascript code to fireworks popup menu links

P: n/a
I am currenly developing a web site using Macromedia fireworks, and am
trying to figure out a way (through hand-coding) of attaching a
javascript function (onClick="doit=false") to each of the links in my
fireworks-generated dhtml popup menus. Does anyone here know where I
would add this javascript fucntion in the code so that it would be
recognized? And do I do it in the html, or in the JS file?

The javascript function I need to add is supposed to supress an exit
popup window. If I can't attach it to the links in the dhtml popup
menu, then that means that the popup will get spawned every time
someone click on one of the links, which woudl obviously be a problem.
Any tips or advice would be appreciated.

thanks,
- yvan
Jul 20 '05 #1
Share this Question
Share on Google+
6 Replies


P: n/a


Yvan J. Gagnon wrote:
I am currenly developing a web site using Macromedia fireworks, and am
trying to figure out a way (through hand-coding) of attaching a
javascript function (onClick="doit=false") to each of the links in my
fireworks-generated dhtml popup menus. Does anyone here know where I
would add this javascript fucntion in the code so that it would be
recognized? And do I do it in the html, or in the JS file?

The javascript function I need to add is supposed to supress an exit
popup window. If I can't attach it to the links in the dhtml popup
menu, then that means that the popup will get spawned every time
someone click on one of the links, which woudl obviously be a problem.
Any tips or advice would be appreciated.


I can't tell you anything about Firework menus, but an onclick handler
is attached with HTML as follows
<a href="whatever.html"
onclick="doit = false; return true;">Link</a>
If you want to attach the handler with script use
document.links[linkIndex].onclick = function (evt) {
doit = false; return true;
};
There are also IE5.5+ and Netscape 6 specific solutions which allow
attaching multiple event listeners to an element

--

Martin Honnen
http://JavaScript.FAQTs.com/

Jul 20 '05 #2

P: n/a
Martin Honnen <Ma***********@t-online.de> writes:
There are also IE5.5+ and Netscape 6 specific solutions which allow
attaching multiple event listeners to an element


I don't know what the IE solution is, but I assume the Netscape 6
solution you are referring to, is the addEventListener method.
It is not Netscape 6/Mozilla specific, but actually a W3C Standard
(DOM2 Events), and it also works in Opera 7+. I don't know if Safari
supports it, but I wouldn't be surprised, and if it doesn't, I bet
it will soon.

/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
Art D'HTML: <URL:http://www.infimum.dk/HTML/randomArtSplit.html>
'Faith without judgement merely degrades the spirit divine.'
Jul 20 '05 #3

P: n/a
"Lasse Reichstein Nielsen" <lr*@hotpop.com> wrote in message
news:of**********@hotpop.com...
There are also IE5.5+ and Netscape 6 specific solutions which allow
attaching multiple event listeners to an element


I don't know what the IE solution is, but I assume the Netscape 6
solution you are referring to, is the addEventListener method.
It is not Netscape 6/Mozilla specific, but actually a W3C Standard
(DOM2 Events), and it also works in Opera 7+. I don't know if Safari
supports it, but I wouldn't be surprised, and if it doesn't, I bet
it will soon.


The IE solution will be the - attachEvent - and - detachEvent - methods
of window, document and DOM elements. Similar to - addEventListener -
except that the function reference argument is executed in the global
context (instead of as a method of the object) and the "on" is required
to prefix the string that identifies the event (and specifying the event
phase is not an option).

Opera 7 also supports - attachEvent - and - detachEvent - and while
recent Opera 7 versions have dropped -addEventListener - from the
global object they have retained - attachEvent - on it.

var svType = (window.addEventListener && 2)||
(window.attachEvent && 1)|| 0;
....
switch(svType){
case 1:
window.attachEvent("onunload", fnRef);
break;
case 2:
window.addEventListener("unload", fnRef, false);
break;
default:
window.onunload = fnRef;
break;
}

Richard.
Jul 20 '05 #4

P: n/a
I must say that I'm a little confused here. Fireworks generates and
integrates both client-side and server-side javscript for the dhtml
menus, and I'm not sure which of the two I should be adding additional
markup to, or specifically what markup I should be adding. And are you
guys saying that it will have to be approached differently for both
Netscape and IE?

- yvan
Jul 20 '05 #5

P: n/a
"Yvan J. Gagnon" <yv**@ideasdesign.com> wrote in message
news:cb**************************@posting.google.c om...
I must say that I'm a little confused here. Fireworks generates
and integrates both client-side and server-side javscript for
the dhtml menus, and I'm not sure which of the two I should be
adding additional markup to, or specifically what markup I should
be adding. And are you guys saying that it will have to be
approached differently for both Netscape and IE?


You would not necessarily have to take a different approach for
different browsers (don't think in terms of "both" there are many
distinct browsers in use these days) as the approach that Martin Honnen
originally outlined will work with most, if not all, current JavaScript
capable browsers. The - addEventListener - and - attachEvent - methods
are only significant if you want to be able to attach more than one
event handling function to an element at the same time (and even then
they are not strictly necessary in order to have multiple event handling
functions, but that is fairly advanced JavaScript).

If you don't know how to implement Martin's suggestion you may have a
problem. No one will be able to tell you whether it would be better
implemented in the HTML output by the server or in the JavaScript
without being able to see and understand both. Unfortunately Macromedia
products tend to output massively bloated HTML and poor and garbled
JavaScript. I for one am not willing to devote any of my spare time to
wading through Macromedia code in order to try to extract meaning from
it. You could post the URL of a working on-line example and see if
anyone was interested in taking a look, you might get lucky.

The situation is that the people who use Macromedia web authoring
products do not tend to have the technical skills to comprehend their
output and the people who have the technical skills do not tend to use
Macromedia products to do what they can do better by hand. If an overlap
exists it is as likely to be represented on a Macromedia newsgroup as
here (though what I have seen of JavaScript on Macromedia newsgroups is
just an endless parade of dubious hacks).

Richard.

--

Example JavaScript DOM listings for: Opera 7.11,
Mozilla 1.2 and ICEbrowser 5.4
<URL: http://www.litotes.demon.co.uk/dom_root.html >
Jul 20 '05 #6

P: n/a
"Yvan J. Gagnon" <yv**@ideasdesign.com> wrote in message
news:cb**************************@posting.google.c om...
<snip>
... No one will be able to tell you whether it would be better
implemented in the HTML output by the server or in the
JavaScript without being able to see and understand both. ... <snip> ... (though what I have seen of JavaScript on Macromedia
newsgroups is just an endless parade of dubious hacks).

<snip>... You'd think that the folks in the Macromedia Fireworks
forums would have something to offer in this respect, but
they've been strangely silent, and non-responsive to my posts. ...
You might not have thought that it doesn't surprise me at all.

<snip>Below is the javascript code that is contained within my HTML
files. If someone here woulf be so kind as to give it a quick
once-over and let me know if this code can be modified to suit
my needs, I would be most grateful.
The reason I proposed posting the URL of an online version is that
isolated chunks of JavaScript without their accompanying context is
often of no value in working out what is going on. This code, for
example, appears to be configuration but without the script that defines
the objects and methods anything said about what is going on is pure
guesswork.

<snip>mm_menu_0624113106_0.addMenuItem(
"Identifying&nbsp;a&nbsp;Debt&nbsp;Problem",
"location='identify.html'");

<snip>

However, that - "location='identify.html'" - parameter looks
suspiciously like it is intended to be a the JavaScript source for an
onclick event handler. Its inclusion, and my assumptions about the
process behind this parameter, make it look like this fireworks menu is
totally failing to exploit the combination of server-side processing and
client side processing in a way that would produce a navigation system
that was not totally dependent on client side JavaScript to be operable,
but half-arse code is what I expect from Macromedia and they haven't
disappointed me yet.

On the other hand, from your point of view this might offer a way in.
Your stated intention is to have the code - doit=false - executed by the
onclick code for each link (presumable prior to navigation) so replacing
= "location='identify.html'" - with -
"doit=false;location='identify.html'" - (and the corresponding change
for each of the other addMenuItem calls) may be all that is needed.

Richard.
Jul 20 '05 #7

This discussion thread is closed

Replies have been disabled for this discussion.