J'ai dû modifier 3 champs reliés à des rubriques, que j'ai remis ensuite
dans leurs états initiaux. Tout semble avoir bien fonctionné.
Sauf qu'en exécution j'obtiens une rubrique bloquée (sur les 3 modifiés)
mais pour 2 enregistrements seulement sur le lot - qui empêche toute saisie
dans ce champ.
Ce projet ne contient aucun code de blocage nulle part.
Ok, thanks to tell. Let's try again ;-) ...pour une version simplifiée.
Je ne sais pas trop ce que j'ai pu faire durant le développement mais en testant mon application je me suis rendu compte que j'ai un champ rubrique qui est bloqué - c'est à dire qu'aucune saisie n'est possible dans ce champ.
Seulement 2 enregistrements (two records) du fichier sont affectés. Tous les autres fonctionnent.
Ce projet ne contient aucun code de blocage nulle part.
Quelqu'un a une idée de ce qui s'est passé?
Comment on fait pour "réparer" cette situation?
Merci à l'avance pour tout piste.
Réal Phil
Ok, thanks to tell. Let's try again ;-) ...pour une version
simplifiée.
Je ne sais pas trop ce que j'ai pu faire durant le développement mais
en testant mon application je me suis rendu compte que j'ai un champ
rubrique qui est bloqué - c'est à dire qu'aucune saisie n'est
possible dans ce champ.
Seulement 2 enregistrements (two records) du fichier sont affectés.
Tous les autres fonctionnent.
Ce projet ne contient aucun code de blocage nulle part.
Ok, thanks to tell. Let's try again ;-) ...pour une version simplifiée.
Je ne sais pas trop ce que j'ai pu faire durant le développement mais en testant mon application je me suis rendu compte que j'ai un champ rubrique qui est bloqué - c'est à dire qu'aucune saisie n'est possible dans ce champ.
Seulement 2 enregistrements (two records) du fichier sont affectés. Tous les autres fonctionnent.
Ce projet ne contient aucun code de blocage nulle part.
Quelqu'un a une idée de ce qui s'est passé?
Comment on fait pour "réparer" cette situation?
Merci à l'avance pour tout piste.
Réal Phil
mat
Salut Réal,
La seule occasion où j'avais un problème pareil, c'était avec WD5.5: des champs numériques et les polices larges de Windows. Aucune saisie n'a été possible.
Je suppose tu as vérifié si les valeurs des deux enregistrements bloquées correspondent à un masque éventuel de saisie?
Salutations Mat
Salut Réal,
La seule occasion où j'avais un problème pareil, c'était avec WD5.5: des
champs numériques et les polices larges de Windows. Aucune saisie n'a
été possible.
Je suppose tu as vérifié si les valeurs des deux enregistrements
bloquées correspondent à un masque éventuel de saisie?
La seule occasion où j'avais un problème pareil, c'était avec WD5.5: des champs numériques et les polices larges de Windows. Aucune saisie n'a été possible.
Je suppose tu as vérifié si les valeurs des deux enregistrements bloquées correspondent à un masque éventuel de saisie?
Salutations Mat
Real Phil
Salut Mat,
EURÉKA! J'ai trouvé! - That was a tricky one.
Je prend le temps d'expliquer au cas où ça serait utile à quelqu'un d'autre.
Explications: Depuis l'analyse, j'efface les champs Rem2, Rem3 et je modifie Rem1 qui passe de 50 à 150 caractères. Je change ensuite le champ de saisie Rem1 dans sa fenêtre à une saisie multilignes.
Je fais ensuite quelques tests et rempli le champ Rem1 au complet (à 150 caractères sur plusieurs lignes). On sait que chaque changement de ligne introduit un RC (Retour de chariot) invisible dans le texte. Je fais des tests dans 2 dossiers (enregistrements).
Je décide ensuite de tout remettre comme avant et je réduit le champ de 150 caractères à 50 caractères depuis l'analyse. Windev conserve les données du champ Rem1 en tronquant, mais conserve les RC invisibles (sans que je le sache).
Donc, par la suite, ce champ (qui n'est plus un champ de saisie multilignes) refuse d'accepter l'ajout de nouveaux caractères parce qu'en réalité cette rubrique contient déjà 50 caractères même si je n'en vois que 4 ou 5 dans le champ à cause des RC invisibles.
Une fois cela compris, il m'a suffit d'ajuster cela avec WDMap et tout est réglé.
Ce n'était finalement pas un problème de blocage dans le sens ou je le pensais. Mais surtout, et c'est très important, j'ai compris ce qui s'est passé.
Mes salutations et Merci beaucoup.
Réal Phil ----------------------------------------------
"mat" a écrit dans le message de news:44234950$
Salut Réal,
La seule occasion où j'avais un problème pareil, c'était avec WD5.5: des champs numériques et les polices larges de Windows. Aucune saisie n'a été possible.
Je suppose tu as vérifié si les valeurs des deux enregistrements bloquées correspondent à un masque éventuel de saisie?
Salutations Mat
Salut Mat,
EURÉKA! J'ai trouvé! - That was a tricky one.
Je prend le temps d'expliquer au cas où ça serait utile à quelqu'un d'autre.
Explications:
Depuis l'analyse, j'efface les champs Rem2, Rem3 et je modifie Rem1 qui
passe de 50 à 150 caractères.
Je change ensuite le champ de saisie Rem1 dans sa fenêtre à une saisie
multilignes.
Je fais ensuite quelques tests et rempli le champ Rem1 au complet (à 150
caractères sur plusieurs lignes).
On sait que chaque changement de ligne introduit un RC (Retour de chariot)
invisible dans le texte.
Je fais des tests dans 2 dossiers (enregistrements).
Je décide ensuite de tout remettre comme avant et je réduit le champ de 150
caractères à 50 caractères depuis l'analyse.
Windev conserve les données du champ Rem1 en tronquant, mais conserve les RC
invisibles (sans que je le sache).
Donc, par la suite, ce champ (qui n'est plus un champ de saisie multilignes)
refuse d'accepter l'ajout de nouveaux caractères parce qu'en réalité cette
rubrique contient déjà 50 caractères même si je n'en vois que 4 ou 5 dans le
champ à cause des RC invisibles.
Une fois cela compris, il m'a suffit d'ajuster cela avec WDMap et tout est
réglé.
Ce n'était finalement pas un problème de blocage dans le sens ou je le
pensais.
Mais surtout, et c'est très important, j'ai compris ce qui s'est passé.
Mes salutations et Merci beaucoup.
Réal Phil
----------------------------------------------
"mat" <NoSPAM-mnobs@windasso.org> a écrit dans le message de
news:44234950$1_3@news.bluewin.ch...
Salut Réal,
La seule occasion où j'avais un problème pareil, c'était avec WD5.5: des
champs numériques et les polices larges de Windows. Aucune saisie n'a
été possible.
Je suppose tu as vérifié si les valeurs des deux enregistrements
bloquées correspondent à un masque éventuel de saisie?
Je prend le temps d'expliquer au cas où ça serait utile à quelqu'un d'autre.
Explications: Depuis l'analyse, j'efface les champs Rem2, Rem3 et je modifie Rem1 qui passe de 50 à 150 caractères. Je change ensuite le champ de saisie Rem1 dans sa fenêtre à une saisie multilignes.
Je fais ensuite quelques tests et rempli le champ Rem1 au complet (à 150 caractères sur plusieurs lignes). On sait que chaque changement de ligne introduit un RC (Retour de chariot) invisible dans le texte. Je fais des tests dans 2 dossiers (enregistrements).
Je décide ensuite de tout remettre comme avant et je réduit le champ de 150 caractères à 50 caractères depuis l'analyse. Windev conserve les données du champ Rem1 en tronquant, mais conserve les RC invisibles (sans que je le sache).
Donc, par la suite, ce champ (qui n'est plus un champ de saisie multilignes) refuse d'accepter l'ajout de nouveaux caractères parce qu'en réalité cette rubrique contient déjà 50 caractères même si je n'en vois que 4 ou 5 dans le champ à cause des RC invisibles.
Une fois cela compris, il m'a suffit d'ajuster cela avec WDMap et tout est réglé.
Ce n'était finalement pas un problème de blocage dans le sens ou je le pensais. Mais surtout, et c'est très important, j'ai compris ce qui s'est passé.
Mes salutations et Merci beaucoup.
Réal Phil ----------------------------------------------
"mat" a écrit dans le message de news:44234950$
Salut Réal,
La seule occasion où j'avais un problème pareil, c'était avec WD5.5: des champs numériques et les polices larges de Windows. Aucune saisie n'a été possible.
Je suppose tu as vérifié si les valeurs des deux enregistrements bloquées correspondent à un masque éventuel de saisie?
