There is what I believe to be a very severe design error in the Main.htm in the Gizmox.WebGUI.Forms.2.0 project under Commons/Dialog.

If you take pretty much any Visual Web Gui project and refresh the browser (IE7 on XP) by holding the CTRL key down (which forces a full browser refresh), the body's KeyDown event fires before the javascript file Resources.Gizmox.WebGUI.Forms.Form.js.wgx has been loaded properly.

You can get the same error (on the resize event) if you resize the browser while refreshing.

Also try closing the browser refreshing, etc etc.  The big big problem is when you do multiple refreshes very quickly.  The beforeunload and unload events go nuts with javascript failures everywhere (object not set or something).

I believe the problem lies with the "deferred" setting in the line:

<script language="JavaScript" deferred="true" src="Resources.Gizmox.WebGUI.Forms.Form.js.wgx"></script>

I am not 100% sure on this but from what I could quickly gather...

What "deferred" does as far as I can determine is that it tells the browser that the file won't produce any output to be rendered.  So it can process it later.  In effect what happens is that any in-line javascript in the current document is allowed to run before the include files are processed.  This results in object not found errors in the javascript which really wrecks my day.

The solution has been for me to remove that deferred attribute or comment out all of the events except for onload and a few others that I can't seem to get to break.

I also don't believe you should be wiring up those events on the body tag.  I have always been told that the onload event is the only safe event to begin running code in.  And from what I have experienced with VWG, I would say that this is true.  I did try to wire those events inside of the onload event but it didn't quite work for some reason.

I had been working with the source and at some point someone had put in checks to see if the functions tied to the events on the body tag were available...but by the time the code made it to a build, those checks were removed.  I don't believe that was a good fix either.  I think the events need to be wired in during the onload event.

-Mike
 

A little more background.  We are using VWG inside of a web application that uses the VWG ReportViewer Control.  It is a single form, using a querystring to pass parameters in.

This page is hosted within an IFRAME in a DotNetNuke portal page.

I have it on my plate to distill this down to a very simple application to maybe help you guys illustrate these issues. 

I understand that possibly our setup is not exactly the norm and maybe that is why we are seeing these issues when others do not.

I have also been very very careful to make sure that NO Gizmox DLLs reside ANYWHERE on the machines we deploy to except in the web application's BIN directory.  There are no GIZMOX Dlls in the GAC, none in Program Files, etc etc.  I can now roll forward and back VWG versions with very consistant results.

-Mike