Sobre erro: Método não exportado: Win_Prn():NEW()

[rossine]

Olá,

Ocorreu esse erro em um cliente e pelo que entendi seria como se a "classe" Win_Prn() não existisse na memória, mas existe, porque
esse erro apareceu somente 1 vez.

Código: Selecionar todos

    Descrição do Erro: Erro BASE /1004 => Método não exportado: NEW

     [   2] NEW(0)
     [   3] MODELOIMPRESS(2977)

**********************
function ModeloImpress( cPrinter )
**********************
local oPrinter

oPrinter := Win_Prn():New( cPrinter )  <----Erro aqui
...

Akguém já viu esse erro e como tratá-lo ?

Obrigado.

[rossine]

Olá,

Abaixo um exemplo para simular o erro ocorrido, seria como se a "classe" Win_Prn() não fosse uma "Classe".

Código: Selecionar todos

*************
function main
*************

   local oPrinter, cPrinter := Win_PrinterGetDefault()

   cls

   ? cPrinter

   oPrinter := Win_Prn():New( cPrinter )

   ? hb_IsObject( oPrinter )

   oPrinter := NIL

   ? hb_IsObject( oPrinter )

   oPrinter := TESTE():New() // Vai dar erro aqui porque nao é uma classe

   ? hb_IsObject( oPrinter )

return NIL
   
**************
function TESTE
**************

return NIL

[JoséQuintas]

Um outro erro pode causar esse erro.

É a primeira vez?
Veja uma rotina e erros que registre os erros, e também mostre o conteúdo das variáveis em questão.
Fique de olho se vai se repetir.

É possível que mostre o objeto com conteúdo zero.

Vai ser a segunda pessoa com esse problema, o primeiro fui eu.

Se acontecer sempre..... então deve ter uma função win_prn() entrando no lugar da classe.
Veja o que andou trocando.

Coloque hbwin em primeiro lugar na compilação, se é que é harbour ou xharbour, sei lá.

LIBs gostam de atrapalhar.
Achei sobre win_prn(), win32prn() e outras.

[JoséQuintas]

hbmk2 -find *prn


hbwin.hbc (installed):
win_Prn()
xhb.hbc (installed):
Win32Prn()

Sei lá...
No harbour win_prn()
Na compatibilidade com xharbour Win32Prn()

[rossine]

Olá José,

Eu uso o Harbour 3.4 Viktor.

Ocorreu este erro somente 1 vez, pelo que verifiquei.

Vou ver se consigo pegar o erro no Begin ... end begin e tratar ele para ver o que pode ser e tentar chamar a classe novamente pra ver se resolver, mas é muito estranho esse erro ter ocorrido.

Obrigado pelas sugestões,

[JoséQuintas]

Sugestão:

Erro é pra ser mostrado, não pra ser escondido.
Coloque pra mostrar o conteúdo das variáveis.

Código: Selecionar todos

STATIC FUNCTION ArgumentList( e )

   LOCAL xArg, cArguments := ""

   IF ValType( e:Args ) == "A"
      FOR EACH xArg IN e:Args
         cArguments += [(] + Ltrim( Str( xArg:__EnumIndex() ) ) + [) = Tipo: ] + ValType( xArg )
         IF xArg != NIL
            cArguments +=  [ Valor: ] + Alltrim( hb_ValToExp( xArg ) )
         ENDIF
         cArguments += hb_Eol()
      NEXT
   ENDIF

   RETURN cArguments

Isso mostraria as variáveis envolvidas no erro com o conteúdo.

Tive esse problema com 3.4 e 3.2.

O detalhe curioso era mostrar ZERO como conteúdo, e não NIL

Código: Selecionar todos

FUNCTION UmaCor()
   RETURN "W/B"

Eventualmente isso retornava 0 (zero).
Eventualmente mesmo, 1 vez por mes, em um terminal.
Não só essa, outras funções/classes também.
Pra mim pareciam muitos erros, mas era porque vinham de terminais diferentes, de locais diferentes.

Adotei multithread de vez, não resolveu, mas se tornaram mais eventuais ainda, uma vez por mês ou menos, juntando todos os terminais de todos os clientes.
Faz tempo que não vejo esse erro, não mexi nada no aplicativo sobre ele.

