RE: Re: [Dynapi-Widgetdev] Browser Window Visible co-ordinate widget for test

[David C. <dle...@ya...>]

Hey Richard,
  I just checked the example 2 and 3 under ie5.5 win98
and got no errors, if you have time could you tell me
what the error message is?  My server has been acting
up lately, so maybe it is to blame.  

"limit the screen size to 800*600, "  Nope, not
limited at all.  I just use that as a start position.
When you start the widget, you can set any size you
want, or not set a size if you are not trying to force
the document size.  In the boxes on the work page (if
you ever get in <g>) you can set the document size to
fool the browsers to show the scrollbars.  I had
problems when trying to force ns4 and getting the
screen coordinates, so this widget was born and I just
added in the other code I was using in a dhtml page I
had done a while back.

  I have been working with Henrik on his code for
layerposit  We now have the persistency feature
working for layers placed against the DynAPI.document
and against parent layers.  The persistency code picks
up on resizes and locked layer movements and then
updates the dependant layers to move to the new
position.  I am creating some additional code for that
widget that ties in scrposit so that you can lock the
positions against the browser window even if you are
using the setdocwidth/height to force the scrollbars
on in ns4.  It will also have the ability to pick up
scrolling in the window and cause the  layers to
reposition (onscroll is not available in ns4, so it is
added by way of position checks in scrposit). 
Scrposit was not designed to create watermarks, but it
does provide that capability when tied to some
positioning code like layerposit.

Another thing about scrposit is that it can
differentiate between the vertical and horizontal
scrollbars and adjusts the returned coordinates
accordingly.  Locking something to the lower right
corner of the screen is difficult unless it picks up
the difference.  Keep in mind that a lot of the
features are for "odd" combinations that kept creeping
in to my dhtml designs regarding scrollbars.  I was
trying to create code that makes all the browsers
behave in a similar manner with respect to the screen
coordinates and scrollbar presence.

I suspect there are still a few bugs in it, but most
of the big ones are fixed.  NS6 is still giving me
fits as it wants to reposition/reset the scrollbars 
again after everything has moved.  I will try to find
time to write all the things I discovered about the
scrollbars and coordinates when I write the usage page
for the widget.  Simple things like the pixel number
to subtract for each of the different browsers (ns6
uses different values for the vertical and horizontal,
ie adds a margin to the bottom of the furthest visible
object and so on).

Timing examples:
  As far as standard animation goes, the only use for
biThread is to get below the 55ms floor.  bi-thread
gets unstable above the minimum floor.  Tri-thread is
too jumpy for my tastes (I accidently overwrote the
test page for tri-thread, but I will re do it and post
it so everyone can compare for themselves.  I still
like your idea of using a factor based on the timing,
but have not gotten it working yet.  Is there any
interest in the add on code for thread that uses the
look-up table to default to worst case minimum
timeslices?  Will get more on the timing when I get
some other things off the deck.  Morten Wang, the
author of the first article on timing, contacted me
and said that he will be releasing a "timing
javascript library" shortly.  There ought to be a lot
of great stuff in there.  He has a routine in that
library that sets the timing in a manner which I was
talking about, defaulting to the worst case, but I got
the sense that it does a lot more.

Off to scramble Henrik's code  umm errr let me
rephrase that <g>

Cheers,
Dave C.  "You Changed What?!?"

__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - Buy the things you want at great prices.
http://auctions.yahoo.com/