HWGUI 2.23 b6 ParsePict()

[Fernando queiroz]

// IF oQuery1:Fields( "FRACIO" ):Value = 1
// oDlg:oQTDPRO:ParsePict( '99999.9999', ::ni_qCom )
/// ELSE
// oDlg:oQTDPRO:ParsePict( '99999', ::ni_qCom )
// ENDIF

está dando erro de: INVALID CLASS MEMBER , na B3 estava funcionando normal

[Fernando queiroz]

pelo jeito criaram uma nova classe, olhando na documentação o ParsePict virou HPicture
e tem de instanciar antes de usar.

[Fernando queiroz]

agora o que era ParsePict tem de ser assim:

IF oQuery1:Fields( "FRACIO" ):Value = 1
oDlg:oQTDPRO:oPicture:cPicMask := '99999.9999'
ELSE
oDlg:oQTDPRO:oPicture:cPicMask := '99999'
ENDIF

[JoséQuintas]

Nessas horas, a alternativa é:
A lib dar alternativa de sintaxe, ou o usuário criar alguma coisa.

Aquele meu simulador é uma espécie de exemplo, porque ele não usa nada direto da LIB.
Se a LIB mudar a sintaxe, é só mudar no fonte LIB_HWGUI.PRG por exemplo.

Tem outra vantagem nisso:
Às vezes o #include troca o fonte pra um fonte muito maior, o uso de função reduz isso.
É pra se pensar.

Por exemplo:

Código: Selecionar todos

IF oQuery1:Fields("FRACIO"):Value == 1
   TextDefinePicture( oDlg:oQtdPro, "99999" )
ELSE
   TextDefinePicture( oDlg:oQtdPro, "99999.9999"
ENDIF
...
FUNCTION TextDefinePicture( oControl, cPicture )
   oControl:oPicture:cPicMask := cPicture
   RETURN Nil

Ou temporário, enquanto estão sendo feitas mudanças, ou até definitivo.

Até pensei em criar classe pra essas coisas, mas acho que nem compensa, assim fica "bonitinho" e se escrever errado dá erro na compilação, ao contrário de classes.

Aproveitando:
Naquele simulador, dava pra ter a alternativa dos controles HDRAWN.
É um interessante playground de testes.
São os pontos chaves do aplicativo: label, textbox, browse, e tab