Posts in the JavaScript Category

Here’s a late-week call for assistance in the JavaScript realm, specifically in making IE do what I need and can make happen in other browsers.  I’d call this a LazyWeb request except I’ve been trying to figure out how to do it all [censored] afternoon, and it doesn’t [censored] work no matter how many [censored] semi-related examples I find online that work just [censored] fine, but still don’t [censored] help me [censored] fix this [censored] problem.  [doubly censored]!

I have a table.  (Yes, for data.)  In the table are rows, of course, and each row has a number of cells.  I want to walk through the rows and dynamically add an ‘onclick’ event to every row.  The actual event is slightly different for each row, but in every case, it’s supposed to call a function and pass some parameters (which are the things that change).  Here’s how I’m doing it:

var event = '5'; // in the real code this is passed into the surrounding function
var mapStates = getElementsByClassName('map','tr');
for (x = 0; x < mapStates.length; x++) {
	var el = mapStates[x];
	var id = el.getAttribute('id');
	var val = "goto('" + id + "','" + event + "');";
	el.setAttribute('onclick',val);
}

Okay, so that works fine in Gecko.  It doesn't work at all in IE.  I changed el.setAttribute('onclick',val); to el.onclick = val; per some advice I found online and that completely failed in everything.  Firebug told me "el.onclick is not a function".  Explorer just silently did nothing, like always.

So how am I supposed to make this work in IE, let alone in IE and Gecko-based and WebKit-based and all other modern browsers?

Oh, and do not tell me that framework X or library Q does this so easily, because I'm trying to learn here, not have someone else's code hand-wave the problem away.  Pointing me directly to the actual code block inside a framework or library that makes this sort of thing possible:  that's totally fine.  I may not understand it, but at least there will be JS for me to study and ask questions about.  Ditto for pointing me to online examples of doing the exact same thing, which I tried to find in Google but could not: much appreciated.

Help, please?

Update: many, many commenters helped me see what I was missing and therefore doing wrong---thank you all!  For those wondering what I was wondering, check out the comments.  There are a lot of good examples and quick explanations there.

• Need Help With Table Row Events was published on Thursday, May 29th, 2008.
• It was assigned to the Browsers and JavaScript categories.
• There have been forty-five replies.

Okay, JavaScript / DOM scripting gurus, I need your help.  Explorer for Windows is completely baffling me and hopefully one of you out there can determine what’s making it act so peculiar.  To see the problems, go to the debug version of HYDEsim in IE/Win and compare the the results to those in Firefox.

Problem #1 is that the rounding function I wrote doesn’t seem to be working right (though this could be an effect of VirtualPC).  Here’s the function:

function round(x,dp) {
	var rt = Math.pow(10,dp);
	return Math.round(x*rt) / rt;
}

That’s it.  All it’s supposed to do is round off a number to the given number of decimal points.  Thus, var test = round(3.1415926539,3) should return 3.142.  In IE/Win, instead of the expected 0.71, I’m getting results like 0.7100000000000001.  Huh?  Where the heck did that come from?  Is this fallout from that Intel rounding bug everyone was smirking about five years ago, or what?

Problem #2 is perhaps more obvious: the Great Big Circles on the map.  I’m creating the GIcon objects correctly, passing in the height and width of each one.  The top left corner placement is correct for each marker.  They just haven’t been resized in any way at all, and so are being drawn at their inherent 1000-by-1000 size.  Is this a breakdown in IE/Win, the Google Maps API, or something else?  I tried passing pre-rounded values and it didn’t seem to help.  Am I stuck here, or is there a solution?

Many thanks for any help you can provide.

• Help Wanted: IE/Win Script Weirdness was published on Monday, July 25th, 2005.
• It was assigned to the JavaScript category.
• There have been ten replies.

As I worked on HYDEsim, I discovered some interesting things about the Google Maps API.  Well, let’s call them what they are: limitations.

