fixed a bug in the haplotype groups

Fixed a bug that was causing the haplotype data in the pop_hap array to sort incorrectly. Basically there was an extra for loop in there that was causing the pop_hap array to be jumbled an extra X times. We're now up to version 2.3.1.

Aha! Getting google to return svg's instead of img's solved

So thanks to Mike William's post to the Google Maps API Google Group, I can get GPolygon to return svg's instead of img's in Firefox in Linux. Yay!

Basically, you have to set these two parameters, _mSvgEnabled and _mSvgForced to true in order to force Google to return SVG's. Here's the code snippet that made everything better:

function load() {
if (GBrowserIsCompatible()) {
// Initialize
if(document.implementation.hasFeature(
"http://www.w3.org/TR/SVG11/feature#SVG","1.1")){
_mSvgEnabled = true;
_mSvgForced = true;
}

Fixing svg/img bugs

So I got a bug report that said that the site didn't work in Firefox in Linux. Only one wedge was being drawn. Turns out that for some reason the call to GPolygon that usually produces svg's produces 'img' elements instead. This caused a bunch of problems. Now I've fixed it so that I check if img's or svg's are produced, then modify the event handling of those objects. I suspect that this img/svg problem may be at the heart of the app's bad behavior in Internet Explorer and Safari as well. But there are more bugs to take care of there... Just a note: Gmaps in Firefox in Windows and Mac DOES produce svgs.

By producing img's instead of svg's certain features of the site become impractical to implement. The biggest problem is that the img's must be completely redrawn each time there's a change. With svg's I can easily change the style (fill color, stroke width, etc.) of the element without having to redraw the graphic. The drawing of the pies is time consuming, so with img's I've disabled the dynamic updating of the pie wedge colors. Now the user must click the 'ok' button to submit their new color requests.

Note: I'm not sure who's 'fault' it is for not being able to use svg's on Firefox in Linux. The documentation for Firefox states that svg support is now built in to the latest release, so maybe it's Google Map API's fault for returning the wrong img datatypes when it should return svg's. In any case, img's are what's being rendered on the page.

onChange handler for the colorpicker

Knallgrau's color picker has been a really useful library, but it took a bit to figure out syntax for the onchange handler. Each colorbox shares the same colorpicker, so I was having trouble deciphering which of the DOM elements was the calling element, so I set an 'onclick' handler on the 'ok' button then had a big loop through all the possible elements to see which one changed. Besides being ugly, the user doesn't have to click on the 'ok' button to exit the colorpicker, so this implementation fails to register a lot of events.

Turns out I was going about this all the wrong way. Knallgrau has an 'onUpdate' attribute that you can set. Here's the syntax when initializing the colorpicker:

new Control.ColorPicker("inputid", { IMAGE_BASE : "javascripts/colorpicker/img/", "swatch" : "buttonid", "onUpdate" : changeColor });

where 'inputid' is the id of the <input> element, 'buttonid' is the id of the <button> element, and 'changeColor' is the function called when the color is updated.

In the changeColor function, this.field gives you the input element. Example:

function changeColor ()
{
console.log (this.field); //prints <input type="hidden" id="hapcolor1" name="hapcolor1" value="B71919"/>
console.log (this.field.id); //prints "inputid"
}

Updated website, fixed extra whitespace bug, uploaded new version 1.0

Fleshed out the website with a bit more content. Hopefully made the instructions easier to follow.

Fixed the whitespace bug in the input form. Now the program doesn't crash with beginning or trailing whitespace and accepts data delimited both by tabs and/or spaces.

bugs fixed -- comment console.logs out

So I was running into the problem that the program worked fine on my machine but was puking on David's. The problem turned out to be how I was debugging my programs. I've been outputting debugging info to a console log readable in the Firebug program. If you don't have Firebug installed, the console functions are not understandable and the browser barfs. So after commenting out all my console logs, the problem went away.

I also noticed the bug that if you moved a pie and zoomed the map, the pies would not be in the right location. Turns out that I had been updating the population centers twice (once on drag, then again on zoom with the same move state), so was getting erroneous placement info. Once again, turned out to be an easy fix. Just commented out the second population updater in the zoom event handler.