[ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ]

Hospital

Let's consider another scenario. Imagine a nurse on her routine tour through a hospital. She might be carrying a laptop computer or perhaps a Windows CE device. While she visits with patients, she is taking notes, scheduling tasks, ordering treatments, and so forth. While she's doing that, she is not connected to the network (unless she has a wireless connection which is an option we will ignore for the moment). Therefore, components that are running on other computers will not be available while the nurse is on her tour. So tasks such as ordering medicine or treatments may not be available since the computer she is using is in offline mode. However, if those components are executed in queued fashion, the request will simply be stored in the queue until the computer is connected to the network and can actually reach those components.

Again, the developer is not required to do a lot of extra work (as we will see in some code examples below).

Queued Components and Visual FoxPro 6.0

For obvious reasons, Queued Components cannot return values. Nor can properties be read. The reason is simple: The actual component is not instantiated at the time it is used. For this reason, only input parameters, methods that don't return a value, and write-only properties are allowed.

Visual FoxPro 6.0 does not fulfill all those requirements. In Visual FoxPro, every method returns a value (if nothing is specified, .T. is returned automatically). For that reason (among others), Queued Components cannot be utilized in Visual FoxPro 6.0.

Overview

The basic concept of queued components is simple. The client application instantiates a component through the queue. The queue intercepts the request and instantiates a recorder object instead that looks just like the real object to the client. The client then makes all the calls to the recorder object just as if it was the life component, but in reality, all those calls simply get recorded to the queue.

At a later point in time, the queue instantiates a player object that instantiates the component the client wanted to instantiate in the first place. To the component, there is no difference whether it is called by the actual client or by the player object.

[ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ]