For example, SampleEEG.dat -- an EEG data file generated by a BioLogic Brain Atlas II -- could be converted by convert.ocx to SampleEEG.gif with the original BioLogic header and data-acquisition parameters appended. Then, during some future operation of the QEEG Program, the name and location of this GIF file could be passed to gif2eeg.ocx via the FileName Property and the GIF file could be re-coverted to the original data file. Briefly, this involves converting the GIF to a BMP, reading the ini parameters for instructions on how to convert the BMP to the original data structure, copying the ini parameters to SampleEEG.ini, doing the conversion, re-attatching the original BioLogic header, and thereby re-creating the original SampleEEG.dat. And none of these manipulations interfere with the integrity of the data or quality of the graphic.

The method by which this control is installed in the Client computer involves posting the control to a remote server along with an HTML document with an appropriate reference to it. When Internet Explorer loads this document, it installs the OCX control and runs whatever Script may be associated with it. And early on in the development of gif2eeg.ocx, I realized that the GIF files created by convert.ocx could be referenced by the same HTML document, thus landing in the Cache of the same Client computer as the OCX control. Which provides an alternate mode of data transfer -- basically, using HTTP instead of FTP. All that's required is for gif2eeg.ocx to be programmed to retrieve the GIF file from the Cache before converting it.

Along with these changes, I wrote a small (22K) program called any2gif.exe which converts any kind of file to a GIF but doesn't append ini parameters and, in fact, has nothing to do with the QEEG Program. Files produced by this program have names like FileName_(Extender).gif. For example, Program.exe would be converted to Program_exe.gif. And, at the same time, convert.ocx was slightly altered so that the files that it produces are now called, for example, SampleEEG_bmd.gif. (BMD stands for Bit-Mapped Data and has special meaning to the QEEG Program)

In it's present form, then, uncache.ocx retrieves GIFs from the Cache and converts them to their original form. If the GIF file has _bmd.gif in it's name, it is converted to the original EEG data file structure and passed on to the QEEG Program. But one improvement allows the HTML designer to specify the ouput path of the converted file. By default, the control will search for a file called SampleEEG_bmd.gif and -- if it finds it -- convert it, copy it to the Cache, and pass it on to the QEEG Program. Therefor, if a GIF file created by convert.ocx is named accordingly and placed in the same HTML document as uncache.ocx, it will automatically be converted with no need of further coding in the HTML document.

However, by specifying folders and file names in the FileName Property of uncache.ocx, several files can be referenced by the same HTML document and directed to specific folders in the Client computer. For example, if the FileName Property was given this value:

• "C:\Temp\|AnotherEEG_bmd.gif|$(Prg)\QEEG\Data\ThirdEEG_bmd.gif"

...AnotherEEG.bmd and AnotherEEG.ini would be copied to C:\Temp\ and ThirdEEG.bmd and ThirdEEG.ini would be copied to ..\Program Files\QEEG\Data\

However, an inherent problem with AciveX controls was exacerbated by these changes. Security risks are increased considerably by allowing the control to execute programs. Because, theoretically, a malicious hacker could reverse-engineer the instruction set and run a program that would delete or steal content from the Client computer. This is an important topic, but is covered fairly well elsewhere.

It would also be friendlier to allow the Client to choose the destination folders of the files that are delivered. This would be an optional feature, controlled by a Property of the control. If selected, a Dialog Box with an input field and Browse... button would be presented before the files were copied. The Client would then enter the name of the destination folder or click the Browse... button and navigate to the desired location. This would require about 4K of code and dependency on Comdlg32.dll.

The control functions synchronously during some routines, which locks up the computer and won't allow scrolling or smooth escapes. That was a mistake and will be fixed -- with 4 Bytes of code.

The visibility of the Command button and the triggering of the Timer event will also be changed. As it is, the control either does nothing until the Client does something, or runs to completion with no user input. In the next Version, the control will begin running immediately (and asynchronously, to allow Client input) -- but it will have a "Command" Property (or some such thing) which will determine whether the control runs to completion or waits for Client input before performing certain tasks. That is, the control will begin retrieving and converting files as soon as it is loaded, but -- if the Command button is visible (Command=True) -- no WAV files would be played, or programs executed, or files copied to anywhere but the Cache -- until the Client clicks the button. For added Security, this will be the default value of this control. And these changes probably won't resust in a net increase in the total code.