The default value is 30000 (30 seconds). This is a design-time property.

Most users will start using blocking operation. The developer's decision to use blocking (Timeout > 0) or non-blocking (Timeout = 0) operation is important; these controls were designed to consistently support both methods of operation.

When set to a positive number of milliseconds, methods block while waiting for the initial response from the method. For example, an FTP or HTTP Get() method on a file will block until response is received. The Blocked property indicates this state. For example, if the Connect method is used with a Timeout of 30000, then the method only returns without error if the connection is established within 30 seconds. This is the easiest design to implement, but not the most robust. If the user attempts to initiate a different method while the Blocked property is True, an error is generated. Also, if the user attempts to close the application while the Blocked property is True, abnormal program termination may result.

When set to 0, no method blocks. It is up to the application to sense the success or failure of the operation by putting code in the related event. For example, if the Connect method is used with a Timeout of 0, then the application can test for the value of the State property from within the State event. This is the most efficient technique, as no idle loops are used to capture the thread of execution waiting for an event to occur. This is also the safest way to use PowerTCP because non-blocking use allows PowerTCP to unload gracefully under any condition.

The novice will probably use blocking operation first because this is the easiest way to immediately use the product. With no explicit error handling enabled (for example, the VB OnError statement), methods return errors into the environment and program execution stops. Once you add error-handling code, most applications will work satisfactorily. While the thread is captured in the method, an idle loop processes Windows messages and few side effects will ever be noted. There are some limits, however, that you should be aware of:

• The only way to abort a blocking method is to call the Abort method off a Timer or some user interface event.
• With the exception of the Abort method, the developer can only be in one method at a time (this protects your program from reentrancy problems).
• If the user closes the application while PowerTCP is blocking, the blocking method attempts to return when this is sensed, but a general protection fault may still be experienced (because the application is being terminated while PowerTCP is in an idle loop).

Non-blocking operations are more fault-tolerant. Set the Timeout property to 0 (at design time or at run time), initiate methods as desired, and insert most of your code in the appropriate event. This eliminates problems associated with reentrancy, users performing unanticipated actions in your application, and error recovery.

Note: Asynchronous operation is dependent upon an active MessageLoop. If an asynchronous operation is started, and subsequently a synchronous process (such as a lengthy database query) is started (immediately or off a timer), operation may be affected. In some development environments, the MessageLoop can be executed by calling DoEvents() repeatedly, but this design is not optimal. Preferred approaches include:

• Operate the synchronous process on another worker thread
• Operate the control itself on another thread or process
• Split the synchronous process into smaller pieces that operate off a timer event

Pop Object  | Pop Members