(And let me say right up front that if I missed ways to get around these limitations, then I’ll happily be corrected.  Either way, these are the impressions of someone whose first project in the API took about two days, and was in the end basically a success, which speaks volumes to the quality of the API.)

The first and most important limitation was that the Google Maps API permits the creation of two types of objects.  The first type is icons, the most obvious example of which are those little push-pin symbols in Google Maps that mark locations.  The second is polylines, which are how Google Maps draws the “get from here to there” routes on the maps.  You get both any time you ask for driving directions, like these from Norwalk, CT to New York City, NY.

Note that they’re polylines, not polygons.  You could certainly draw a polygonal shape using a polyline, but you couldn’t easily fill it with a color, let alone a translucent color.  And as for a circle… well, if you want to draw enough line segments so that you approximate the roundness of a circle, you certainly can.  It just doesn’t seem like a great idea.  Plus there’s no simple way to fill it in.

So in order to draw the overpressure rings, I created a 1000×1000 pixel 24-bit PNG of a circle.  To create a ring, I first used the Google Maps API to figure out the latitude and longitude boundaries of the map.  From that, I determined the number of miles per degree based on the latitude, and then calculated the number of miles per pixel (mpp) within the view.  From there, I determined how wide a ring needed to be to be the right size, created an icon at that size using the big PNG, and added it as an icon.

Whew.

Okay, so that solved the problem of putting the rings on the map.  What it didn’t solve was what happened if the zoom level changed, because icons (being raster images) don’t zoom with the map.  By default, you wouldn’t want them to: if the pushpin kept growing with the map as you zoomed in, eventually it would get huge and blocky and obscure half the view.

Therefore, the upshot was that every time the zoom level changed, I had to rip away the rings and rebuild them entirely, based on the new mpp value.  It was easy to trigger the process:

GEvent.addListener(map, "zoom", zoomLimit);

That’s the API at work for me.  I just tack a listener onto the zoom event, and I’m ready to go.  Cool.  Rebuilding the icons—well, not so cool, although it doesn’t seem to kill the tool’s performance.

All this zoom handling was necessary because icons, as you might expect, are given dimensions in pixels.  Polylines, on the other hand, have each point defined with longitude/latitude coordinates.  That’s why polylines do scale with change in zoom level—as, again, you’d want them to do by default.  If I could have defined my icons’ sizes using longitude/latitude measures instead of pixels, I could have avoided the whole “recalculate the ring sizes every time the zoom level changes” bit and shaved two or three hours off of my development time.  (Which was, in total, 12 hours or less.)

Of course, if the API provided polygonal primitives, I’d have avoided even more hackery.  If I could have just drawn the circles as circles, using longitudinal degrees as the unit of sizing, then there’d have been even less work and a shorter development time.  Something like this:

var base = new GShape();
base.type = circle;
base.anchor = new GPoint(-73.9971, 40.7223);  // longitude,latitude
base.radius = 0.0273548;  // degrees of latitude

…or something to that effect, with properties for the color and thickness of the outline, and also for the color and transparency of the interior.  And so on.

By doing it this way, the shapes (and there could easily be many other types) would be like filled polylines, and would scale in size along with the map.  That would have made HYDESim a whole lot easier to create.

You might say, “That’s all well and good, Eric, but how many reasons are there to draw circles on a map besides charting widespread destruction?”  I thought of a few possibilities:

• Explicitly showing the scope of a “show me hotels within this many miles of the specified address” type of request
• Someone looking to recreate the WIMPUR map in Google Maps
• Plotting Iridium flare intensities

I’m sure there are countless more.  As well, allowing for actual filled polygons would add extra possibilities to applications like chicagocrime.org, which uses polylines to draw ZIP code boundaries.  With filled polygons, they could shade the ZIP code in question… or shade all other ZIP codes while leaving the current one unshaded, in order to give it some extra visual pop.

