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.