Interface IOleParentUndoUnit (ocidl.h)

Permite que unidades de desfazer contenham unidades de desfazer filho. Por exemplo, uma ação complexa pode ser apresentada ao usuário final como uma única ação de desfazer, mesmo que várias ações separadas estejam envolvidas. Todas as ações de desfazer subordinadas estão contidas na unidade de desfazer pai de nível superior.

Uma unidade de desfazer pai é criada inicialmente usando o método IOleUndoManager::Open. A adição de unidades de desfazer sempre deve ser feita por meio do gerenciador de desfazer. Os métodos IOleParentUndoUnit::Open e IOleParentUndoUnit::Close nas unidades pai acabarão sendo chamados pelo gerenciador de desfazer. Fazer com que as unidades pai chamem de volta para o gerenciador de desfazer causará recursão infinita.

Enquanto uma unidade pai está aberta, o gerenciador de desfazer adiciona unidades de desfazer a ela chamando IOleParentUndoUnit::Add. Quando o gerenciador de desfazer fecha um pai de nível superior, toda a unidade de desfazer com seus subordinados aninhados é colocada sobre a pilha de desfazer.

É necessário que um pai habilitante esteja aberto na pilha antes que outras unidades de desfazer possam ser adicionadas. Se um não estiver aberto, a pilha deverá ser limpa. Isso é para garantir que unidades de desfazer sejam adicionadas apenas como resultado de ações do usuário e não ações programáticas. Por exemplo, se o aplicativo quiser tornar o clique de um determinado botão desfazível, mas essa mesma ação também é exposta por meio do modelo de objeto. Essa ação deve ser desfeita por meio da interface do usuário, mas não do modelo de objeto porque você não pode restaurar o estado do código de script do usuário. Como o mesmo código implementa a alteração em ambos os casos, o código da interface do usuário que manipula o clique do botão deve abrir um pai habilitante na pilha, chamar o código apropriado e fechar a unidade pai. O código do modelo de objeto não abriria uma unidade pai, fazendo com que a pilha de desfazer fosse limpa.

Um pai de bloqueio é usado quando você não deseja que seu código chame outro código que você sabe que pode tentar adicionar unidades de desfazer à pilha. Por exemplo, você deve usar um pai de bloqueio se chamar o código que cria unidades de desfazer, que seu código externo já criou que irá desfazer totalmente todo o comportamento desejado.

Um pai não habilitador é usado quando você dispara um evento em resposta a uma ação do usuário. A pilha seria limpa somente se o manipulador de eventos fizesse algo que tentasse criar uma unidade de desfazer, mas se nenhum manipulador existir, a pilha de desfazer seria preservada.

Se um objeto precisar criar uma unidade pai, há vários casos a serem considerados:

  • Para criar uma unidade pai habilitadora, o objeto chama IOleUndoManager::GetOpenParentState no gerenciador de desfazer e verifica o valor retornado. Se o valor for S_FALSE, o objeto criará o pai habilitante e o abrirá. Se o valor retornado for S_OK, haverá um pai já aberto. Se o pai aberto estiver bloqueado (UAS_BLOCKED conjunto de bits) ou um pai habilitante (UAS_BLOCKED e UAS_NOPARENTENABLE bits não definidos), não haverá necessidade de criar o pai habilitante. Se o pai aberto no momento for um pai desabilitador (UAS_NOPARENTENABLE conjunto de bits), o pai habilitante deverá ser criado e aberto para reabilitar a adição de unidades de desfazer. Observe que UAS_NORMAL tem um valor igual a zero, o que significa que é a ausência de todos os outros bits e não é um sinalizador de bit que pode ser definido. Se estiver comparando *pdwState com UAS_NORMAL, mascarar bits não utilizados de pdwState com UAS_MASK para permitir uma expansão futura.
  • Para criar um pai bloqueado, o objeto chama IOleUndoManager::GetOpenParentState e verifica se há um pai aberto que já está bloqueado. Se houver, não será necessário criar o novo pai de bloqueio. Caso contrário, o objeto o criará e o abrirá na pilha.
  • Para criar um pai desabilitador, o objeto chama IOleUndoManager::GetOpenParentState e verifica se há um pai aberto bloqueado ou desabilitado. Se houver um deles, será desnecessário criar o novo pai. Caso contrário, o objeto cria o pai e o abre na pilha.
Caso os sinalizadores UAS_NOPARENTENABLE e UAS_BLOCKED sejam definidos, o sinalizador mais relevante para o chamador deverá ser usado com UAS_NOPARENTENABLE tendo precedência. Por exemplo, se um objeto estiver criando uma unidade de desfazer simples, ele deverá prestar atenção ao sinalizador UAS_NOPARENTENABLE e limpar a pilha de desfazer. Se estiver criando uma unidade pai habilitadora, ele deverá prestar atenção ao sinalizador UAS_BLOCKED e ignorar a criação.

Quando a unidade de desfazer pai é marcada como bloqueada, ela descarta todas as unidades de desfazer recebidas.

Herança

A interface IOleParentUndoUnit herda de IOleUndoUnit. IOleParentUndoUnit também tem estes tipos de membros:

Métodos

A interface IOleParentUndoUnit tem esses métodos.

 
IOleParentUndoUnit::Add

Adiciona uma unidade de desfazer simples à coleção.
IOleParentUndoUnit::Close

Fecha a unidade de desfazer pai especificada. (IOleParentUndoUnit.Close)
IOleParentUndoUnit::FindUnit

Indica se a unidade especificada é um filho dessa unidade de desfazer ou de um de seus filhos, ou seja, se a unidade especificada faz parte da hierarquia nesta unidade pai.
IOleParentUndoUnit::GetParentState

Recupera informações de estado sobre a unidade de desfazer pai aberta mais interna. (IOleParentUndoUnit.GetParentState)
IOleParentUndoUnit::Open

Abre uma nova unidade de desfazer pai, que se torna parte da pilha de desfazer da unidade que contém.

Requisitos

Requisito Valor
Cliente mínimo com suporte Windows 2000 Professional [somente aplicativos da área de trabalho]
Servidor mínimo com suporte Windows 2000 Server [somente aplicativos da área de trabalho]
Plataforma de Destino Windows
Cabeçalho ocidl.h

Confira também

IOleUndoManager

IOleUndoUnit