Javascript - "function not defined"

K

Kevin

I ran my showReport() function, which merely makes a table using HTML,
not as a function, i.e. I ran the code when my webpage loads. My
selectTab() function, which shows different views based on a button
press, works.

When my webpage opens, it runs the showReport() function javascript,
but not as a function. Next, I added the function, showReport(), that
first deletes the entire table, then re-draws a table. Up to this
point, showReport() works. However, when I press a button to change
the views, the "selectTab() is not defined" shows up again!

I don't understand!
 
G

Garrett Smith

Stefan said:
On 16/04/10 00:29, Kevin wrote:
[...]




PS, [1]: There is/was a browser in which text nodes could be targets for
click events, instead of their container elements, but I forget which
one it was. Maybe Safari 2 or 3. In the interest of backward
compatibility, the "evt.target || evt.srcElement" part may need a
wrapper to avoid this case.

Mouse event on text node is seen in Safari 2. Older mozilla, as well.
Maybe FF 1.
 
T

Thomas 'PointedEars' Lahn

Kevin said:
I ran my showReport() function, which merely makes a table using HTML,
not as a function, i.e. I ran the code when my webpage loads.

Perhaps you mean "has loaded". You have been told repeatedly that
document.write() is the wrong tool then.
My selectTab() function, which shows different views based on a button
press, works.
OK

When my webpage opens,

There are no "webpages", and they don't open. (X)HTML documents are being
loaded (parsed and rendered) in a view.
it runs the showReport() function javascript, but not as a function.

That's nonsense. Perhaps you mean something ridiculous like

window.onload = showReport;

If yes, RTFM. This is an assignment to an event-handler attribute. The
function thus being assigned (in simple terms) is supposed to be called
(as a function, of course) when the document *has been* loaded. And I have
told you before that you should use

<body onload="showReport()">

instead.
Next, I added the function, showReport(),

What does that mean, "added the function"? Your function is already
*there*!
that first deletes the entire table, then re-draws a table. Up to this
point, showReport() works. However, when I press a button to change
the views, the "selectTab() is not defined" shows up again!

I don't understand!

(That is not a question!)

You have been told before. Learn to read! When you call document.write()
after the document has been loaded, chances are good that you overwrite the
document along with all script code in it. So there is no selectTab()
function anymore then. Got it?


PointedEars
 
T

Thomas 'PointedEars' Lahn

Thomas said:
That's nonsense. Perhaps you mean something ridiculous like

window.onload = showReport;

If yes, RTFM. This is an assignment to an event-handler attribute.
^^^^^^^^^
_Property_, not attribute.
[...] And I have told you before that you should use

<body onload="showReport()"> ^^^^^^^^^^^^^^^^^^^^^
instead.

Now *this* is an event-handler _attribute_.

Sorry for any further confusion this may have caused.


PointedEars
 
G

Garrett Smith

Stefan said:
Stefan said:
PS, [1]: There is/was a browser in which text nodes could be targets for
click events, instead of their container elements, but I forget which
one it was. Maybe Safari 2 or 3. In the interest of backward
compatibility, the "evt.target || evt.srcElement" part may need a
wrapper to avoid this case.
Mouse event on text node is seen in Safari 2. Older mozilla, as well.
Maybe FF 1.

Thanks. I guess I was looking for an excuse to ditch that code, but it
looks like I'll have to keep it for a while yet.

Just for the record, the following code has been posted in this thread:

var t = evt.target || evt.srcElement;
if (t && t.nodeName != "#text")
{
// ...
}

What I use is similar, except that for browsers which accept text nodes
as event targets, the parent element is returned instead:

function getElement (node) {
if (node && node.nodeType == DOM_TEXT) { // DOM_TEXT is 3
node = node.parentNode;
}
return node;
}

function getTarget (evt) {
return getElement(evt.target || evt.srcElement);
}

function getRelated (evt) {
var node = evt.relatedTarget;
if (!node) {
// snip MSIE mouseover/mouseout adjustments
}
return getElement(node);
}

One problem with this is Mozilla chrome tooltips. These guys can get the
mouse event but can result in errors and also, you usually do not want
to trigger a mouseout when the cursor goes from element to its tooltip.

I have seen two problems where chrome tooltip cause mouseout to fire:
1) relatedTarget is null
2) relatedTarget.nodeName throws a security error (code 9).

The way I have dealt with this is

1) if relatedTarget is null, use target.
2) use try/catch.

I don't like it because it adds clutter to the code, but it avoided the
error.

Using `target` when relatedTarget is null is that may, in the case of an
iframe, provide an undesirable result. I will try to set up an example
to demonstrate this problem.

Documentation of relatedTarget on MDC mentions this problem:
<https://developer.mozilla.org/en/DOM/event.relatedTarget>

[...]
I haven't had any problems with this approach, but if you can find any,
I'll buy you a Kipferl next time you visit Vienna ;-)

OK, but if you want to contribute on my project, I'm just an email away.

I've fixed errors and cleaned up interfaces and am always looking for
ways to improve it. The unit tests provide pretty good coverage for
refactoring.

The documentation is way out of date and needs to be removed, but the
code is pretty self-documenting with interfaces where you can, say:

console.dir(APE);

- and have a good idea of what is available. The complexity is greater
further down. APE, APE.dom, APE.EventPublisher, APE.dom.Event should be
easy to understand by just looking at the interface.
 
