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.

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 the use of LiveConnect. LiveConnect is not implemented in IE. Therefore, command script strings are sent to Chime by using JS to re-write the document in an invisible frame. The document contains a single "immediate-mode" button that executes without being clicked. This is called IMBIF (see abbreviation list above). IMBIF has been for several years available demonstrated in a downloadable interface.

• 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.

• .spt files eliminated. So many problems were found with .spt files that for now, they are not used (with one special exception, dummy.spt). Command scripts formerly in .spt files have been relocated to javascript strings conveyed via IMBIF. Luckily, this was easy because there were only a handful of .spt files used in the tutorial and in the firstview rendering.

• 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; NS but not IE can determine the size of an already-open window. 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. If the screen is smaller, a higher-resolution screen is recommended. 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.

• 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.

• 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.