![]() |
![]() | ![]() | ![]() | ![]() | ![]() | ![]() | ![]() |
| Welcome to Windows Vista Forums. Our forum is dedicated to helping you find solutions with any problems, errors or issues you are experiencing with Windows Vista. The Vista forum also covers news and updates and has an extensive Windows Vista tutorial section that covers a wide range of tips and tricks. |
| |||||||
![]() |
| |
| | #1 (permalink) |
| | window.onresize bug or feature? 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. |
My System Specs![]() |
| | #2 (permalink) |
| | Re: window.onresize bug or feature? On Mar 14, 1:46 pm, Csaba Gabor <dans...@xxxxxx> wrote: .... Quote: > 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. Quote: > > 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. 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 |
My System Specs![]() |
![]() |
| Thread Tools | |
| |
Similar Threads | ||||
| Thread | Forum | |||
| Why I think the help & support feature is the best feature on Windows Vista. | Vista networking & sharing | |||
| Is there a way to add tasks feature and to do feature to windows live mail? | Live Mail | |||
| Vista 3d Window Switcher feature | Vista General | |||
| Missing Feature in New File Associations Window? | Vista General | |||
| "Browse Window"/Places Bar Feature | Vista General | |||