Problème avec "NUMLOCK = .T." en entrée de textbox sous VFP9

Signaler
Messages postés
9
Date d'inscription
mercredi 19 août 2009
Statut
Membre
Dernière intervention
12 janvier 2010
-
Messages postés
9
Date d'inscription
mercredi 19 août 2009
Statut
Membre
Dernière intervention
12 janvier 2010
-
Bonjour,

NB : cette question a déjà été posée dans une autre rubrique, mais pas forcément à la bonne place, d'où une absence de réponse ; j'essaie donc ici ... :

Je suis amateur, et je tente de migrer depuis FOXPRO-DOS vers VPF9.

Sous VFP9, - le 'FORM' étant créé normalement - j'ai un problème à l'entrée dans une textbox (en fait dans les textboxs) dans le 'Gofocus' ou 'When' duquel figure un "NUMLOCK = .T." ( : le pavé numérique est forcé sur le mode logiciel, de façon à saisir des valeurs numériques ...) ; à l'entrée de la dite textbox le curseur s'agite dans tous les sens : part en fin de cette textbox - s'y retrouve raccourci en hauteur !!?? - ; ensuite, repasse dans le champ (textbox) précédant, pour enfin venir à sa place, soit en début de la textbox de saisie en cours, après tout ce mic-mac ... ; ceci pour saisir des valeurs de date, ou des valeurs numériques 'brutes' (poids, taille, ...)

C'est assez déroutant, pour ne pas dire désagréable, et sans doute consommateur de ressources ...

A noter que j'ai le MEME problème - curseur épileptique sous VFP9 ; OS : Win XP SP2 - avec le "même" écran mais généré sous FOXPRO-DOS, donc, lors de l'exécution d'un fichier SPR/SPX (avec "NUMLOCK = .T." dans le 'When') ; cela ne vient donc pas intrinsèquement du formulaire créé sous VFP9 ...

Qu'en pensez-vous

Remerciements,

JAIMES

11 réponses

Messages postés
381
Date d'inscription
vendredi 15 octobre 2004
Statut
Membre
Dernière intervention
24 octobre 2013
2
N'utilise pas le NUMLOCK = .t.
Il semble que tu veux controler les majuscules dans un champ texte.
Dans la propriété Format du textbox met un !.
Tout va sortir en majuscule sans déranger les autres champs.
Si tu veux qu'un champ accepte seulement des valeures numériques, met un R dans la propriété format et dans la propriété InputMask met '9999.99' ou le format que tu veux accepter. pas de guillemets.


Mike Gagnon
Messages postés
9
Date d'inscription
mercredi 19 août 2009
Statut
Membre
Dernière intervention
12 janvier 2010

Bonjour,

Oui, sauf que si je me sers du pavé numérique, celui-ci n'étant pas activé, les touches correspondront aux flèches ; au mieux je me déplace à droite ou à gauche dans la 'textbox' (flèche droite ou gauche) , au pire je quitte la 'textbox' (flèche vers le haut, vers le bas, et autres touches du pavé numérique) et poursuis ma saisie (ou plus généralement mon périple) à un mauvais emplacement, tout cela en confiance ... ! et ceci, quelque soit le masque de saisie programmé ('9999.99', ... ) qui interdit certaines entrées, mais PAS les déplacements ...

L'activation du pavé numérique est donc indispensable, et si on peut le réaliser sur le mode logiciel, à priori prévu pour (!?), ça serait bien, car j'ai pris de mauvaises habitudes sous FOXPRO-DOS ...

Donc nous voilà au point de départ ; je te remercie pour ta contribution, et ne manquerai pas de vous informer si une piste ad hoc se présentait.

Remerciements,

JAIMES
Messages postés
828
Date d'inscription
mardi 5 octobre 2004
Statut
Membre
Dernière intervention
7 mai 2013
1
Bonjour,

[list]
[*] la syntaxe correcte est =NUMLOCK(.T.)
[*] ton erreur de syntaxe n'explique pas en soi le comportement erratique de ton curseur, regarde du coté de ta gestion d'erreur, vérifie en désactivant les thèmes avec la propriété Themes de ce textbox
[*] essaies de na pas utiliser l'évenement WHEN, qui n'est là que pour la rétrocompatibilité, mais plutot GotFocus si tu veux agir quand le controle prend le focus
/list
Messages postés
9
Date d'inscription
mercredi 19 août 2009
Statut
Membre
Dernière intervention
12 janvier 2010

Bonjour MichelAtoutFox,

Merci pour ta réponse ...

OK pour la syntaxe (boulette à l'écriture du message ...)

J'étudie tout cela ( 'gestion d'erreur' , 'propriété Themes de ce textbox ' ... ?? ) , et je te tiens au courant.

Bonne journée

JAIMES
Messages postés
9
Date d'inscription
mercredi 19 août 2009
Statut
Membre
Dernière intervention
12 janvier 2010

