Bloqueios de documento

O Protocolo de Bloqueio de Documento

Para solicitar um bloqueio de documento para aplicativos baseados em ACP, o gerente do TSF chama ITextStoreACP::RequestLock. Para aplicativos baseados em âncora, o gerenciador do TSF chama ITextStoreAnchor::RequestLock. O aplicativo concede o bloqueio de documento chamando ITextStoreACPSink::OnLockGranted (aplicativos baseados em ACP) ou ITextStoreAnchorSink::OnLockGranted (aplicativos baseados em âncora) dentro do RequestLock. O bloqueio só é válido durante a chamada OnLockGranted . Quando OnLockGranted retorna, o documento é considerado desbloqueado.

Tipos de bloqueios de documento

Há dois tipos de bloqueios de documentos, somente leitura e leitura/gravação. Um bloqueio somente leitura permite que o gerenciador leia o texto, mas não pode modificar ou inserir texto. Um bloqueio de leitura/gravação permite que o gerenciador leia, modifique e insira texto. Um bloqueio somente leitura é solicitado especificando TS_LF_READ em dwFlags. Um bloqueio de leitura/gravação é solicitado especificando TS_LF_READWRITE em dwFlags.

Solicitações assíncronas e síncronas

Uma solicitação de bloqueio pode ser síncrona ou assíncrona. O gerente solicita um bloqueio síncrono usando o sinalizador TS_LF_SYNC em dwFlags. Se esse sinalizador não estiver presente, a solicitação será assíncrona.

Concedendo o bloqueio

Quando RequestLock é chamado, o aplicativo deve determinar se o documento está bloqueado no momento. Se o documento não estiver bloqueado e nenhum outro motivo para negar o bloqueio existir, o aplicativo deverá definir phrSession como S_OK e retornar S_OK.

Se o documento estiver bloqueado e a solicitação de bloqueio for síncrona, o aplicativo deverá definir phrSession como TS_E_SYNCHRONOUS e retornar S_OK. Isso indica que uma solicitação síncrona não pode ser concedida.

Se o documento estiver bloqueado e a solicitação de bloqueio for assíncrona, o aplicativo deverá enfileirar a solicitação, definir phrSession como TS_S_ASYNC e retornar S_OK. Quando o documento estiver disponível, o aplicativo deverá remover a solicitação da fila e chamar OnLockGranted. Esse enfileiramento de solicitações de bloqueio é opcional; há um cenário ao qual um aplicativo deve dar suporte. Se o documento tiver um bloqueio somente leitura, a nova solicitação de bloqueio será de leitura/gravação e a solicitação será assíncrona, o aplicativo chamou onLockGranted , o que causou uma chamada reentrante para RequestLock. O aplicativo deve definir phrSession como TS_S_ASYNC e retornar S_OK. Depois que a chamada para OnLockGranted retornar, o aplicativo deverá processar a solicitação de atualização chamando OnLockGranted novamente com TS_LF_READWRITE.

Imposição de bloqueio

O aplicativo deve garantir que o tipo adequado de bloqueio exista antes de permitir o acesso ao documento. Por exemplo, o aplicativo deve verificar se um documento tem pelo menos um bloqueio somente leitura antes de permitir que ITextStoreACP::GetText ou ITextStoreAnchor::GetText prossiga. Se o bloqueio adequado não existir, o aplicativo deverá retornar TF_E_NOLOCK.

Tópicos relacionados

Repositórios de Texto

ITextStoreACP::RequestLock

ITextStoreACPSink::OnLockGranted

ITextStoreACP::GetText

ITextStoreAnchor::RequestLock

ITextStoreAnchorSink::OnLockGranted

ITextStoreAnchor::GetText