Important:
This is retired content. This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.
A version of this page is also available for
4/8/2010

This method restricts access to a specified range of bytes in the array.

Syntax

HRESULT LockRegion( 
  ULARGE_INTEGER 
libOffset, 
  ULARGE_INTEGER 
cb, 
  DWORD 
dwLockType 
);

Parameters

libOffset

[in] Byte offset for the beginning of the range.

cb

[in] Length, in bytes, of the range to be restricted.

dwLockType

[in] Type of restrictions being requested on accessing the range. This parameter uses one of the values from the LOCKTYPEenumeration.

Return Value

The following table shows the return values for this method.

Value Description

S_OK

The specified range of bytes was locked.

STG_E_INVALIDFUNCTION

Locking is not supported at all or the specific type of lock requested is not supported.

STG_E_ACCESSDENIED

Access denied because the caller has insufficient permission, or another caller has the file open and locked.

STG_E_LOCKVIOLATION

Access denied because another caller has the file open and locked.

STG_E_INVALIDHANDLE

An underlying file has been prematurely closed, or the correct floppy disk has been replaced by an invalid one.

Remarks

ILockBytes::LockRegionrestricts access to the specified range of bytes. Once a region is locked, attempts by others to gain access to the restricted range must fail with the STG_E_ACCESSDENIED error.

The byte range can extend past the current end of the byte array.

Locking beyond the end of an array is useful as a method of communication between different instances of the byte array object without changing data that is actually part of the byte array.

For example, an implementation of the ILockBytesinterface for compound files could rely on locking past the current end of the array as a means of access control, using specific locked regions to indicate permissions currently granted.

The dwLockTypeparameter specifies one of three types of locking, using values from the LOCKTYPEenumeration.

The lock types are as follows:

  • Locking to exclude other writers

  • Locking to exclude other readers or writers

  • Locking that allows only one requestor to obtain a lock on the given range.

This third type of locking is usually an alias for one of the other two lock types, and permits an Implementer to add other behavior as well. A given byte array might support either of the first two types, or both.

To determine the lock types supported by a particular ILockBytesimplementation, examine the grfLocksSupportedmember of the STATSTGstructure returned by a call to the ILockBytes::Statmethod.

Any region locked with ILockBytes::LockRegionmust later be explicitly unlocked by calling the ILockBytes::UnlockRegionmethodwith exactly the same values for the libOffset, cb, and dwLockType parameters.

The region must be unlocked before the stream is released.

Two adjacent regions cannot be locked separately and then unlocked with a single unlock call.

To determine whether the platform supports this interface, see Determining Supported COM APIs.

Notes to Callers

Because the type of locking supported is optional and can vary in different implementations of ILockBytes, you must provide code to deal with the STG_E_INVALIDFUNCTION error.

Notes to Implementers

Support for this method depends on how the storage object built on top of the ILockBytesimplementation is used.

If you know that only one storage object at any given time can be opened on the storage device that underlies the byte array, then your ILockBytesimplementation does not need to support locking.

However, if multiple simultaneous openings of a storage object are possible, then region locking is needed to coordinate them.

A LockRegionimplementation can choose to support all, some, or none of the lock types. For unsupported lock types, the implementation should return STG_E_INVALIDFUNCTION.

Requirements

Header objidl.h, objidl.idl
Library ole32.lib, uuid.lib
Windows Embedded CE Windows CE 2.0 and later
Windows Mobile Windows Mobile Version 5.0 and later