Deixar slicer funcional sem possibilidade de remoção pelo menu de contexto

Question

Tenho uma tabela simples com um slicer. Quero deixar o slicer funcional e sem a possibilidade de remoção do slicer pelo menu de contexto. Já tentei varias configurações de proteção da planilha com as propriedades do slicer. O resultado foi: para não ser possível a remoção pelo menu de contexto, o slicer perde a funcionalidade; se ficar funcional, fica possível a seleção do slicer com a possíbilidade de remoção do mesmo. Eventos que poderiam ser usados não são disparados quando atuam sobre o slicer. Assim, mesmo que uma planilha fique protegida, para que o slicer fique funcional, o usuário pode, ocasionalmente, excluir esse filtro. Possíveis soluções alternativas: uso de form com objetos que substituem o uso do slicer; uso de xml, ribbonx. Busco uma solução que possa ser usada em qualquer computador com os recursos nativos do office. Udo o office 2016.

Answer 1

Problema resolvido. Só faltou o EditAltText. Lembrando que meu Office é o 2016.
O código foi esse:
<customUI xmlns="http://schemas.microsoft.com/office/2009/07/customui">

   <commands>

       <!--Disable Slicer right-click menu controls-->          

      <command idMso="SlicerSettings"  enabled="false" />

      <command idMso="SlicerConnectionsMenu"  enabled="false" />

      <command idMso="SlicerDelete"  enabled="false" />

      <command idMso="SlicerRefresh"  enabled="false" />

      <command idMso="ObjectSizeAndPropertiesDialog"  enabled="false" />

      <command idMso="MacroAssign"  enabled="false" />

      <command idMso="ObjectBringToFront"  enabled="false" />

      <command idMso="ObjectSendToBack"  enabled="false" />

      <command idMso="PasteGalleryMini"  enabled="false" />

      <command idMso="SlicerMultiSelect"  enabled="false" />

      <command idMso="SlicerClearFilter"  enabled="false" />

      <command idMso="SlicerDataSourceOrder"  enabled="false" />

      <command idMso="SlicerSortUp"  enabled="false" />

      <command idMso="SlicerSortDown"  enabled="false" />

   </commands>

   <contextMenus>

      <!-- Hide Slicer right-click menu controls--> 

      <contextMenu idMso="ContextMenuSlicer">

         <button idMso="Cut" visible="false" />

         <button idMso="Copy" visible="false" />

      </contextMenu>

  </contextMenus>

</customUI>

Answer 2

Entendo que o VBA faz parte do pacote portanto, se houverr solução através do VBA,resolveria o problema. Inclusive, a exclusão pelo botão Delete já foi resolvida com o evento onkey. Quanto a opção de detectar quando o slicer é selecionado, o problema é em que momento isso seria executado (aceito sugestões) uma vez que não há algo que possa disparar esse evento. Teria que ser um monitoramento constante e não sei como isso seria, considerando que a ação danosa, seleção e remoção se dá pelo mouse e que esse não dispara eventos quando acionado sobre o slicer. Além disso, o custo de desempenho fazendo essa verificação constante há de ser considerado. Entendo que é uma vulnerabilidade deixar a possibilidade do usuário excluir um objeto que compromete o funcionamento da aplicação.

Answer 3

Já testei através de macros mas também não encontrei uma solução adequada,conforme comentário.

Answer 4

Olá Leandro,

No Excel 2016, não existe um método totalmente nativo e sem código que mantenha o slicer funcional e impeça o usuário de removê-lo pelo menu de contexto ou pela tecla Delete.

• Travar o slicer → ele deixa de funcionar.
• Deixar destravado → o usuário ainda pode clicar com o botão direito e removê-lo.
• Slicers não disparam eventos úteis, então não é possível impedir a exclusão usando apenas a proteção normal da planilha.

Depois de revisar a documentação e casos anteriores, apenas duas soluções realmente funcionam:

1. RibbonX / Custom UI XML Desabilitar comandos como SlicerDelete e Cut no menu de contexto do slicer (e opcionalmente ocultar a guia Slicer Tools). Exige edição do XML do arquivo.
2. VBA Detectar quando o slicer está selecionado e bloquear ações de Delete/Cut.

Ambas as soluções funcionam, mas exigem personalização em XML ou uso de macros, ou seja, não atendem ao requisito de “recursos nativos apenas, funcionando em qualquer computador sem configurações extras.”