Eu não acho que seus subs CleanUsedRange() e CleanFileName() estejam realmente excluindo (completamente) suas fórmulas Vlook (quaisquer que sejam), mas suas fórmulas podem ser destruídas por CleanFileName() , pois remove certos caracteres.
Para explicar por que seu código atual cria problemas, vamos analisar algumas linhas:
Em CommandButton2_Click() , você chama CleanUsedRange ws.UsedRange . Aqui, ws refere-se a "Sheet1" e UsedRange representa o intervalo usado de ws , significando o intervalo de células entre a primeira e a última colunas (inclusive) e a primeira e última linhas (inclusive) que têm (ou conteúdo) (por exemplo, dados ou fórmulas).
Em CleanUsedRange() , você está percorrendo todas as células (cada linha e coluna) do intervalo usado (passado como ur As Range ) e chamando CleanFileName() no conteúdo de todas essas células. Esta função ( CleanUsedRange() ) é a principal razão para a destruição de suas fórmulas, porque ela passa as fórmulas em sua planilha como strings para a função CleanFileName() .
Em CleanFileName() , o argumento passado é verificado para determinados caracteres que são inválidos em nomes de arquivos. O argumento modificado é então retornado como resultado da função.
Correção: não passe todo o intervalo usado para CleanUsedRange() e CleanFileName() . Na verdade, você pode eliminar o CleanUsedRange() sub integralmente.
Passa apenas uma célula (C10?) que contém o nome do arquivo que pode precisar de limpeza, para CleanFileName() .
IOW, em CommandButton2_Click() replace
CleanUsedRange ws.UsedRange
com
Range("C10") = CleanFileName(Range("C10")).
(Assumindo que a célula C10 contém o nome do arquivo a ser usado.)
Editar sobre "pontos de interrogação em caixa"
Para o problema com os "pontos de interrogação encaixotados", descobri que qualquer caractere com código menor que 32 produz o problema em um arquivo .pdf produzido pelo Excel (no meu Excel, somente Chr (12) é mostrado como "ponto de interrogação encaixotado"). É claro que existem dois caracteres entre cada campo, e os prováveis são um par de "Carriage Return - Line Feed" (CRLF), mas somente você pode confirmar isso, pois você ainda não forneceu essa informação.
Quando você lê os valores da string txt , usa este código:
.Range(d(k)).Value2 = Trim$(Mid$(txt, found, sz - found - 1))
Alterando para
.Range(d(k)).Value2 = Trim$(Mid$(txt, found, sz - found - 2))
como sugeri em um comentário, cura o problema.
Editar sobre erro 7.8.2018
Primeiro, obrigado pelo arquivo. Isso claramente confirma minha suspeita sobre um par CRLF entre os campos no arquivo. Também confirma que o comprimento dos dados que extraímos com a função Mid$() deve ser reduzido em 2 em vez de 1.
Eu não consegui reproduzir o erro que você experimentou com a modificação anterior, mas na verdade ainda há um erro com o último campo ("Datado"). Possivelmente isso é levantado como um erro em seu ambiente, não é no meu, mas o ano é erroneamente mostrado como 201.
O erro com o último campo é que a variável sz precisa crescer para compensar a alteração anterior que fizemos na extração de dados (alteramos sz - found - 1 para sz - found - 2 ).
Então, mude
Else sz = txtLen + 2
para
Else sz = txtLen + 3
Naturalmente, isso só ajuda se o erro ocorrer ao ler o último campo ("Datado") do arquivo. Se isso não ajudar, depure e deixe-me saber qual campo você está lendo e quais valores as variáveis k , found e sz têm quando falhar. Informe também sobre quaisquer mensagens pop-up que possam aparecer.