O mais engraçado:
Atualmente o EXE é compilado com GTWVG, HWGUI e FIVEWIN, tudo no mesmo EXE.
Agora sim, poderia ser considerado normal qualquer problema desse tipo, mas não dá kkkk.

Atualmente usando mingw 14.2/15.0.
O principal motivo de atualizar mingw foi o EXE 32 bits trabalhar com 4GB de memória, versões anteriores limitavam a 2GB.
E mingw DWARF, porque as LIBs fivewin não trabalham com outra, e não podemos recompilar a LIB, qualquer versão de mingw DWARF serve.
Se isso fez diferença para o problema não sei, acredito que não, porque lembro de ter voltado pra 7.3 pra ver se resolvia.

Também não fez diferença mudar de 3.4 pra 3.2.
Contribuo pra algumas LIBs, e o HBMK2 do 3.4 tem recursos que não estão disponíveis no 3.2.
Comecei a incluir recursos que não estavam disponíveis, e atrapalhando as LIBs.
Só por isso troquei, pra ficar igual todo mundo e poder continuar contribuindo.

No meu caso sempre usei GTWVG, a multithread não era 100% liberada aos clientes, até o problema acontecer.
Depois que liberei, eles não querem que remova kkkk
Talvez interessante comentar o que usa.

[rossine]

Olá José,

Sugestão:

Erro é pra ser mostrado, não pra ser escondido.
Coloque pra mostrar o conteúdo das variáveis.

Sim, já faço assim.

O detalhe curioso era mostrar ZERO como conteúdo, e não NIL

Concordo, mas veja em um erro que simulei aqui, existem várias funções "internas" do "habrour" que retornam "(0)":

Argumentos:

- [NIL]

Ordem de execução:

[ 1] SIM_ERRO(7807) Params=3->(P1=[L]:.T., P2=[N]:2725, P3=[C9]:"CHAVE_NUM") - Variaveis Locais: (:NIL)<-Params_T: (1)
[ 2] (b)INICIA_O_SISTEMA(6473) Params=3->(P1=[C10]:"WENT_DADOS", P2=[N]:2725, P3=[C9]:"CHAVE_NUM") - Variaveis Locais: ()<-Params_T: (0)
[ 3] HBGETLIST:GETDOSETKEY(0) Params=2->(P1={|| ... }, P2=[O:GET]) - Variaveis Locais: ([L]:.F., :NIL)<-Params_T: (2)
[ 4] GETDOSETKEY(0) Params=2->(P1={|| ... }, P2=[O:GET]) - Variaveis Locais: ([O:HBGETLIST])<-Params_T: (1)
[ 8] READMODAL(0) Params=7->(P1=[A1]__itemSetObj( {{{"BBLOCK", {|| ... }}, {"CPICTURE", "@E 99"}, {"BPOSTBLOCK", {|| ... }}, {"BP..."{"CNAME", "CHAVE_NUM"},Variaveis Locais: ([O:HBGETLIST], :NIL)<-Params_T: (2)

Adotei multithread de vez, não resolveu, mas se tornaram mais eventuais ainda, uma vez por mês ou menos, juntando todos os terminais de todos os clientes.
Faz tempo que não vejo esse erro, não mexi nada no aplicativo sobre ele.

Eu não uso MultThread.

Atualmente o EXE é compilado com GTWVG, HWGUI e FIVEWIN, tudo no mesmo EXE.
Atualmente usando mingw 14.2/15.0.
O principal motivo de atualizar mingw foi o EXE 32 bits trabalhar com 4GB de memória, versões anteriores limitavam a 2GB.

Hoje eu uso Harbour 3.4 Viktor, MingW que vem junto com a QT 5.7.1 que é a MingW5.3 2 bits, QTQTC, GTWVG, QT5XHB

Meu .EXE só serve para startar meu sistema que é carregado via vários módulos .HRB.

Obrigado.

[JoséQuintas]

Concordo, mas veja em um erro que simulei aqui, existem várias funções "internas" do "habrour" que retornam "(0)":

Se não me engano isso é número de linha e não retorno.
E funções em LIB não tem número de linha, por isso zero.