Removing setValidator

[CarozoDeQuilmes]

Hi Pritpal, when I try remove a validator from a QLineEdit putting 0 (zero) as parameter, I get the following error message:

Error HBQT/1001 Argument error

Called from QLINEEDIT:SETVALIDATOR(0)

-------------
Documentation from http://doc.qt.nokia.com/4.5/qlineedit.html#setValidator :
void QLineEdit::setValidator ( const QValidator * v )
Sets this line edit to only accept input that the validator, v, will accept. This allows you to place any arbitrary constraints on the text which may be entered.
If v == 0, setValidator() removes the current input validator. The initial setting is to have no input validator (i.e. any input is accepted up to maxLength()).
-------------

Is it possible or I'm wrong?

Thanks in advance
--
CdQ

[francesco perillo]

from TQLineEdit.prg

METHOD QLineEdit:setValidator( ... )
SWITCH PCount()
CASE 1
DO CASE
CASE hb_isObject( hb_pvalue( 1 ) )
RETURN Qt_QLineEdit_setValidator( ::pPtr, ... )
ENDCASE
EXIT
ENDSWITCH
RETURN __hbqt_error()

it wants one parameter of type hbqt....

[Pritpal Bedi]

Hi

Yep.

And it must be known to the hbQT users that
any parameter which be a NULL or 0 is only
at C++ level. From .prg code we must pass
a valid object. To make it null, just pass another
object, i.e., in this context QValidator().

QLINEEDIT:SETVALIDATOR( QValidator() )

Regards
Pritpal Bedi

[Bacco]

I think this should accept 0 also to be conformant with Qt behaviour
and documentation.

"void QLineEdit::setValidator ( const QValidator * v )
Sets this line edit to only accept input that the validator, v, will
accept. This allows you to place any arbitrary constraints on the text
which may be entered.
If v == 0, setValidator() removes the current input validator. The
initial setting is to have no input validator (i.e. any input is
accepted up to maxLength())."

Regards,
Bacco

[Viktor Szakáts]

Or rather NIL, which is Harbour's term for NULL.

Viktor

[Bacco]

> Or rather NIL, which is Harbour's term for NULL.

I agree that sending NIL should remove the validator, but I think we
can stick to Qt accepting 0 also with same effect, so the Qt
documentation still applies and it costs one "If" or "elseif" in the
middle of many others.

Just in case, how is the current planning/goals of migrating the
current HBQt Ifs to C++?

[Viktor Szakáts]

> I agree that sending NIL should remove the validator, but I think we
> can stick to Qt accepting 0 also with same effect, so the Qt
> documentation still applies and it costs one "If" or "elseif" in the
> middle of many others.

Accepting zero means and extra pass of validation, plus
it's not natural in .prg programs for 0 to mean NIL. Also,
what if someone passes 99? Should it RTE? It looks unusual
practice to allow certain types with certain values, so
IMO allowing numeric 0 introduced ambiguity.

If you means moving C++ code directly to .prg, and we assume
that 0 is represented by NULL in correct C++ code, the
easiest is to do '#define NULL NIL' in the .prg and the problem is
solved, without adding strangeness and complication to HBQT code.

> Just in case, how is the current planning/goals of migrating the
> current HBQt Ifs to C++?

I don't know, nobody seemed interested in any remaining
open questions, so apparently it's stalled. Anyhow it remains
one of the important moves to do, before calling HBQT
stable (plus eliminating those raw pointers).

Viktor