Bonjour,

Je travail sur un proget Qt est mon problème est le suivant:

J'essaie désespérément de trouver une solution pour limiter le nombre de caractère a saisir dans un  "QInputDialog::getText"

Avec un QLineEdit, on utilise la méthode maxLenght, mais la pour "Qt QInputDialog" je sèche!

void TW_S_Rck::renameTextBank()
    {
        bool ok = false;
        int index = listeDeroulanteBank->currentIndex();
        QString buff = nameBank[index];

        nameBank[index] = QInputDialog::getText(this,"Rename Bank","",QLineEdit::Normal, QString("%1").arg(nameBank[index]), &ok);

        if(ok && !nameBank[index].isEmpty()){listeDeroulanteBank->setItemText(index,nameBank[index]);}
        else{nameBank[index] = buff;}
    }

Merci d'avance pour votre aide.

Cordialement, Antoine

Salut,

On dirait que tu va devoir implémenter ta propre TextInputDialog à partir de QDialog

Salut,

On ne peut pas limiter le nombre de caractère saisie avec Qt, un éditeur si complet ne propose pas cela?

Quand je crée un QLineEdit, il suffit de faire:

{
QLineEdit *line = new QLineEdit();
line->setMaxLength(16);
}

Il doit bien y avoir un moyen?

Merci pour vos réponses?

Qt est une bibliothèque, pas un éditeur

Ben tu viens de l'écrire ton moyen, mets une QLineEdit dans une QDialog, avec les autres fonctionnalités qui te sont utile et pis c'est réglé

Les fonctionnalités de la QInputDialog telles qu'indiquée dans la doc ne le permette en tout cas pas.
Je comprends pas trop pourquoi ils ont décidé de faire une seule classe pour gérer la saisie d'une valeur sous différents types.

Finalement, j'ai opté pour ceci:

void
    {
        int index = listeDeroulanteBank->currentIndex();
        QString buff = nameBank[index];

        QInputDialog *dialog = new QInputDialog(this);
            dialog->setInputMode(QInputDialog::TextInput);
            dialog->setWindowTitle("Rename Bank");
            dialog->setLabelText("");
            dialog->setTextValue(nameBank[index]);

            lineEdit = dialog->findChild<QLineEdit *>();
            lineEdit->setMaxLength(16+1);

            connect(lineEdit, SIGNAL(cursorPositionChanged(int,int)), this, SLOT(messageBoxInfoLenghtName(int,int)));

            if (dialog->exec() == QDialog::Accepted)
            {
                nameBank[index] =  dialog->textValue();
                listeDeroulanteBank->setItemText(index,nameBank[index]);
            }
    }

Et ca marche nikel! 

Merci quand même de vos réponse

Cordialement, Antoine

romantik a écrit:

Je comprends pas trop pourquoi ils ont décidé de faire une seule classe pour gérer la saisie d'une valeur sous différents types.

Parce que le but est vraiment de permettre au développeur qui "ne veut pas se casser la tête" de créer une boite de dialogue, contenant n'importe quel type de widget d'input, selon un shéma bien déterminé car ayant le label, le widget en question et les différents boutons à des endroits bien précis

C'est, finalement, une classe "aux trois quarts terminées" qui offre au développeur la possibilité d'adapter ce qui manque à ses propres besoins, comme on en croise tant et plus dans Qt

Ce qui importe avant tout ici, c'est qu'il s'agit d'une boite de dialogue, affichée de manière séparée de ta fenêtre principale (en mode "modal"), avec son titre, ses boutons de fermeture et d’agrandissement rapide et ses éléments utiles à des positions "clés" ;).  Il ne faut pas chercher plus loin

Certes, mais pourquoi faire une seule classe qui gère le cas int, le cas double et le cas string et qui switch les widgets avec des setVisible en fonction d'un enum plutôt que de faire une classe par cas d'utilisation (par héritage ou template). le but de cette classe est de récupérer une seule valeur, et elle ne change pas de type pendant sa saisie (normalement) ni généralement de méthode de saisie.

ça éviterait de se retrouver avec des setRange setMax setMin alors qu'on veut manipuler une string ou du setEchoMode quand on manipule des nombres. Et les classes étant plus allégés en terme de fonctionnalité, ils pourrait rajouter des fonctions comme ce setMaxLength dans le cas du string sans avoir un gros pathé de fonctions disponible parce que celles qui n'ont pas de sens auront été déporté.

EDIT: bon petit hack valide, je ferais juste le commentaire à propos de la syntaxe du connect, depuis Qt5 une nouvelle est apparue apportant son lot d'avantage (pour, je trouve, finalement assez peu d'inconvénient)

-
Edité par romantik 11 octobre 2019 à 9:56:46

Je comprend ton point de vue, et je suis tout à fait d'accord avec toi, mais il faut te dire qu'une multitude de classes plus "précises" viendraient avec leur propre inconvénient, parce que tu te retrouverait avec un QIntInputDialog, un QFloatInputDialog, et toute la clique.

Au final, ce que tu aurais gagné en interface, tu l'aurais perdu en nombre de classes spécifiques

Et puis, il faut aussi chercher dans les raisons pour lesquelles cette classe existent.

Cette classe n'est en définitive destinée au développeur dans le cas -- récurrent -- où il se rend compte qu'il doit demander une entrée à l'utilisateur sans ajouter de widget à la fenêtre principale.  Le plus souvent, ce sera parce qu'il a besoin de l'input en question, qu'il veut s'assurer "vite fait" que cela fonctionnera, sans encore "perdre du temps" à développer une "boite de dialogue de plus".

L'un dans l'autre, cette classe ne va être utilisée que lors d'un POC (Proof Of Concept) ou lors du prototypage de IHM pour que le système puisse fonctionner, en attendant que l'ergonome vienne y mettre son grain de sel en expliquant comment il souhaiterait que cet input soit présentée à l'utilisateur.

C'est donc -- très souvent -- une "solution temporaire" mise en place en attendant de mettre en place une solution plus cohérente par rapport au reste de l'application, parce que si l'ergonome a quelque chose à dire sur une boite de dialogue, ce sera bien sur celle-là ;).

Maintenant, rien ne t'empêche de l'utiliser comme solution "provisoirement définitive" si tu le souhaite, mais tu reste alors soumis aux "imperfections" d'une classe développée dans un but strictement générique

Oui ça me va comme explication j'avais pas réfléchi comme ça

merci