Bonjour,

J'ai essayé de voir aux 'gestion d'erreur' et autres 'propriété Themes de ce textbox ' ... j'avoue que je patauge un peu ...

Aurai-tu quelques pistes ?

Par ailleurs, le fait que :

<< A noter que j'ai le MEME problème - curseur épileptique sous VFP9 ; OS : Win XP SP2 - avec le "même" écran mais généré sous FOXPRO-DOS, donc, lors de l'exécution d'un fichier SPR/SPX (avec "NUMLOCK = .T." dans le 'When') ; cela ne vient donc pas intrinsèquement du formulaire créé sous VFP9 ... >>

... semble indiquer une 'bizarrerie' de haut niveau genre "écran Foxpro" ??

Sans te mettre à contribution, as-tu rencontré ce problème ; pourrais-tu le tester ? ; en plus, je te demande ça pendant le week-end !!

Bon, voilà, tu sais tout ; j'attends de pouvoir résoudre ce problème, avant de convertir mon Appli.

Remerciements, et à bientôt,


JAIMES
Messages postés
828
Date d'inscription
mardi 5 octobre 2004
Statut
Membre
Dernière intervention
7 mai 2013
1
Une petite recherche dans l'aide, sur le mot Themes, t'aurait permis de trouver tout seul, mais voilà les réponses:

Controls defined using @...GET or @...SAY and similar @... commands are not compatible with Windows XP Themes. Therefore, when running programs written with FoxPro 2.x on Windows XP or later, you should set the _SCREEN.Themes
property to False (.F.); otherwise, the controls on the forms disappear.

et aussi
SYS(2700) - Enables Windows XP Themes


Enables or disables Windows XP Themes support in Visual FoxPro entirely.
SYS(2700 [, nValue ])

nValue Setting
0 Disables Themes support.
1 Enables Themes support. (Default)


Est-ce que tu utilises de la syntaxe de type @... ou bien ton form est-il 100% en mode objet?
Peux-tu faire un test en créant un form avec un des assistants de VFP9? tu le lanceras pour tester son bon fonctionnement, puis tu rajouteras un textbox, en mettant du code dans sa méthode gotfocus, et tu relanceras le test.
Messages postés
9
Date d'inscription
mercredi 19 août 2009
Statut
Membre
Dernière intervention
12 janvier 2010

Bonjour,

J'ai découvert ça ce week-end (_SCREEN.Themes , SYS(2700, 0), textbox.theme = .F.) : ça ne marche pas ...

En synthèse, sous VFP9, (pour le problème évoqué supra ...) ni du code de type '@...' ni du 'FORM' pur et dur (100% en mode objet VFP9) ne passe ...

Plus surprenant, un 'FORM' - pur - créé en VFP6 (VFPsix !!) se comporte comme attendu sous Windows 98 (DOS 7) mais présente le même "swinging curseur" sous windows XP ; y compris avec le thème de XP basculé en mode "Windows Classique" ; à noter que, sauf erreur, la notion de 'thème' n'apparaît pas dans cette version ; ce qui est logique (autre époque !?)

Pour tester le 'bug' :

* créér dans un FORM, (>=) 3 textboxES
* mettre dans le GotFocus de chacun " =NUMLOCK(.T.) "
* ... et dans le LostFocus de chacun "=NUMLOCK(.F.) "

Ca mérite d'être vu, ne serait-ce qu'au titre de sa culture générale ...

A bientôt, pour de nouvelles avancées ?

Remerciements,

JAIMES
Messages postés
828
Date d'inscription
mardi 5 octobre 2004
Statut
Membre
Dernière intervention
7 mai 2013
1
En effet, il y a bien un problème.
Il semble que ce soit le passage de =NUMLOCK(.F.) à =NUMLOCK(.T.) qui perturbe le positionnement du curseur dans la couche visuelle. Mais je ne vois pas pourquoi

Désolé de ne pas pouvoir t'apporter d'aide sur cette question...
Messages postés
9
Date d'inscription
mercredi 19 août 2009
Statut
Membre
Dernière intervention
12 janvier 2010

Merci encore pour ta contribution,

A plus ; je vous tiens au courant si j'ai du nouveau ...

JAIMES
Messages postés
381
Date d'inscription
vendredi 15 octobre 2004
Statut
Membre
Dernière intervention
24 octobre 2013
2
La raison pour laquelle j'ai mentionné de ne pas utliser NUMLOCK.


Mike Gagnon
Messages postés
9
Date d'inscription
mercredi 19 août 2009
Statut
Membre
Dernière intervention
12 janvier 2010

Merci à toi, également ... Je continue néanmois à chercher ; XP semble ne pas faire bon ménage avec les commandes passées au pavé numérique ; moins bon ménage que le DOS en tout cas ...

A plus

JAIMES