Impossible de focaliser une fenêtre désactivée ou invisible
Résolu
Guillemouze
Messages postés
991
Date d'inscription
samedi 25 octobre 2003
Statut
Membre
Dernière intervention
29 août 2013
-
15 nov. 2006 à 12:10
fredelem Messages postés 136 Date d'inscription dimanche 29 octobre 2006 Statut Membre Dernière intervention 1 décembre 2022 - 5 mars 2009 à 21:15
fredelem Messages postés 136 Date d'inscription dimanche 29 octobre 2006 Statut Membre Dernière intervention 1 décembre 2022 - 5 mars 2009 à 21:15
A voir également:
- Erreur fonctionnalités relationnelles désactivées
- Erreur d'execution 9 ✓ - Forum Visual Basic 6
- Erreur d'exécution 424 ✓ - Forum Visual Basic
- Erreur 424 "Objet requis" ✓ - Forum Visual Basic 6
- Message d'erreur 424: objet requis ✓ - Forum VBA Office (Excel, Word ...)
- Erreure d'execution 9 ✓ - Forum Visual Basic 6
26 réponses
Cirec
Messages postés
3833
Date d'inscription
vendredi 23 juillet 2004
Statut
Modérateur
Dernière intervention
18 septembre 2022
50
17 nov. 2006 à 18:12
17 nov. 2006 à 18:12
Oui sur ce cas de figure
mais je viens de voir que je n'aurais pas du écourter le code ...
puisque chez moi le code continue et n'a pas le droit de s'executer au delà du Try Finally End; si Data = 0
donc le problème reste posé
@+
Cirec
mais je viens de voir que je n'aurais pas du écourter le code ...
puisque chez moi le code continue et n'a pas le droit de s'executer au delà du Try Finally End; si Data = 0
donc le problème reste posé
@+
Cirec
Cirec
Messages postés
3833
Date d'inscription
vendredi 23 juillet 2004
Statut
Modérateur
Dernière intervention
18 septembre 2022
50
18 nov. 2006 à 13:10
18 nov. 2006 à 13:10
Alors ... pas d'idées !
Je te rassure, elles existent mais :
1 elles ralongent le code
2 réduisent sa lisibilité
3 donne un aspect "crade" d'ammateur au code
Autant reprendre le Basic si c'est pour faire la même chose
tu dis : "ce que je leur reproche, c'est d'avoir un impact trop important sur le code comparé a leur "visibilité""
en fait la lisibilité où visibilité ne change pas (enfin pour moi)
que je trouve :
If Condition Then
Begin
End;
Où :
If Condition Then Exit;
Dans les deux cas je m'arrête sur le teste de condition et forcement sur ce qui suit (Begin/End où Exit)
@+
Cirec
Je te rassure, elles existent mais :
1 elles ralongent le code
2 réduisent sa lisibilité
3 donne un aspect "crade" d'ammateur au code
Autant reprendre le Basic si c'est pour faire la même chose
tu dis : "ce que je leur reproche, c'est d'avoir un impact trop important sur le code comparé a leur "visibilité""
en fait la lisibilité où visibilité ne change pas (enfin pour moi)
que je trouve :
If Condition Then
Begin
End;
Où :
If Condition Then Exit;
Dans les deux cas je m'arrête sur le teste de condition et forcement sur ce qui suit (Begin/End où Exit)
@+
Cirec
Guillemouze
Messages postés
991
Date d'inscription
samedi 25 octobre 2003
Statut
Membre
Dernière intervention
29 août 2013
6
18 nov. 2006 à 14:04
18 nov. 2006 à 14:04
pour l'histoire de la lisibilité, c'est, comme je le disais, surtout pour parcourir les fonctions.
par exemple quand tu regarde rapidement une fonction, et que tu as un break ou un exit en plein mileu, tu ne vois pas forcement sans regarder le code plus en detail.
mais je le repete, ce n'est qu'un avis personnel.
par exemple quand tu regarde rapidement une fonction, et que tu as un break ou un exit en plein mileu, tu ne vois pas forcement sans regarder le code plus en detail.
mais je le repete, ce n'est qu'un avis personnel.
cs_Loda
Messages postés
814
Date d'inscription
vendredi 3 novembre 2000
Statut
Membre
Dernière intervention
30 juillet 2009
3
19 nov. 2006 à 02:30
19 nov. 2006 à 02:30
@Guillemouze:
"'un fonction de 200 lignes" hum, ça c'est contre ma religion! Car une fct de plus d'une centaine de ligne, ça devient dure a débogguer et c'est une source de problème/bug.
"pour ne pas utiliser un while" hum, un break peut ce mettre au milieux de la boucle. pas un while.
disons, que c'est souvent pratique de pouvoir gérer des cas limite à l'aide d'un exit, plustot que de faire des if begin-end partout. (j'ai vu des fonction commencant par un "if data<>nil then begin" et le if finisait.... jsute avant le end de la fonction. bref. comme tu dis, pour une grande part, c'est une question de gout personel. n'empeche que c'est bien pratique.
"'un fonction de 200 lignes" hum, ça c'est contre ma religion! Car une fct de plus d'une centaine de ligne, ça devient dure a débogguer et c'est une source de problème/bug.
"pour ne pas utiliser un while" hum, un break peut ce mettre au milieux de la boucle. pas un while.
disons, que c'est souvent pratique de pouvoir gérer des cas limite à l'aide d'un exit, plustot que de faire des if begin-end partout. (j'ai vu des fonction commencant par un "if data<>nil then begin" et le if finisait.... jsute avant le end de la fonction. bref. comme tu dis, pour une grande part, c'est une question de gout personel. n'empeche que c'est bien pratique.
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
japee
Messages postés
1727
Date d'inscription
vendredi 27 décembre 2002
Statut
Modérateur
Dernière intervention
6 novembre 2021
8
19 nov. 2006 à 10:29
19 nov. 2006 à 10:29
Pour ajouter mon petit grain de sel, je trouve qu'il est parfois évident de préférer l'utilisation de Break ou Exit pour des raisons de lisibilité du code, et j'ajouterai qu'un commentaire bien placé trouvera là toute son utilité !
Après, il faudrait vérifier au niveau du code compilé, mais à mon avis un if then suivi d'exit placé au début d'une suite d'instructions doit équivaloir à un if then suivi d'un bloc begin..end.
Surtout que, mine de rien, l'indentation nous amène vite vers des codes plus larges que l'écran, lol
Bonne prog' dominicale
japee
Après, il faudrait vérifier au niveau du code compilé, mais à mon avis un if then suivi d'exit placé au début d'une suite d'instructions doit équivaloir à un if then suivi d'un bloc begin..end.
Surtout que, mine de rien, l'indentation nous amène vite vers des codes plus larges que l'écran, lol
Bonne prog' dominicale
japee
fredelem
Messages postés
136
Date d'inscription
dimanche 29 octobre 2006
Statut
Membre
Dernière intervention
1 décembre 2022
2
5 mars 2009 à 21:15
5 mars 2009 à 21:15
Il y a des fois où on a ce message de façon totalement injustifiée. En pariculier, lorsqu'on passe d'une "form" à une autre.
Quelquefois, on évite le problème en écrivant "ActiveCobtrol=Button1" au lieu de "Button1.SetFocus".
D'autres fois (pas toujours), les choses s'arrengent siŽ, au lieu d'écrire:
Form2.Button1.Setfocus;
on écrit deux lignes:
Form2.Setfocus;
Form2.Button1.Setfocus;
Quelquefois aussi, si on intercale un showmessage, on évite le message d'erreur:
Showmessage('Coucou');
Form2.Button1.Setfocus;
Mais ce remède est aussi mauvais que le mal ! Par quoi remplacer ce showmessage ? Par "Application.ProcessMessages" ? non, ça ne donne rien.
Quelquefois, on évite le problème en écrivant "ActiveCobtrol=Button1" au lieu de "Button1.SetFocus".
D'autres fois (pas toujours), les choses s'arrengent siŽ, au lieu d'écrire:
Form2.Button1.Setfocus;
on écrit deux lignes:
Form2.Setfocus;
Form2.Button1.Setfocus;
Quelquefois aussi, si on intercale un showmessage, on évite le message d'erreur:
Showmessage('Coucou');
Form2.Button1.Setfocus;
Mais ce remède est aussi mauvais que le mal ! Par quoi remplacer ce showmessage ? Par "Application.ProcessMessages" ? non, ça ne donne rien.
