This is a technical document about PE's construction -- you do not need to read it to use PE! It is provided for those who may be interested in adapting some downloaded PE javascript to their own applications.
 
Abbreviations used in this document: IE Microsoft's Internet Explorer browser; IMBIF Immediate-Mode Button in Invisible Frame. JS javascript/JScript; NS Netscape's browser; PE Protein Explorer;

For background and an introduction to the PE in IE project, and for details on the implementation of browser and Chime version testing, please see Browser Testing first.
 
I have made a very large effort to make PE work in IE as well as possible, within the limitations of Chime's function in IE. There are some inadequacies that are beyond my control. These are listed in How and Why PE works better in Netscape 4.7x/4.8x than in IE.

In order to get PE to run in IE, first the idiosyncracies and bugs for Chime+IE needed to be discovered and understood, and then worked around with creative javascript. Paul Pillot made a big start on this as a volunteer. Below are a list of these issues and the strategies used to work around them.

Major/Critical Issues Fixed.

• Browser and Chime version detection were completely redesigned, as explained elsewhere.
   
  
• IMBIF. In NS, script strings are sent to Chime with a special javascript function, defined by the invocation of Chime, executeScript(). This uses a proprietary Netscape mechanism called LiveConnect. In early versions of Netscape, use of the IMBIF method (read on) caused the browser to crash frequently, which forced me to begin using LiveConnect. PE continues to use LiveConnect (for NS only) since there has been no need to change (see s2netscape() in shared/s2c2.js).

  LiveConnect is not implemented in IE. Therefore, command script strings are sent to Chime by using JS to re-write a document contained in an invisible iframe. The document contains a single "immediate-mode" button that executes without being clicked. This method is called IMBIF (see abbreviation list above). IMBIF has been for several years demonstrated in a downloadable interface. For the implementation in PE, see the IFRAME created in the Chime frame in protexpl/pe_proj.htm, and IMBIF() in shared/s2c2.js.

  When Chime 2.6 SP4 was released (Sept 12, 2002), a change was needed in the IFRAME (first reported by Paul Pillot on the RasMol email list on Sept 13). Previously, the IFRAME could be made invisible by having a height and width of zero pixels. With SP4, this failed to send commands to Chime in IE. The IFRAME needed to be >5 pixels in each dimension. In PE, it was made invisible with "frameborder=0" (see IFRAME in protexpl/pe_proj.htm) and by keeping the background color of the series of contained documents the same as that of the surrounding background.

• Single quotes prohibited in commands. IMBIF requires that that command script string be quoted. I used single quotes (') so anything that needed to be quoted in the command script could use double quotes ("), because I thought people would be more likely to use double quotes. Single quotes cannot be used in commands sent to Chime because they prematurely end the command string. (I tried every escape mechanism I could think of without success, but I may have missed a trick. I tried \' and \\'.) If you manually enter a command containing single quotes, an error message will intercept to prevent malfunctions.

  Single quotes were removed from all script strings (e.g. in comments) (I hope).

• Semicolons in comments in script strings caused no problem in NS, but were interpreted as an end-of-command in IE, thereby typically causing the remainder of the comment to be misinterpreted as an invalid command. Semicolons were removed from all script strings (I hope).

• Message unscrambling. PE needs to parse the message stream returning from Chime in order to determine many crucial pieces of information, such as the selected atom count, and when Chime has completed a script and PE can go from Busy to Ready. All this requires that messages come back from Chime in the order in which commands are processed. In Netscape, messages are scrambled in an unpredictable way. To solve this, at my request, Tim Maffett numbered the messages, and I wrote a large amount of code (over 400 lines exclusive of comments) to unscramble them (see Design Features, also unscramb.txt, scrambld.txt, unscramb.js, all in the shared folder).

  In IE, Paul Pillot reported that messages are not scrambled. However, in my tests, even small numbers of messages seem to come back in reverse order (last first). Therefore, the IE message stream is also being processed by the unscrambler -- this seems to do no harm and it didn't seem worth the time to do further tests to fix what wasn't broken. No changes were needed to the unscrambler code.  

