Vista - Maintaining State Between Web Pages

I have written a visual automation server. The server controller is an html
web page. From the web page, I communicate with the server, using
MS COM standards, via vbscript. For example:

1. Create the server using vbs:
Set mySrvObj = CreateObject("ImageDisplaySrv.ImgDisp")

2 Perform a method call to the server:
iResult = mySrvObj.UnBusyInvoice(vDocID, vStaus)

This works perfect. From the web page, I can do method calls, send data to
the server, and get data back to display on my web page.

However, every time the web page refreshes, I lose the handle to the server
because vbs is basically stateless.

My Question: Is there a way I can make the automation server (mySerObj from
above) persistent between web pages?
Otherwise, the server closes when the old web page goes away and then opens
with the new web page displays.

If possible, how can I save what is stored in mySerObj when I do:
Set mySrvObj = CreateObject("ImageDisplaySrv.ImgDisp")

Can I save the server's handle to a file or cookie. Can I run another
program that will get the handle
information that I need to maintain state?

Suppose I first launch my server and login. Can vbs, some other client side
scripting language or program
find my server and get the handle in a form that allows me to do vbs method
calls?

Please help, I desperate!!

Thanks much.

Depends on what "between pages" means.

Between successive page hit BY THE SAME PERSON? That is, page hits within
the same SESSION?

Or between all page hits by all users?

If the latter, it's easy. Just use static data (shared in VB). All users
will get the same data.

But I'm guessing you mean between hits in the same session.

In which case you've got some choices.

First off, *IF* you coded your COM object using the right threading model,
you could simply store an instance of the object in a session variable.

Set myObj = Server.CreateObject("myfoo.whatever")
...
Set Session("foo") = myObj

If you used apartment threading, this is a bad idea. When the object is
needed again, it has to be instantiated in the same thread it was created in.
Can cause performance bottlenecks. Having said that, it's not a *terrible*
idea if your web site is only lightly loaded and especially if your component
is only used for (say) a fraction of a second on each page. But if you want
the best possible performance, you need to make the object "both threaded."

It's my understanding that VB6 is not capable of creating "both threaded"
COM objects, though I *believe* it can produce apartment threaded ones. You
don't say how you created your custom object, but if you did it with VB, you
are stuck.

Incidentally, you *MUST* use
Server.CreateObject
and *NOT* just
CreateObject
if you intend to save the object in a Session value, or at least that is my
own understanding.

I'm NOT an expert on this stuff. I created a grand total of two COM objects
for use with ASP, mainly just to see how it was done. Since most ISPs won't
allow you to install your own custom objects, and since all but one of the
web sites I've worked on were hosted by ISPs, it seemed pointless to use them.

"Old Pedant" <OldPedant@xxxxxx> wrote in message
news:14752B59-5E47-49D5-B702-0F8333E1DA1D@xxxxxxYou could also create in the global.asa. Perhaps even declare it using the
object tag.


--

Joe Fawcett (MVP - XML)
http://joe.fawcett.name

crashRCFlyer wrote:I'm not sure where this poster has indicated that ASP is in use? Without
ASP, neither Session, nor ASP, nor Server.CreateObject is available.

My impression from this is he is attempting to instantiate a com object
installed on the client machine using client-side vbs code in a .htm file.
Would that be the correct interpretation, CrashRCFlyer? If so, you should
modify the COM object to add Save and Load methods, consisting of writing
the properties you wish to persist to files on the user's machine. This will
mean switching to using a .hta (hypertext application) file because .htm
files likely will be barred from accessing the user's file system
--
Microsoft MVP - ASP/ASP.NET
Please reply to the newsgroup. This email account is my spam trap so I
don't check it very often. If you must reply off-line, then remove the
"NO SPAM"

Reply to Old Pedant:

Thanks for your response. You asked a few good questions/issues.

A. This is a business application and will not run on an independent ISP.

B. "Depends on what "between pages" means.":
Each time the user hits enter or clicks a "Save" button, this is a page
refresh.

C. "If you used apartment threading, this is a bad idea.:
The srever runs on the client machine. All method calls are performed
sequentailly. I used Apartment threading model.

The server is written in Delphi 7. I purchased Delphi 1 about 10 years ago
and fell in love with it. It is my hobby. I know Delpi will never get me a
job, but I like it.

Below is information regarding the servers Instance and Threading Model
taken from Delphi Help. [bold]What would your recommendation be regarding
Instance and Threading Model.[/bold]

INSTANCE MEANING

When your COM application creates a new COM object, it can have any of the
following instancing types:

1. Internal: The object can only be created internally. An external
application cannot create an instance of the object directly.

2. Single Instance: Allows only a single COM interface for each executable
(application), so creating multiple instances results in launching multiple
instances of the application.

3. Multiple Instance: Specifies that multiple clients can connect to the
application. Any time a client requests the object, a separate instance is
created within a single process space. (That is, there can be multiple
instances in a single executable.)

Note: When your Automation object is used only as an in-process server,
instancing is ignored.


THREADING MODEL

