O erro foi na geração do PDF do Danfe.
E na formatação do texto de informações adicionais.
Isso não costuma ter tanto texto assim.
Seguindo o erro:
Called from (b)RUNMODULE(120) in jpa.prg
Called from DOPRG(156) in jpa.prg
Called from DO(0) in ../../../memoedit.prg
Acima o menu chama a rotina, com certeza memoedit não tem nada a ver
Called from PDFEZIPXML(52) in pdfezipxml.prg
Called from GERADADOS(119) in pdfezipxml.prg
Called from XMLPDFCLASS:GERAPDF(47) in ze_spedxmllist.prg
Acima ok, a rotina que foi chamada, que cria ZIP de XML + Danfe
Called from HBNFEDAGERAL:TOPDF(180) in source\ze_sefazDadfe.prg
Called from HBNFEDANFE:TOPDF(206) in source\ze_sefazDaNfe.prg
Called from HBNFEDANFE:GERAPDF(310) in source\ze_sefazDaNfe.prg
Called from HBNFEDANFE:CALCULALAYOUT(983) in source\ze_sefazDaNfe.prg
Called from HBNFEDANFE:FORMATAMEMO(103) in source\ze_sefazDadfe.prg
Called from SUBSTR(0) in source\winapi\hprinter.prg
Acima, até ia bem na criação do PDF, até que chegou na rotina FormataMemo(), que pega o texto de informações adicionais (ou outro) pra calcular quantidade de linhas.
De repente, mostra que deu erro em Substr() e fonte hprinter da hwgui.
Não existe essa função lá.
E num XML não tem tanto texto que cause sobrecarga de memória.
Código: Selecionar todos
METHOD FormataMemo( cMemo, nLarguraPDF ) CLASS hbNFeDaGeral
LOCAL cNovoTexto := "", cTexto, nPos, nCont
FOR nCont = 1 TO MLCount( cMemo, 10000 )
cTexto := MemoLine( cMemo, 10000, nCont )
DO WHILE .T.
nPos := HPDF_Page_MeasureText( ::oPDFPage, cTexto, nLarguraPDF, .T. )
IF nPos == 0
nPos := HPDF_Page_MeasureText( ::oPDFPage, cTexto, nLarguraPDF, .F. )
nPos := Max( nPos, 2 )
ENDIF
cNovoTexto += Substr( cTexto, 1, nPos ) + Chr(13) + Chr(10)
cTexto := AllTrim( Substr( cTexto, nPos + 1 ) )
IF Len( cTexto ) == 0
EXIT
ENDIF
ENDDO
NEXT
IF Right( cNovoTexto, 2 ) == Chr(13) + Chr(10)
cNovoTexto := Substr( cNovoTexto, 1, Len( cNovoTexto ) - 2 )
ENDIF
RETURN cNovoTexto
A rotina pega UMA LINHA por vez, pra ver se cabe.
Ou separa a parte que cabe, ou usa o tamanho máximo que couber.
Conforme testa, já remove a parte que vai ficar, e vai acumulando na string geral.
De um jeito ou de outro a string vai ficando menor.
E o resultado geral vai ser uma string um pouco maior que a original.
Digamos que uma string de 4k pode ficar com 4k1
Não faz sentido estourar memória nessa rotina, e muito menos entrar hwgui no meio.
Também não tem a ver com estouro de PDF, porque nesse ponto é apenas cálculo antes de começar o PDF.
Sei lá... deixar pra lá, e aguardar se vai acontecer de novo.
E tentar entrar em contato assim que aparecer email de erro.
Até agora eles nem ligaram pra falar do erro, deve ter funcionado depois, ou nem perceberam que deu erro.