• .pdb file loading kills remainder of script. Many scripts begin with a "load pdb" command, and continue with rendering commands. These work fine in NS. In IE, any command that accesses a file (namely load "file.pdb" and script "file.spt" commands) stops script execution -- the remaining commands in that script are not executed. For .spt files, the remaining commands cannot be resuscitated. In contrast, when the script was sent via IMBIF, Paul Pillot discovered that the remaining commands are resuscitated when another file access command is received by Chime, AFTER that command is executed. For example, if the first script is

  load "1hho.pdb"
  wireframe off
  spacefill
  color green

  the result is a wireframe display of oxyhemoglobin. If this is followed by

  load "atp.pdb"

  the result is a spacefilled, green ATP! If, instead, the second script is

  script "dummy.spt"

  where the "dummy.spt" file contains only one line, a comment, the result is a green spacefilled hemoglobin.

  The behaviors described above are based on tests from local files. There is some evidence (transient wireframe display during molecule loading in PE) that behavior on-line from a server is different. Details have not been documented.

• Loading and FirstView rendering of PDB files in PE was redesigned to accomodate the above behaviors.

• Detecting script completion. Because "load" commands stop script execution, exception code had to be installed to detect the completion of a load command. In NS, the message stream is watched for a special End-Of-Script (EOS) message that is added to the end of all scripts in a comment. In IE, the load commands prevents the comment from being messaged. Paul Pillot inserted code to detect a message that does come back, namely "Chime script completed.", and to signal the end-of-busy condition only when preceded by a message that begins "Requesting" (which occurs only for load and script commands that request files). This code is in file msgcall2.js. I added a new function send_load_script() (in s2c2.js) to handle load commands. In IE, it doesn't append the EOS signal (since it has to be handled differently and would end up coming out later and confusing the busy/ready controls), while in NS it does.

• Some .spt files converted to script strings. So many problems were found with .spt files that some were converted to javascript strings conveyed via IMBIF (e.g. those that render the first view in shared/loadit2.js). In other cases. the existing .spt files seem to work reliably (e.g. in DISPLAY, Contacts, the "cont*.spt" files in shared).

• Explicit newlines or semicolons required in command script strings. This concerns the format for command scripts sent to Chime via IMBIF, as JS strings. In both NS and IE, commands can be delimited either by newlines alone, or by semicolons alone (or by both). In NS but not IE, literal newlines, escaped with backslash, become newlines in the string. For example

  var x = "select protein\
  cartoon\
  color red";

  contains two newlines in NS, but not in IE. In IE the above string is identical to

  var x = "select proteincartooncolor red"

  In order to get the command string to work in IE, either semicolons must be added after each command, or \n must be inserted, like this

  var x = "select protein\n\
  cartoon\n\
  color red";

  Hope I got them all!

• history.length is used in a few critical places in PE. Lengths in IE are one less than in NS for the same "length". Exception-handling code was installed to deal with this.

• Distinct names required for concurrent Chimes. In NS Protein Explorer, each Chime was named "chime_graphics" (the bottom one in Comparator, "chime_2graphics"). However, PE assigns a number to each session, and opens a distinctly named window for each session. Each window name contains the session number, plus "F" if PE is being run from a downloaded local Files, for example "PE_Win_F01". (The "F" distinction allows on-line and off-line PE sessions to run concurrently.) In NS, the distinct parent window names were sufficient to keep the Chime objects in two sessions separate, even though the Chime names were identical. In IE, distinct Chime names were required, so the names are now, e.g. "chime_graphics03" (for the 3rd Explorer session on-line) and "chime_2graphics01F" (for the bottom Chime in the first off-line Comparator session). In NS, you can right click in the gray border around Chime and View Source to see the actual name assigned; IE shows the javascript that generates the name but not the actual code generated.

  Less Critical Issues Mostly Fixed.

• Project Folders. It is possible to set a Project Folder in IE, and run rendering scripts. Because of bugs in the Chime/IE combination, there are severe limitations. Details are provided in Using Chime Command-Script Files in Protein Explorer's Project Folder with Microsoft Internet Explorer (PE/IE).

