I am experiencing a most peculiar behaviour with
regards to a window.onresize event handler I've placed
onto Internet Explorer:

IF I resize IE (by dragging a border) AND the mouse is
still down when the handler fires (even with a
window.setTimeout interposed) AND I pop up a UI
element within the handler, then AFTER I dismiss the
MsgBox (or popup), IE's window will revert to its
previous size.

C'mon Csaba, you will say, you are just asking for
trouble because the mouse is down and focus is being
stolen from IE (sorta, kinda, maybe?), the mouse
action cannot be completed and IE is clever enough to
realize this and revert itself to its previous setting.
So what's the big deal?

Well, the thing is, that it also happens if there is no
MsgBox, but instead I create another ie (not even
visible) and immediately dismiss the new ie! In other
words, just the brazen act of creating a new ie will
revert the old ie's size. And that is a big deal
because I want to use that new IE to store a local
cookie (by virtue of it reading an empty .htm file -
for details see my 3rd post in the March 4th thread
http://groups.google.com/group/micro...380268eda09de/
titled Setting cookies on InternetExplorer.Application)

Admittedly, I should be able to work around this by
placing an onmouseup handler onto the window object,
but then what is the point of the onresize handler - why
not just check the size each time the mouse moves?
Grouse, grouse, grouse.

Here's the .vbScript which demos the issue. There are
anyways a few interesting things to note about the code,
chiefly having to do with the way the callback works.
This is explained underneath the code.

Comments welcome,
Csaba Gabor from Vienna


'Demo of onResize issue
Set ie = CreateObject("InternetExplorer.Application")
Initialize ie

'vbScript must stick around so ResizeHandler can be called
On Error Resume Next
Do while ie.visible 'When we force a quit, this errors
If ie.document.parentWindow.doneP Then ie.Quit
If Err Then Exit Do 'And is caught by this line
WScript.Sleep 10
Loop
WScript.echo "Done with " & WScript.ScriptFullName

Sub ResizeHandler()
' MsgBox "ResizeHandler MsgBox"
Set tmpie=CreateObject("InternetExplorer.Application")
tmpie.Quit
End Sub

Sub Initialize(ie)
'Basic configuration
ie.Navigate2 "about:blank"
ie.visible = true
ie.document.title = "onResize Testing"
Set window = ie.document.parentWindow

'Escape handling
window.opener = "me"
window.execScript "window.doneP=false"
window.execScript _
"document.onkeypress=function(){ " & _
"if (window.event.keyCode==27) " & _
"window.doneP=true;}"



'Resize handling
window.execScript "window.onResizeCnt=0"
window.execScript "window.myHandler=false"
window.myHandler = GetRef("ResizeHandler")
window.execScript "window.onresize=" & _
"function() { " & _
"window.setTimeout( " & vbcrlf & _
"function(cnt) { " & _
"return function() { " & vbcrlf & _
"if (cnt==window.onResizeCnt) " & _
"window.setTimeout(window.myHandler,0); } }" & _
"(++window.onResizeCnt), 2000); }"
End Sub


How to run the code:
Plunk it into a .vbs file and press enter on it. A new
instance of IE will come up. Drag one of its borders (to
resize it) and keep the mouse down for at least two
seconds. You'll see that IE jumps back to it's previous
size. This does not happen if you let the mouse up
within 2 seconds.

Variation: In the ResizeHandler subroutine, comment
out the last two lines and uncomment the MsgBox.
The same type of behaviour will result (only it will be
more visible). Finally, comment out all the lines of
ResizeHandler to see it work as expected.

Explanation of the Resize handling section at the
bottom of Initialize(). First of all, I wanted
ResizeHandler to fire with a window.setTimeout to
ensure that being in the actual event handler was
not an issue. Secondly, when you resize the window,
there are a boatload of resize events (e.g I counted
14 for a minimal movement). That's just wasteful
making so many subroutine calls (especially in light
of the eventual goal of having IE slurp in an empty file).

Thus, the idea is to have a counter (window.onResizeCnt)
that gets incremented each time the .onresize event
handler gets called. Inside that .onreisze event handler
call, a setTimeout is kicked off to a (local javascript)
function after incrementing the counter and associating
the current value with the setTimeout call (by means
of a closure).

When the setTimeout fires its function, the (old) stored
value of the counter (cnt) is checked against the current
value. If they don't match, then this callback has been
superceded by a more recent one, so this one just goes
away quietly. In the event that this callback is the most
recent one, then it should call the vbscript function
ResizeHandler. Unfortunately, just now I don't recollect
whether or how it's possible to get javascript to call into
vbscript directly, even if you store a GetRef("subroutineName")
of the routine onto the window object. Fortunately,
window.setTimeout knows how to deal with it, so that is
the reason for the innermost window.setTimeout.

On Mar 14, 1:46 pm, Csaba Gabor <dans...@xxxxxx> wrote:
....

> IF I resize IE (by dragging a border) AND the mouse is
> still down when the handler fires (even with a
> window.setTimeout interposed) AND I pop up a UI
> element within the handler, then AFTER I dismiss the
> MsgBox (or popup), IE's window will revert to its
> previous size.

....

>
> Admittedly, I should be able to work around this by
> placing an onmouseup handler onto the window object,
> but then what is the point of the onresize handler - why
> not just check the size each time the mouse moves?
> Grouse, grouse, grouse.

Hmmm, not so fast. Turns out the window object doesn't
have a mouseup event. In short, I cannot, as far as I've
been able to find, use standard scripting to find out
when the mouse is down and up on the title bar/borders
of IE. onresize will be fired as the border is changing, but I
don't know when the border resizing is finished. That
means that if I'm opening up a temporary IE in the middle
of this process (to write a cookie), I'm always liable to
reset size/location on the original IE because of the above
noted behaviour. Polling and window.setTimeouts both
suffer from this same problem.

Thus, I see two approaches. The first is to collect and
write size/position information to a local cookie after each
mouseup event and upon a graceful shutdown.

The second approach is to keep a static "cookie" IE (in
other words, I open it at the beginning of the script and keep
it around so that I don't interrupt the main IE while the mouse
is still down) for the purpose of writing cookies and shut it
down when exiting the script. With this I can write a cookie
upon each onResize (as per the above example). I have
implemented this and it works fine.

However, in a separate thread posted earlier today entitled
Detecting position change in IE6 (window.onmove equivalent)
http://groups.google.com/group/micro...fff90a9b2b2a54
I was not able to find a non polling way to detect ie being
moved. Though I'm actually interested in the values at
IE.top and IE.left, there are "DOM" values at
IE.document.parentWindow.screenTop and
IE.document.parentWindow.screenLeft. In addition to
the approaches tried in the referenced post, window
does not have a .onpropertychange event handler nor
could I figure a way to utilize a dynamic setExpression
incorporating those values to fire a helper function. Thus,
I also note the position upon each mouseup (in addition
to noting it when .onresize fires and at script end).

One final sanity check. Wouldn't it be enough to just note
the positions when the program exits? After all, I'm using
the cookie information on subsequent visits, no? Um, well
yes, that's true. The fact is, I'm really noting the positions
and sizes in case of a crash (especially during the
development phase, such crashes are not infrequent). So,
for the amount of benefit I'm realizing from this, I really
could just note everything at shutdown. Which is what
many programs do as far as settings go (How many times
have you crashed Excel only to find certain settings
reverted when you next opened it up?). In any case, some
interesting aspects on sizing/positioning of IE.

Csaba Gabor from Vienna