vb写的ole 回调函数

'This sample demostrates the use of an ole object ptr being passed to 'an external (and optionally remote) ole server. The ole server then 'periodically calls a method on this object ptr. This has the effect of 'a server initiated callback to the client... which can be a much better 'app model that the polling a client app might have to do otherwise to 'find the status of a server. Although this demo simply returns the time 'to the client, it could just as easily return data, news, or other information 'it has been told the client wants to know. The benefit here is that the 'server does all the work looking for data the client might need... and the 'client does other work... only being interrupted when the server actually 'has something that interests it. 'Note1: In this scenario, the client creates an object that is internal to it' 'It then creates an instance of the remote server and passes an object 'ptr to it of its internal object. The server hangs onto the client's object, '"feeding it" from time to time. At somepoint the client decides to 'disconnect (DropObjectReference) and the server does some clean up 'work in preparation for the client setting its reference to the server = 'Nothing. Since this server has a visible form (servers usually will not 'have any visible displays except for debugging information), it unloads 'it at this point so that the instance will be closed by ole when the client 'sets the reference = Nothing. 'Note2: Since the client created both the instance to its internal object 'and the instance to the server... it is important that the client be the one 'to close these instances by setting them = Nothing. OLE errors will 'occur if the server tries to set the reference to the client = Nothing. 'Note3: This app was developed very quickly... and should not be taken 'as gospel on how to build good servers. For example, a good server 'should not have ANY msgbox calls outside of a debug mode. (If a 'production server tried to display a msg for the user... it could wait a 'long time for someone to come by the server machine to click "OK".) 'This sample will be refined and cleaned up before final release. 'Note4: The following class properties are critical for the behavior of 'the application: ' ' "Instancing = Creatable SingleUse" This causes OLE to create a ' new physical instance of the class for each client. This ' provides a simple programming model for creating parallel ' execution paths on the NT server, but requires a fair amount ' of memory to be allocated for each client. Literally, SingleUse ' means the server is only used by a a single client at a time. ' A more efficient runtime model can be achieved if the setting ' of "Instancing = MultiUse" is set. This causes OLE to only ' create an instance of the server for the first client... all other ' clients will get a ptr to the initial instance when they do their ' creates. This model is more efficient from a memory standpoint, ' but OLE will only allow one client to use the class instance at ' a time... which could cause client blocking if the work the class ' does takes longer than the average client request interval. A ' good compromise between these two implementation options is ' to use a pool of SingleUse servers. In this case, 100 clients ' might have access to a pool of 10 class instances. See the ' poolmngr sample for more details on this scenario. ' ' ' "Public = True" This allows external apps to access this class through ' OLE. ' "Name = Stuff" This name is used as the class name in the second part ' of the progid. The client references this progid to tell OLE what ' object it wants to start. 'Note5: 'In the Tools.Options.Project dialog, it is very important that the project name 'be set. This is used by the client to define the project name in the progid. After 'creating an ole server exe, the exe must be run once so that it can register its 'OLE typeinfo data in the system registry. After running it once, close the server 'manually and everything should be set for your client app to call the server through 'OLE. 'Note6: Every time you build a new exe of your server, VB will generate a new 'unique ID for each of its classes. Since this ID must be the same ID that is also 'registered in the client machine's registry, this constant changing of the ID can 'make keeping the client and the server working together a real chore. To get 'around this, go to the Tools.Options.Project dialog and set the "Compatible OLE 'Server" field to a previous instance of the server exe. Then, each time VB rebuilds 'your server exe, it will steal the classid(s) out of the previous version. It will also 'do other checking to try to make sure you have maintained compatibility with earlier 'versions.