Updating a site to run in mozilla/netscape

young gun trying to learn the ropes

[Aconbere]

never posted up here before but I've been told this is a good place to learn and watch.

I've been working on updating a site, alot of it has been coded IE specific and those of us that use linux, or just don't like IE are unable to access many of the features.

I'm pretty new to JavaScript but have studied a bit of C++ and I have been largly using that as a basis for understanding JavaScript, and in this fashion I've fixed a few of the pages. However I've run up to parts of code that are over my head, in particular a section of code designed to allow someone to engage, drag, and drop a layer.

here are the sections I'm working on. I don't expect exact solutions but hints in the direction to head would be much apreciated.

// Drag an element
/**************************************************************************
DRAGIT
**************************************************************************/
function dragIt(evt)
{
// operate only if a plane is selected
if (selectedObj)
{
if (isNav)
{
shiftTo(selectedObj, (evt.pageX - offsetX), (evt.pageY - offsetY));
}
else
{
shiftTo(selectedObj, (window.event.clientX - offsetX), (window.event.clientY - offsetY));
// prevent further system response to dragging in IE
return false;
}
return true;
}
return false;
}

// Set globals to connect with selected element
/**************************************************************************
ENGAGE
**************************************************************************/
function engage(evt)
{
setSelectedElem(evt);
if (selectedObj)
{
// set globals that remember where the click is in relation to the
// top left corner of the element so we can keep the element-to-cursor
// relationship constant throughout the drag
if (isNav)
{
offsetX = evt.pageX - selectedObj.left;
offsetY = evt.pageY - selectedObj.top;
}
else
{
offsetX = window.event.offsetX;
offsetY = window.event.offsetY;
}
}
// block mouseDown event from forcing Mac to display
// contextual menu.
return false;
}

// Restore elements and globals to initial values
/**************************************************************************
RELEASE
**************************************************************************/
function release(evt)
{
fleetName = window.event.srcElement.parentElement.id;

if (selectedObj)
{
setZIndex(selectedObj, 0);
selectedObj = null;

xp = (document.layers)? loc.pageX : window.event.clientX;
yp = (document.layers)? loc.pageY : window.event.clientY;

// real x, y position calculate
calxy();

for (var i=0; i<=20; i++)
{
fleet_flag = 0;

if (over[i][0].substring(0, 5)!= "fleet")
{
for (var j=0; j<=20; j++)
{
if (over[j][0]!= fleetName)
{
fleet_flag++;
}
else
{
fleet_flag = 2;
}
if (fleet_flag == 1)
{
over[i][0] = fleetName;
over[i][1] = fleetX;
over[i][2] = fleetY;
}
}
}
}

my solutions thus far have been to remove windows.event with [variable].x ... and assume that the variable being passed into the functions are holding events. Document,layers I've fixed by adding a small bit of code in the html headers. Well anyways... any help would be much apreciated.

Thanks

Anders

[Bernard Marx]

IMHO, JavaScript is easy.
...it's the DHTML that hard!

Writing a fully cross-browser drag 'n' drop script, which takes account of scrolling, isn't something I can face right now.

The script you have isn't just IE-specific, it is an old-style cross-browser script.

Document,layers I've fixed by adding a small bit of code in the html headers.

I don't quite get that.

document.layers

is simply a question: "are you Netscape 4?". You'll have to decide/find out whether you're bothering to support it.

Your script will still need branching (of one kind or another) even if dealing with ver5+ browsers. The event models are different between IE and standards browsers. You are best off using event capture.

[Aconbere]

yeah I know I'm going to need to do a check browser and then split the code, but right now I just want to get a working version in mozilla/FF. The code already works in IE. I figure I can work on getting 2 working version and then figure out how I'm going to branch them out later.

but maybe that's a bad idea [eep]

I really have almost no idea what I'm doing, my strategy thus far has been to find the error flags, and work on fixing them by fiddling enough, or bringing them up to a number of friends of mine that know how to code in JS and might know the answer. Then I tried the Mozillazine forums, and someone there pointed me here. So I'm looking for resources.

I got a couple of the errors on my own earlier and have gotten a few others since. But yeah, the drag and drop code is WAY over my head, but the last little piece that needs to get done to make the whole thing run in Mozilla/FF.

Thanks though! I'll read up on event.capture

Anders

[Bernard Marx]

I won't try to enter into it too far. I don't want to post a load of vague drivel.
Apart from this:

Mozilla (et al) have an Event object 'class', with a prototype that's open to additions. If you assigned an event handler like this:

elementRef.onclick = takeClick
function takeClick(evt)
{
 alert(evt) // Mozilla
 alert(event) // IE
}

Here, an event-type object that has been created by the click is passed into the method, and is referenced by the argument.

In IE things are different. evt would be undefined. Instead, there is the global (window) property, event, which as far as I can see, carries the properties of the most recent event. Thus, a good test for browser event handling can generally be:

if(Event) // is there an Event constructor? No => IE

..and specifically in a function

function eventHandlerFn(evt)
{
if(evt) // has an event object been passed? No => IE
.....

<edited: drivel control>

but maybe that's a bad idea [eep]

Not necessarily. It's not such bad practice to actually assign method calls to functions at the top of the script, based on browser tests. This way, you have two separate functions for each method. Only one gets assigned.

This approach isn't often seen in cut'n'paste scripts, which have all their branching inside the functions, and are thus - very slightly - less efficient.