Preserved Topic: ZscrollBar2 with mouse wheel support (IE6 only) (Page 1 of 1)

Doc, I?ve been playing with your ZscrollBar2 script and decided to add mouse wheel support (IE6 only). I created separate JS file which should be included and that?s all (no other modifications necessary). You can see an example here: http://www.max.co.yu/ozone/ZscrollBar2/

Now, one question... Why do you use ZscrollerWidth variable for? Adding that value (in moveHandler() function) to the position of ?scrollbkg? layer will make scroller respond to clicks outside scrollbar area and that?s not how other scrollers behave. I think that you should add width of ?scrollbkg? layer to its left position instead (I?ve modified it like this in my example scroller). If you?re adding this value in order to respond to mouse dragging outside scrollbar, then you should modify moveHandler() so that it doesn?t respond to mouse left click outside scrollbar (it should only respond to dragging when mouse goes out from scrollbar area).

Oh, and one small bug... When you move scroller to some position other than top and resize window after that, new scroller position will be wrong (try to click on up or down buttons and you?ll see that it will jump quickly).

Very cool !

Oh, that is so damn cool! I was thinking about that for a while, but got distracted and never really got back to looking at it, but it's a natural progression. (I'm running IE6, as all can tell! Have you all upgraded yet? It seems worth it, although I think I'm going to load Windows 95 on my smallest partition, I wonder what ancient browser that might come with?) The ZscrollerWidth variable was set a bit wide on purpose, I know I always have a tough time clicking right where I want to, especially with these skinny scrollbars, I thought I'd give folks the option of making the "active" area larger if they chose. Your way does make sense though, I made that decision early on and never gave it a second thought since then. Since really looking *hard* at scrollbar behaviour since then, I realize I should eliminate that bit and add a flag so that it knows you're in mid-drag and keeps working till you realease the left mouse button, no matter what your Xpos is.