• Newlines in alerts. In NS, strings containing backslash-newlines display in alert() and confirm() messages with the newlines intact. In IE, the newlines are lost, so they display without newlines (very wide) and with words joined lacking spaces. These were fixed where noticed but some may have been missed.
   
  
• Opening an optimally large (1024 x 768 pixel) window for each new session has been improved and streamlined. In most cases, PE will now open directly, without the intermediate request asking for the user to ensure that the window is adequate that formerly occurred for every session. Neither NS nor IE appear to have a mechanism for opening a new window that is maximized. Both can determine the screen size by the same mechanism (screen.width); determination of the size of an already-open window differs (e.g. window.outerWidth in NS vs. document.body.clientWidth in IE). By default, PE now opens a window the same size as the screen, unless the screen is larger than 1024 x 768 pixels, in which case it opens a window 1024 x 768 (because that is adequate). If the screen is smaller, PE recommends increasing the screen resolution. There is a checkbox on the FrontDoor that is checked by default. If unchecked, it lets each browser open its default window size. For NS, if the last window closed was maximized, then new windows are maximized by default; but for IE, new windows are never maximized and are always smaller than the parent window. Instructions for the user are provided in a new document Window Size Control in PE. When the checkbox is unchecked or the screen size is too small, explanations appear automatically in a resizable window.

  The javascript that controls the new window size is in in winsize2.js.

• NS and IE use different parameters to place the upper left corner of a newly opened window (screenX,screenY vs. left,top respectively). A function ul_corner(x, y) in util_top.js was created to handle this.
   
  
• Catch 22. The different method used by IE to report the size of an existing window (document.body.clientWidth is the only method known to me) has a catch-22 consequece. If you want the content of a document to depend on the size of its frame, you can't find out the size of the frame until after the document is loaded! So in cmd2way2.htm, I resorted to first loading a blank document and placing the size of its frame in top-level variables, then loading the real document referencing those variables.
   
  
• Embed commands follow script file. When coming from a server, if the initial view comes from a script file (rather than a javascript variable), bgcolor and startspin commands in Chime's embed tag (in pe_proj.htm) are executed after(!) the script file commands. This is not true when run in local mode! And not true in Netscape. To prevent the embed commands superceding the script, I removed bgcolor and startspin from the embed tag. This caused no problems because the intial view script already included background and spin commands.
   
  
• "javascript" commands to Chime cause the image to flicker in IE only. Command scripts for Chime that display multiple images with refresh commands cause the image to flicker if "javascript" commands precede the refresh commands. The flickering (or "jumpiness" or "static") occurs in IE only, not in Netscape. Such scripts were originally used in animations generated by the NMR Models/Animations control panel. The javascript commands in these scripts displayed the current model number in a form slot during the animation. When the cause of the flickering problem was finally identified in December, 2002, the model number display was removed from the animation windows to enable the animations to run smoothly in IE.

  Minor Inconveniences Unfixed.
  We can live with these for now, so they weren't fixed.

• Command recall. In Netscape, you can recall previously entered commands by typing comma (,). The command appears in the slot, but the cursor remains at the left end of the slot. This means that you can press comma repeatedly to scroll through prevous commands. In IE, the cursor goes to the end of the recalled command. This means you have to press Home before another comma will recall the next command.

• Transient wireframe rendering when a new molecule is loaded, before the firstview rendering appears. Paul Pillot came up with a cute trick to avoid this. Unfortunately, this trick works only when PE is operated from local files in a downloaded copy, so on-line, you still see the unwanted wireframe for a moment.

  Paul's trick was to first send this script:

  script "dummy.spt"; #dummy.spt contains only one line, a comment
  wireframe off;
  backbone off;

  followed by the load command. The load command, being a file access (see above) triggers the post-.spt commands in the previous script to execute AFTER the load command -- hence to hide the wireframe before Chime completes execution of the "script". This is what I call convoluted and devious code! Wonder what it will do when and if MDL "fixes" Chime's behavior in IE?!

  Can't Be Fixed.
  Beyond my control.

• Closing the second of two (or more) windows containing Chime causes a Plugin Error that occasionally crashes IE. See Tips for more (warning displays in tips document only if you are using IE).

• Animations are jumpy. A red warning appears at the top of the Animations window (created from the NMR Models/Animation page) when you are using IE. Netscape displays animations much more smoothly.