> I am not running the automation server inside a web browser. I call an
> ActiveX object that runs within IE6 an "Active Form" in Delphi lingo.
Just a matter of implementation. Okay, it runs as an independent process,
instead of as a browser plugin. Simpler to do, of course. More flexible,
too; not limited to what the browser allows.
> I 've uploaded two jpg images in a zip file to rapidshare.com.
Looked at the images. All makes sense. Not completely clear what the
browser brings to the table (that is, why not just communicate directly with
the remote servers), but I guess flexibility and interoperability aren't
> You Wrote:
> "Seems to me the alternative to this would be to always store the data to
> > some known place, before the object is "torn down" by leaving one page and
> > then "built up" again on encountering another page. This wouldn't be hard.
> > You could just store to a temp file on the user's computer. And since you
> > control the format of the storing, you could use most anything you wanted
> > that would be efficient."
> I have no idea how to do the above.
Well, that's still a possible option. Really wouldn't be that hard to do.
But it means that you'd *STILL* see the control disappear every time you
changed web pages. And I presume that's as big an annoyance as anything else.
I admit I am *guessing* as to what causes your control to be "killed" when
the browser changes pages. I would *assume* that the link to the control
from within the web page says "I'm done with this object now" and then the
tearing down of that object ("mySrvObj") tells the automation object to close
itself. And by the nature of HTML pages and the objects they create, closing
the page (and, yes, that includes simply bringing up another version of the
SAME page) closes the object.
Thus the obvious solution is to *NOT* close the browser page that controls
the object. And you should be able to do that via (as I mentioned) browser
tabbed windows or <FRAME>s.
For example, suppose you had a <FRAMESET> that contained an invisible
<FRAME>, and if that invisible frame contained the VBS code that instantiated
the OLE object and thus launched the automation object. And then the
frameset *ALSO* contains a <FRAME> where the interactive web page is
displayed. The interactive frame's code can ask the hidden frame for a copy
of the reference to the object and then make the requested call on that
object. When the interactive frame moves to another web page (or even
re-loads the current one), the current copy of the object reference is lost.
But the hidden frame maintains the connection and the next page can ask for
*** 100% UNTESTED AND PURELY A GUESS ***
Still, it makes sense. It should certainly be worth trying.
<FRAME name="MAIN" src="mainpage.html" />
<FRAME name="HIDDEN" src="hiddenControlPage.html" />
And then, in the "hiddenControlPage.html", you do
Set MasterSrvObj = CreateObject(....)
and in the "mainpage.html" and in all pages that come after, you code
something like this to get a copy of the object reference:
Set MySrvObj = parent.HIDDEN.MasterSrvObj
and after that use MySrvObj just as you have been.
NOTE: Just be sure that none of your <FORM>s or <A> tags use
or equivalent. If you do that, then the reference page will be loaded at
the top level and will replace the <FRAMESET> and then the main object
reference will be forced to close.
This should be dirt simple to make a quick & dirty test to see if my
*guesses* are correct. Good luck.