I still need to do some work with the reSize event, as it stands now, I just got cheap and cheated, running the setup() routine again, minus the init module. Obviously I should also do something with the scroll position too. (Ideally, I'll just let it leave the scroll position where you had it, and just alter the height/width of the elements. Tinker tinker!) Max, this is wonderful, this is the first real application of my silly little Znippets, and yours is the first addition to one of the functions, love it!

In the next iteration of this beast, with the Ztemplate experiment, I've added small "doNothing()" functions that run scripts in my second file, Ztemplate.js. If (when) I want to add new functionality to things like doFirstTime() and doOnResize() or doOnZrefresh() I can just add lines to that file and avoid touching the primary file, which started neat looking and quickly became *ugly*! Thanks Max, you made my day!

Your pal, -doc-

The poster has demanded we remove all his contributions, less he takes legal action.
We have done so.
Now Tyberius Prime expects him to start complaining that we removed his 'free speech' since this message will replace all of his posts, past and future.
Don't follow his example - seek real life help first.

Cool, I made those changes you suggested, eliminating the ZscrollerWidth variable altogether, and then in the moveHandler() function I just added "if (mDown) return false;" right after it processes the Xpos and Ypos, which is all it should do if the mouse is down, don't bother checking anything more! Now I gota go in and muck about with those ZIP files again, otherwise I'll have versions and versions of this thing floating around!

Your pal, -doc-

InI, the collaborative effort was *not* a bad idea, quite the contrary! Your enthusiasm for this stuff is a joy to behold, and the way you dive into these things, you're destined for greatness, I'dm betting. I must admit, I'm a bit skeptical of some collaborative efforts with a certain, rigid direction, we're all too much the individualists to cooperate on things for too long, in my experience the more talented the team, the bigger the difficulties as creative differences get in the way. Not to say that these things *can't* be done, they just require a very strong project leader, who (unfortunately) usually ends up hated, while granted a certain grudging respect. I've alweays felt sorry for Project Managers as a profession, especially the poor suckers who get the job of trying to manage *me*!

Now, cooperation, as opposed to collaboration, that's a different story altogether, and something we all do very well - the more eccentric and individualistic the better we cooperate, go figger, heh. After reading your idea I went and looked into the DynAPI project again, which has passed out of Steinmans hands and turned into a true Open Source project, managed by SourceForge, (see http://sourceforge.net/projects/dynapi/ for more on this.) These guys have actually done what you propose, and have codified the entire realm of DHTML coding, seems like. I still have a problem with that type of coding though, since it does *everything*, its naturally quite bloated. I checked one script, the move "Path animation" for example starts with just one script, that calls several others to build all the functions and possibilities that *anyone* could ever imagine, and in the end ends up calling about 70k of script, just to do one silly thing. It's overkill IMHO. For my part, I'd be happier with the tools I need to build my own, extremely streamlined scripts that do only what is needed for this particular page, keeping the code under 10k if possible. I end up with messier scripts, but the user gets a better experience, a faster loading page that does something cool, just like the DynAPI but faster.

I know that once everyone gets broadband coding like that will become more commonplace, and the programmers of tomorrow will all be working one level up, removed from the actual code and only working with applications and APIs that *generate* code for them. The way things are now, we're like the programmers from back in the old days of programming, when all scripts had to be small (no multi Gbyte drives) and fast (computers were slow.) Super fast personal computers and humungous drives led to bloated, inefficient apps like MSWord, which scarcely fits on a CD anymore (it used to fit on a floppy disk! It's a word processor fer crying out loud, what's so hard about that?!) In years to come we can poke fun at the kids who never actually worked at the lowest level, we can tell them about the "good old days" and earn points by stepping in and coding small, mission critical scripts that do their one thing, and do it fast! This is a time to be enjoyed, and the more we know, the better off we'll be.

Er, have I been rambling? What were we talking about, anyway?

Your pal, -doc-

I like what Doc's got here with the Znippets, and I think it'd be cool if we cooperated on that, made tons of little Znippet include files that people could use, as long as they're all *explained*, which Doc mentioned he's planning on doing. (I refuse to make scripts that people will use without understanding =)

The two potential problems with that are... A) I didn't ask Doc if it's ok with him if we all jump in on his little project here, although he seems to be happy that Max added something to it, I'm not sure how much he wants to keep it to himself, I know *I* would. B) Our coding styles are very different... If I wanted to add something to Znippets, I'd have to be allowed to go through all the old Znippets files and change things around - eliminating eval() statements, for instance! It'd drive me crazy to have to make my code based on something that someone else (Doc) wrote, that set things up in a way that's awkward for me personally to code around.

But, if we could get past those two things, this could be a pretty cool collaborative project, provided it stayed small. I hate it when tons of people get involved in something and it gets too hard to handle it all, and all our coding styles are different and stuff... it'd make things worse in the end. But if it were only a few people, maybe 10 or so, I could have fun with it. (I don't want to restrict it at all, I'm just saying that if it's really big I probably won't get involved.)

The poster has demanded we remove all his contributions, less he takes legal action.
We have done so.
Now Tyberius Prime expects him to start complaining that we removed his 'free speech' since this message will replace all of his posts, past and future.
Don't follow his example - seek real life help first.

Hey, my first personal computer was an Atari too! Mine was the Atari 800xl though, with a whopping 64k of RAM - boy were my Commodore buddies jealous! You really learn to start optimizing when you no longer have enough ram to add even one line of code, if you can't make it smaller, no new code for you! =) (I remember being simply *shocked* the first time that happened! I had to go learn Atari assembly language to make certain functions smaller, working for hours so I could squeeze in one more line of code, crazy.)

Slime, you'd be happy with me I'm thinking! I do have a very few eval() statements, but they only get processed once at the very start when I fill all my DHTML vars with the strings needed to push stuff around. You were right, and my CPU went from using 100% to using more like 16%, amazing! I've been picturing multiple versions of even the most basic of code Znippets, and as long as the advanced ones indicate which other files are required there should be room for everyones different libraries, the point is to have fun, and teach if we can! (And also to have useful Znippets for our own use, 'natch.)

Ah! I just checked, and the one and only use of eval is in this line, in the Zobject.js script...