Choose the threading model to indicate how COM serializes calls to your
Automation object’s interface. The threading model you choose determines how
the object is registered. You must make sure that your object implementation
adheres to the model selected.

Automation Objects can have one of the following:

1. Single: Only one client thread can be serviced at a time. COM serializes
all incoming calls to enforce this. Your code needs no thread support.

2 Apartment: Each object instantiated by a client is accessed by one thread
at a time. You must protect against multiple threads accessing global memory,
but objects can safely access their own instance data (object properties and
members).

3. Free: Each object instance may be called by multiple threads
simultaneously. You must protect instance data as well as global memory.

4. Both: This is the same as the Free-threaded model, except that all
callbacks supplied by clients are guaranteed to execute in the same thread.
This means you do not need protect values supplied as parameters to callback
functions.

5. Neutral: Multiple clients can call the object on different threads at the
same time, but COM ensures that no two calls conflict. You must guard against
thread conflicts involving global data and any instance data that is accessed
by more than one method. This model should not be used with objects that have
a user interface. This model is only available under COM+. Under COM, it is
mapped to the Apartment model.

Note: Under COM+, the serialization of calls to your object is also
influenced by how it participates in activities. This can be configured using
the COM+ page of the type library editor or the COM+ Component Manager.

"Bob Barrows [MVP]" wrote:
In order to make the server persistent using Save & Load, what properties
should I save and how do I access to these properties?

crashRCFlyer wrote:Sorry, but I have no clue. The only answer I can give is to save whatever is
needed to rebuild the saved object when you reload it using the saved data.
For a model of what I am talking about, look at how ADO has Save and Load
methods for recordsets. You need to do smething similar to what they do.

--
Microsoft MVP - ASP/ASP.NET
Please reply to the newsgroup. This email account is my spam trap so I
don't check it very often. If you must reply off-line, then remove the
"NO SPAM"

"crashRCFlyer" wrote:OH! So this is all *IN THE BROWSER*???

That is, the COM object lives in the browser, too?

I guess I should have tumbled to that when you said it was a "VISUAL
automation server." But then you said "communicate with the server" and I
foolishly assumed *web* server.

Hmmm...

*NOT* an expert in this stuff, but...

(1) I assume if it "lives" in the browser, then there's no need for any
particular kind of threading, as there will indeed be only one thread using
the code at a time. Apartment threaded is probably the cleanest, but
single-threaded may be sufficient.

(2) If you could ensure that the object is created when the first page is
used and never destroyed, and if you simply used "shared" (that is, static)
data, then all pages WOULD share the same data.

So...

Why not use either multiple tabs or frames. Instantiat the object in one
tab or in one frame and then just leave it there, always untouched, doing
nothing except ensuring that it is still "live." Then, as pages come and go
in another tab or frame, they can connect to the object and, because the data
is SHARED, they will all see the same data, every time.

**********

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.

***********

Apologies for going off in *WAAAAYYYY* the wrong direction. All my babbling
was about using an ActiveX object on the WEB server, in IIS.

"Old Pedant" wrote:
Thanks for your reply.

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. It is
nothing more than an ActiveX control based on a Delphi Form. There is
certainly the equivalent in MS VB and MS .NET tools.

Your thought about making the server a type that runs in a IE 6 will have to
be my fall-back position. I've done that before in Delphi.

I 've uploaded two jpg images in a zip file to rapidshare.com. The url is:
http://rapidshare.com/files/13313274...creenShots.zip

The images show:

1. A Visio Diagram showing the relationship between all components of the
system: remote Web Server, Client Web Page with bedded VBS code, client
Automation server, and remote Imaging File Server and DB Server.

2. The second image is a test web page that shows the WorkInvoice method.
At the top of the page is the company number and invoice type. Click the
Work Invoice button on web page. The server is launched, the next invoice
image is displayed in the automation server (on right side) and the Document
Number is returned to the web page. The test web page is a representation of
the Host Application,-Accounts Payable Business Application.

Please download the zip file ( 464 KB) and view the images. I hope it will
better explain the environment and relationship between the "objects".

You Wrote:
"Seems to me the alternative to this would be to always store the data toI have no idea how to do the above. I am not a technical guru. I'm just a
systems analyst who loves technology. That's why I try to program these "on
the fringes" sort of things.

Thank you!!!

"crashRCFlyer" wrote:
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.
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
terrible answers.
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.

So...

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
it, again.

*** 100% UNTESTED AND PURELY A GUESS ***

Still, it makes sense. It should certainly be worth trying.

<FRAMESET rows="100%,*">
<FRAME name="MAIN" src="mainpage.html" />
<FRAME name="HIDDEN" src="hiddenControlPage.html" />
</FRAMESET>

And then, in the "hiddenControlPage.html", you do
<SCRIPT Language="VBScript">
Set MasterSrvObj = CreateObject(....)
</SCRIPT>

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:

<SCRIPT Language="VBScript">
Set MySrvObj = parent.HIDDEN.MasterSrvObj
</SCRIPT>

and after that use MySrvObj just as you have been.

NOTE: Just be sure that none of your <FORM>s or <A> tags use
target="_top"
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.