V

VK

Usenet isn't a helpdesk.

Yet the answer has to be provided somewhere on the first place - then
a "round-the-topic" - but not an off-topic - discussion may be
continued.

OP posted syntactically correct code for selectTab function asking why
"selectTab function is not defined" error on clicking an interface
element. There is nothing useful posted here to suggest to look for
*previous* errors and not the last one.
I highly doubt that. A syntax error can usually be identified easily
enough, and it wouldn't result in a "function not defined" error message
(or at least not in this case).

When in doubt it is a good habit to try the provided test case and
compare with the claimed results. Simply skipping on any testing and
simply declaring one's doubts is a mute point of discussion. In the
posted test case to demonstrate the difference between the onload
parsing of <script> blocks vs. lazy parsing of intrinsic event
handlers (posting one more time):

<!DOCTYPE html>
<html>
<head>
<title>Untitled Document</title>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
<script>

function foo() {}

function selectTab(x) { // not closed

// this code is obviously wrong so cannot be parsed
// so neither foo nor selectTab not the whole
// <script> block will exist
</script>
</head>

<body bgcolor="#FFFFFF">
<p onclick="selectTab()">test</p>
<!-- Yet onclick will be first parsed
on the first click only and be OK,
it will try to find selectTab function,
obviously fail on it and give you the relevant error
-->
</body>
</html>

On page load it gives the syntax error "missing } after function
body". Yet every time clicking on "test" gives runtime error
"selectTab is not defined". Please, don't doubt, simply check it.

Confirming one more time that.
No. Don't send Kevin off looking for a syntax error when you don't have
any reasonable indication that there is one.

The resonable indication is to look for syntax errors in the error
console *before* "selectTab is not defined" errors. As no code other
than the selectTab itself was posted obviously nor me nor anyone else
can be more specific at this time.
 
G

Garrett Smith

Stefan said:
Looks like I owe you a Kipferl!

I've never had one of those.
I've never encountered any errors with Mozilla tooltips; probably
because the combination relatedTarget+tooltip never came up.
event.relatedTarget is indeed null when the mouse enters a tooltip. I'm
not sure if that's really a problem, it just means that our script can't
always tell where the mouse cursor went (or came from).

Right.

The pointer is either over the tooltip or outside the window. If the
pointer is over the tooltip, it's as good as being over the element, as
far as the program should be concerned.

However, if the pointer is *outside the window*, then it is not over the
element and the program should probably want to know about that.

I don't know a simple way to discriminate between these two, but
getRelatedTarget should be able to do that.

[...]
Why do you want the target returned instead of the relatedTarget?

If it is outside the window, I don't.

I'm going to reassess that piece of code and the code that the
workaround was introduced for.

One possibility is to return null when relatedTarget is null.

The downside to doing that is that the caller won't know where the
pointer is. Is it on the element's toolip? Outside the window?

Another downside to returning null is that the caller must perform a
null check before passing that value to other methods. This is not so
much of a problem, and it makes sense when the `event.relatedTarget`
really outside the document's window (and not on a "tooltip" window).

I see the jQuery code you posted catches the problem in "withinElement"
function.

They add, at the bottom of that function:
| // assuming we've left the element since we most likely mousedover a
| // xul element
| } catch(e) { }

- This assumption seems wrong. If the pointer was over an XUL element,
it was probably over the element's tooltip, and by implication, "within"
the element.

Other Gecko relatedTarget bugs not related to this problem:

Bug 225462 - Exception thrown trying to get text input mouseover event
relatedTarget properties
<https://bugzilla.mozilla.org/show_bug.cgi?id=225462>

Bug 382735 - mouseOver & mouseUp from/to option elements within select
generate spurious events with bad relatedTargets
I know your APE library, although I have to admit that it's been over a
year since I last looked at it, and I have used parts of APE as an
inspiration for the code I'm using here. I'm currently working on other
(non-JS-related) projects, but if things are going as planned, I will
be doing an overhaul of the agglommeration of random code I sometimes
call a library, probably in late summer or autumn. When I'm in "library
mode" again, I'll be glad to contribute if I can.
Over the past year, it has had a major refactoring, a lot of bug fixes,
and new widgets (Autocomplete and Calendar). The outdated documentation
has been taken down.
 
K

Kevin

Thanks for everyone's help.

I tried a new design and it works. I have two frames. The left frame
is merely a list with "onclick" event handlers that point to a new
HTML. The right-side is the populated HTML.

For example, you might see Project 1, Project 2, ... , Project 5 on
the left-hand side. When you click a project, you'll see the project's
table with 3 buttons that let you change your view.
 
S

Scott Sauyet

I tried a new design and it works. I have two frames. The left frame
is merely a list with "onclick" event handlers that point to a new
HTML. The right-side is the populated HTML.

For example, you might see Project 1, Project 2, ... , Project 5 on
the left-hand side. When you click a project, you'll see the project's
table with 3 buttons that let you change your view.

I'm glad you got something that works for you. Out of curiosity,
though, are there separate URLs for each HTML? If so, then you
probably don't even need onclick handler, just a "target" attribute on
the link.

-- Scott
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,774
Messages
2,569,600
Members
45,180
Latest member
CryptoTax Software
Top