this.DHTML = (wrapper && Zflag.NS) ? eval(layerstart + wrapper + "." + layerstart + this.ID + layerstyle) : eval(layerstart + this.ID + layerstyle);

2 points and an extra cookie if you can make that one eval go away for me, I'll implement it right away! I'm hoping we can agree on the name space, and after that all the different Znips ought to work together, and if I like your version of one of the scripts better I'll start using it instead of my own. If the name space is different, it'd still be cool to collect 'em all together and use them in Znippet form, I figure the more advanced scripts would get shorter and shorter as we started using our basic scripts for all the ugly boring stuff, that would rock for me.

So! The band is playing, and the wagon is starting to roll, hop on! I doubt we'll get as many as 10 people ever developing basic scripts, do I even know that many people doing really cutting edge development? Eventually I'm picturing people submitting derivative scripts based off of this basic work, which could then be offered to the world (with credits, of course!), but this would be off at some future date, lots of work to be done before that starts happening. We learned this from the GurusNetwork, people don't *want* to be just "users", they want to be gurus too! It's the best motivation to learn how things work IMHO.

As soon as I get a decent enough interface put together, I figured I'd start collecting all of the real "mini" scripts I have together, Javascript "date and time" scripts, PHP "date and time" scripts, etc... I always learned best from stealing teeny-tiny scripts and seeing how they worked, and from then all the rest of it made sense. This "cut & paste" example section would be a side-annex at best I'd think, lots of sites already have this kind of stuff, but how many actually attempt to teach? I'd want to make sure that even the most basic of scripts explain what they're doing, and how.

InI, I know a few people who program that way, it really works with two brains and one keyboard! While the first guy is typing something already clear in his head, the other guy is thinking ahead, and catching bugs along the way. I've found that two programmers working this way can get the work of 4 people done, still with only one keyboard! (You have to be pretty good friends, though, otherwise you end up strangling that annoying son of a bitch! =)

Your pal, -doc-

Hmm? I'm just looking at that line, do I even need those eval() statements, or could I just eliminate them? <checking...> Hrmph, looks like I can't just say something like...

this.DHTML = layerstart + this.ID + layerstyle;

...so how do I append three strings together if not with the eval() statement? Slime, I know you've told me before it seems but I can't think of it right now.

Your pal, -doc-

Well, seems like something I'd like to get involved in... just as long as you're ok with me continually requesting changes to the "base" Znippets? =)

I'll need to start reading the Znippets in order to figure out how to eliminate that eval statement. I'll need a better understanding of what that statement is for and what the variables are that are defined before it, and all.

I'll start soon... but, oh crap! I gotta write a paper for thursday, I have other stuff to do too, I'll get to it.

By the way, is www.znippets.com updated with the most recent znippets?

InI, I didn?t say in that other topic that working in groups is a bad idea. I just pointed out that writing DHTML libraries (especially if they need to be cross browser compatible) is very time consuming process and new libraries (partially finished) should not appear on every day. The other story about collaboration vs. cooperation has been explained above by Doc...