There was one other thing I encountered that’s either a limitation, or I just couldn’t figure out how to deal with it.  If you click on a detonation point in HYDESim, it pops up a “blowup” window (their term, not mine!) that shows a zoomed-in view of that point on the map.  The overpressure ring overlays are faithfully reproduced on that map, but they aren’t scaled to its zoom level.  They exactly match the overlays on the main map, and zooming in and out in that window has no scaling effects.

Ideally, I’d just remove the overlays from the zoom window while leaving them in place on the larger map.  I couldn’t find a way to do it.  Failing that, I wanted to have the overlays correctly scaled.  No dice there either.  If there is a way to do either of these and I missed it, hopefully someone will let me know.  If not, it’s something I hope the API adds in the future.

The final observation has to do with the icons and interactivity.  I wanted to set the overpressure rings to be event-transparent.  In other words, I wanted to make it so that the rings didn’t exist as far as the event model was concerned.  That way, you could click-and-drag the map even if there’s a ring underneath the mouse pointer.  This didn’t appear to be possible, although again, maybe I just couldn’t figure out how.  I did play around with the imageMap property, but it didn’t seem to have much effect.  Figuring that out would be nice, though.  I could leave the detonation point active for popping open the blowup window, and make the rest inert.

Other than that, things went as smoothly as you might expect they would for someone with limited JavaScript skills and no prior experience with the Google Maps API.  The examples provided by Google on the documentation page helped immensely, actually, especially the AJAX example.  That let me split the city list into a separate file, thus making it much easier to maintain, and get my first hands-on experience with AJAX programming.  (I’ve seen AJAX applications before—as long as three years ago, actually—but never written any code along those lines.)

Oh, and one more thing—the fact that the Google Maps API key only works for a specific directory, and not any of its subdirectories, drove me up the wall.  Instead of generating a key for meyerweb.com that would cover anything I might do on the site, I’ll have to generate a new key for every new directory.  This is why I set up the directory /eric/tools/gmap/, but that just seems so… confining.  Similarly, it was annoying that the key was completely bound to the full address.  I generated the key for meyerweb.com/eric/tools/gmap/, so if anyone types in www.meyerweb.com/eric/tools/gmap/ they’ll get a key error.  It would be nice if at some future time the keys were a little more flexible than they are now.

• Working With Google Maps was published on Friday, July 15th, 2005.
• It was assigned to the JavaScript and Tools categories.
• There have been seventeen replies.

In pursuit of better JavaScript skills, I’ve encountered a Safari problem that may be a limitation in the browser, or it may be my coding.  I have a temporary test file demonstrating what’s happening.  In Firefox, everything works as I’d hoped it would, but in Safari, all I get is an error on the JavaScript console stating:

SyntaxError – Parse error

Here’s the function in which the error occurs, with the offending line emphasized:

function Test(a,b) {
	this.a = a;
	this.b = b;
	this.c = new (function Inner() {
		this.x = 'woo';
	});
}

As I say, here’s the temporary test file in case you want to see the entire script.

My long experience with CSS and browser handling  of it teaches me that just because something works in one browser, that doesn’t mean it’s supposed to work at all.  Therefore, it could be that Firefox is letting me be sloppy, and Safari is telling me I’ve messed up; or it could be that Firefox is right, and Safari has a problem.

So which is it?  If it’s the former, how can I do the same thing I’m trying to do, except correctly?  If it’s the latter, are there any simple workarounds to get Safari to behave?

Thanks for any help.

Update: Lachlan Hunt rides in to the rescue by pointing out what probably should have been painfully obvious, but like I say, I’m new to this.  The solution here:

function Test(a,b) {
	this.a = a;
	this.b = b;
	this.c = new function() {
		this.x = 'woo';
	};
}

I’m still not 100% certain if this was a case of sloppy authoring or a bad browser, but I’m not so concerned with that right now.  I’ll leave up the post in case anyone else encounters a similar problem.

Update redux: Adrian (and, though I didn’t understand what he was saying at the time, Tim) points out a simpler way to do the same thing.

• Safari SyntaxError was published on Monday, July 11th, 2005.
• It was assigned to the JavaScript category.
• There have been sixteen replies.