Doc, I?ve modified your code (again, heh ) and removed use of eval() function. Modified files are ?Zprime.js? (I added getZobj() function which returns proper object) and ?Zobject.js? (only thing modified is ?this.DHTML? line). You can get them from the same location ( http://www.max.co.yu/ozone/ZscrollBar2/ ). Oh and one small suggestion. I?ve noticed after I modified moveHandler() that it won?t respond when I click on the right border of the scrollbar (that?s probably because hotstop of mouse cursor is not exactly at the 0,0 point in Windows), so I?ve added additional 1 pixel to the calculation (Zobject[getZnum('scrollbkg')].left+Zobject[getZnum('scrollbkg')].width+1)...

That should be all (for now)...

Reading this is making my head spin! It's almost better than a shot of vodka.

Speaking of which, I just picked up a DHTML/CSS book today as my recent attempts at DHTML scripting are proving trying at best, this book should stop me from needing that bottle of vodka! heh...

Anyway, I just wanted to express my awe and whish you all the best of luck in your cooperative endevours, and don't forget to have fun ok!

Coolness!
Drac.

Slime, I expect to have the "base" Znippets changing and being optimized many times as we go, and while I'm kinda happy with most of them, I'm also OK with changes. I was talking with a firend today about "Open Source" versus other free distributions, and from what I can tell, the source is open for anyone to modify, but the versions need to be approved before becoming "official releases", slippery concept, but I'm down with it, seems cool. What's being used right now is current, and the codes you see in the form windows are inserted using SSI inlcudes, so they should be up-to-date. The ZIP files still have older code in them, I need to give some thought on how best to let people download them, ZIPping and re-zipping could turn into a major pain in the ass, seems to me.

BTW, the "this.DHTML" line is used like this, once it's built with the "doucment.all.blah.browser.specific" bit, all you need to do is add the last part like "top" or "left", so in order to alter the top position of a layer you'd send something like

Zobject[0].DHTML.top = 200;

And that would push the layer to that spot. Sometimes I don't want to be pushing it there right away, so I can also just set the top value like Zobject[0].top = 200; the number would get changed in the array, bt it would wait until I ran an update of the position of all Zobjects.

Max! I love this, this is turning into so much fun! I'll grab your newest code and add it to the library. We have people coming over in a half hour, so the ZIP files won't be updated until later this evening.

Your pal, -doc-

Isn't there some way to zip up files server side so that the zipped files are always the up-to-date ones? Its something I've never had to look into but I've always thought there must be a way to make sure that the versions are all the same.

mr.Max?

Emps

Cool.

I suggest we create both a ZSimpleObject.js and a ZComplexObject.js (with createZSimpleObj and createZComplexObj functions, respectively). This way, one could use ZSimpleObject to do mainly what ZObject does now - just access the important style properties of an HTML element in a cross-browser compatible way. ZComplexObject.js would include that, plus a lot of other cool things that one might want to do to an object, such as automatically restricting its position, automatic drag and drop with an onRelease event (which people could set with myZObject.onRelease = myOnReleaseFunction , cool stuff like that. So people can avoid the more bloated complex object class if they want to either do only simple things or if they want to code the complex stuff themselves, or the can use the more complex object class if they just want some sort of cool effect without having to worry about coding it so much.

By the way, I notice that ZObject.DHTML references the style sheet of the object, but there is also an advantage to have a reference to the object itself, perhaps we should create an object for that? Then ZObject.DHTML would merely be that object's "style" property.



[edit: disabled slimies, poor things.]

[This message has been edited by Slime (edited 09-19-2001).]

Hah time for doc to set up a CVS server for this.

I agree with Slime. however what I'd do is simply seperate out the object creation from the method functions allowing developers to add the methods they need as they see fit.

As well as having a complete package which can be downloaded and used by those not as technically minded for easy use.





:[ Computers let you make more mistakes faster than any other invention in human history, with the possible exceptions of handguns and tequila. ]:

Oh, yeah, good idea.. we can just have separate JS files that add methods on to the prototype of the ZObject's. Neat... I guess that's what makes it so easy to do with multiple people in this case.

BTW, if we ever have Znippets calling other Znippets, we'll have to make some sort of thing similar to C++'s #ifdef stuff... like, we'd have one object, called ZnippetsCalled, and it would have multiple properties, like ZnippetsCalled.ZObject and ZnippetsCalled.ZScrollBar, and we'd only call the outside files if those properties aren't yet defined. Then again, I doubt we'll actually have Znippets calling other Znippets, so, eh.

The poster has demanded we remove all his contributions, less he takes legal action.
We have done so.
Now Tyberius Prime expects him to start complaining that we removed his 'free speech' since this message will replace all of his posts, past and future.
Don't follow his example - seek real life help first.

Arg, this is going to be problematic. I want to edit ZPrime.js now, but I'll have to edit max's version, and we have to be careful to keep track of which is the most updated one.

Edit: my main suggestion right now is that the "wrapper" argument should not be a string, it should instead be a reference to an object. So, max's getZobj function would contain this:

if (Zflag.NS) {
return wrapper ? wrapper.document.layers[name] : document.layers[name];
}

instead of this:

if (Zflag.NS) {
return wrapper ? document.layers[wrapper].document.layers[name] : document.layers[name];
}

And when the function was called, it would be called like this:

myidsDHTML = getZobj("myid", getZobj("myWrapper"))

The advantage is that you can do layers nested within layers without any trouble:

myidsDHTML = getZobj("myid", getZobj("myIDsWrapper", getZobj("parentOfThatOne", getZobj("highestLevelParent"))))

Also, I suggest that we rename the .DHTML property to something more descriptive of it, "DHTML" stands for "Dynamic HTML" and is too vaque in my opinion... I suggest "styleInfo" or something similar.

[This message has been edited by Slime (edited 09-19-2001).]

OK, although I think "styleInfo" doesn't really say it to me either, what might be in there, bgcolors, padding? I don't have any great ideas right now, just know that that one doesn't help me understand what it is. BTW, I just uploaded the most recent ZIPs of the Zscripts as far as I have them. I made a point of dating the front page with the precise time and date, using GMT, something we can all get from our servers. That reminds me, I'll also add a tag on that page to display the date in GMT for those of you who have trouble with base 24, heh heh. I was just trying, and I couldn't get throguh to Max's site, DNS problems, I'm thinking, as I also couldn't get through to this site either! So! The scripts on the Znippets site were updated 22 minutes ago, and if you could mail me the completed hacks as they're done, I'll reconcile them with whatever other versions I get and post the combined scripts in their place, would that be OK?

(Hmm, just thought, I can get the last modified date from the files using SSI also, better do that and make it automatic!) Version tracking is going to be our biggest nightmare, I'm thinking, perhaps we should also start a changes.txt document which could be added to the ZIP file each time?

Your pal, -doc-

OK, and BTW. I just got through to the max.co.yu site, so of course, those files updated moments ago are already getting stale! I'll want to add the Zmousewheel file, and reconcile our changes, some I made at maX's suggestion which I'm sure he already made in his, this could be problems until we get past the basic scripts and on into making applications from them! (Version tracking, scary scary stuff... =)

Your pal, -doc-

OK, the first changes I plan to make will be with the ZgetObj function that i mentioned, and one other thing...

I realized that if people wanted to use multiple Znippets that required onload events, it could cause problems. So I'm going to add a function that *concatenates* a function onto the onLoad event, and i'll also create a global variable which keeps track of whether or not the page has loaded. I'm not sure if I'll put this all in a separate JS file, I probably will... and call it ZonLoadLib or something.

The scrolling script may have to be modified, I suggest that we make sure these more basic Znippets are completed before we move on to heavier stuff like the scrolling script. We need to make sure that if we want to add anything in the future, we can at least keep it backwards compatable.

I keep typing much more than I intend to. =)

OK, one more note. I found it easier to just go by the server time, which is "PDT", something to do with the Pacific ocean, perhaps? Sounds like California. You can see the current time listed on the front page, at the bottom, and each of the ZIP files has it's last updated time next to it, at least you can grab something that's not too old, hopefully! I'll have to write out a nice happy "README.txt" file, so we can list what's happened with the included scripts and track changes, provide credits and links, etc... I figure each Znippet should have a *short* copyright/credit included in the text, otherwise our bandwidth willl go sky-high from all of the comments, heh. Perhaps we should have profiles collected under the Znippet site, with listings of which files have been worked on, etc...?

Your pal, -doc-

Yeah, I had a thought on this aspect. I already ran into this right off the bat, when I did the first actual implementation of the Zscrollbar script. I needed to add things to the onLoad setup() function, and also to the updating() loop, as well as onResize. What I did was make one more page I called "Ztemplate" (though I also imagined it as "Zcontrol") and in this page I had empty funtions that I refered from my main script. If I wanted to add some things to the onLoad setup(), I added it here, and made sure I called it from there. BTW, I've been using the variable "loaded" to set whether things have loaded or not, made sense to say something like...

if(!loaded) return false;

to stop a function from firing too early, or...

if (loaded) { do some stuff...; }

Your pal, -doc-

This is what I was thinking of for all the onLoad stuff:

var Zloaded = false;

var ZanonFuncs = new Array();

function ZaddFunctionToEvent(theObject, theEventName, theFunction)
{

// store what's *currently* in the event we're about to overwrite
var anonFuncNum = ZanonFuncs.length;
ZanonFuncs[anonFuncNum] = theObject[theEventName];
ZanonFuncs[anonFuncNum+1] = theFunction;

// write the new event:
theObject[theEventName] = new Function("e", "ZanonFuncs[" + anonFuncNum+ "](e); ZanonFuncs[" + (anonFuncNum+1) + "](e);");
}

window.onload = new Function("Zloaded = true;");

Note that the function can also be used by the user to concatenate their own onMouseDown event onto an object that a Znippet may already be using the onMouseDown event with. All event functions will be passed an argument "e" that contains the event object for Netscape.

EXAMPLE OF USE

function setup() {...}
function anotherSetup() {...}

ZaddFunctionToEvent(window, "onload", setup);
ZaddFunctionToEvent(window, "onload", anotherSetup);

There may be a bug or two to work out in the code, and it's going to be pretty hard to explain to novices how it works, but it's the best way *I* can think of to handle the event stuff.

[This message has been edited by Slime (edited 09-20-2001).]

Whoa, that does look like a cool solution, and I agree it'll be damned hard to explain to anyone new to programming! I'd image that as long as we provide an example though, people will be able to figure it out. I know I already mentioned to InI that I want to avoid short, cryptic function and variable names, but I also don't want to go *too* far overboard in making long names either! (think of the bandwidth! Bandwidth, I said!) Maybe ZaddToEvent() would be enough for most folks, eh? This'll be cool. All most people would need to add to their own files is something like...

ZaddToEvent(window, "onload", mySetupStuff);
function mySetupStuff() {...}


Your pal, -doc-

The only problem I see is that the function may cause weird problems if the event hasn't been defined before you start calling the function for it, but that's not a huge problem to fix.

This makes the Zobject.element property that I suggested earlier seem necessary - it would reference the actual HTML element (instead of just Zobject.DHTML which references the style properties of that element) so that we can do things with the object such as passing it to this function.

I'm bored. I'm going to get to work on this.

There's a bug in Zobject.js... if you don't specify the zindex, it tries to access the Zobject array, which, as far as I can tell, has never been defined.

And shouldn't the arguments be in the order left,top,width,height? Why are you putting top and height first? I guess that's a matter of preference, but I always assume it's left first, like (x,y) coordinates. =)

[This message has been edited by Slime (edited 09-20-2001).]

OK, for my third reply in a row...

I'm changing Zobject.js around a little. I'll post all the new files before I go to bed, they're mainly the same, I'm keeping a changes.txt file to record what I change.

Zevents.js is being coded differently than I thought it would be, but it's working! yay! (Even in NN! Double yay!)

And one question: Does the style information always need to be specified (like, in style tags)? I think it does, just for NN, that evil browser. Oh well.

Hopefully my next reply will state where I've uploaded the new scripts.

OK! Doc, look at http://www.rpi.edu/~haggej/changes.txt - I gotta get to bed now! =)

(Remember Doc, this is really your project, so anything i changed that you don't want changed, change it back!)

[Edit: very sorry, the links are incorrect because rpi.edu changed all the capital Zs to lowercase ones, and won't let me change them back. Download the four files mentioned in changes.txt to, like, your desktop or something, and make the Zs capital, and then everything (including the one HTML file that's an example of Zevents.js) will work.]

[This message has been edited by Slime (edited 09-20-2001).]

OK, OK, this is the fifth post in a row by me, and it's merely to bump it up to the top of the list. Sorry! I just wanted to make sure that Doc noticed this so that my work that night doesn't go to waste.

I just wanted to post so Slime wouldn't be alone


j/k

I think when creating objects you should not have to include the height and width in the arguments. This is something that can be determined via the browser.

.02 now included.



:[ Computers let you make more mistakes faster than any other invention in human history, with the possible exceptions of handguns and tequila. ]: