Ceci est une page optimisée pour les mobiles. Cliquez sur ce texte pour afficher la vraie page.

XL 2019 Fermeture intempestive de formulaire

gbinforme

XLDnaute Impliqué
Bonjour à tous,

Je suis confronté à un souci dont je ne comprend pas la cause.
J'ai 2 formulaires assez basiques avec textbox, labels, listbox qui vont chercher des informations
à la fois sur le classeur et sur le web pour documenter la listbox et/ou des labels.

Cela fonctionne très correctement sauf que lorsque le traitement est effectué
le formulaire se ferme sans que l'on puisse faire le traitement sur les données affichées.

Comme dans certains cas le formulaire reste affiché, je ne comprends pas
la fermeture dans la plupart des affichages.
Dans le cas des labels, j'ai résolu le souci en enregistrant les informations sur une feuille
mais je ne peut pas faire de même pour celui avec listbox.

Si quelqu'un a la moindre idée à me proposer je l'en remercie d'avance.
 
Solution
Bonjour,
Le classeur donné n'utilise que la Méthode Post ( donc beaucoup de status > 400 ) et trop d'options setReQuestHeader .
Nota: quand on paramètre certains setReQuestHeader, c'est généralement pour un site prédéfini , ils ne sont pas universels .

Certains sites renvoient des "lignes" > 2047 caractères et de ce fait supérieures à la longueur max d'une colonne de listbox, ce qui a tendance à la faire planter ...

Voyez le classeur joint s'il peut répondre à votre attente .

Gégé-45550

XLDnaute Accro
As-tu essayé d'ouvrir le UserForm en mode modal ?


Ce que je ne comprends pas, c'est qu'un clic sur le bouton "Quitter" n'est pas pris en compte.
Hello l'ami TooFatBoy, bonsoir (bonjour ?) gbinforme,
En supprimant la commande
VB:
Cancel=True
dans la procédure
Code:
Private Sub C_mot_Exit(ByVal Cancel As MSForms.ReturnBoolean)
on redonne leur opérationnalité aux boutons 'Valider' et 'Quitter'.
En déplaçant la commande
Code:
Call rech(C_mot)
de ladite procédure vers la procédure CommandButton1_Click et en la faisant précéder par un Recherche.Hide
Code:
Sub CommandButton1_Click()
    Recherche.Hide
    Call rech(C_mot.Value)
End Sub
et enfin, en remplaçant MNU.Activate par {Recherche.Show 0} à la fin de la procédure
Code:
Private Sub cnx_page(adr)
on retrouve (ouf) un comportement (presque) normal.
Cordialement,
 
Dernière édition:

gbinforme

XLDnaute Impliqué
on retrouve (ouf) un comportement (presque) normal.
Bonjour,
En ce qui me concerne, malgré les modifications préconisées pour éviter d'utiliser la procédure 'Exit' qui peut poser souci,, mon formulaire en non modal continue de se fermer.
D'autre part l'utilisation du Hide empêche la listbox d'afficher les données.
Pour moi cela ne me semble toujours pas un comportement normal,
mais un grand merci pour avoir passer du temps sur ce phénomène
et j'espère que par petites touches l'on va résoudre le problème.
 

patricktoulon

XLDnaute Barbatruc
Bonjour
la fermeture intempestive d'un userform est quelque fois due a une réponse erronée de vba
en effet l'erreur out of mémory déclenche un message (habituellement) mais des fois quand le probleme est trop haut c'est pas le message mais la fermeture du userform qui est appliquée

contrôle tout les types de variable et si ça correspond au méthodes que tu utilise
 

gbinforme

XLDnaute Impliqué
contrôle tout les types de variable et si ça correspond au méthodes que tu utilise
Bonjour Patrick,
J'utilise ce genre de procédure journellement sans problème et les variables sont toutes typées bien sûr pour éviter les ennuis. Dans ce cas la fermeture est systèmatique, malgré les modifications qui m'ont été préconisées, seul l'affichage en non modal évite la fermeture mais ce mode bloque les traitements externes en ce qui me concerne.
Merci de ton expertise.

Bon j'ai rajouté une option pour cacher ou non le formulaire comme conseillé par Gégé-45550 mais il me semble que cela ne change rien et le cancel n'est plus là non plus.
Le formulaire lancé non modal disparait dans tous les cas en ce qui me concerne.
Je vous met le classeur test en espérant que quelqu'un me trouve la raison de la panne.
 

Pièces jointes

  • test.xlsm
    24.6 KB · Affichages: 3
Dernière édition:

Gégé-45550

XLDnaute Accro
Bonjour
le classeur est disponible mais l'appréhension du phénomène n'a pas l'air de bien inspirer.
C'est vrai qu'il ne doit pas être très documenté.
Bonjour gbinforme et un clin d'œil à l'ami @TooFatBoy !
J'ai beaucoup de respect pour l'ami @patricktoulon et pour ses immenses compétences sur Excel et je "crains" qu'une fois de plus il ait raison.
Reprenant les remarques de son post #21, j'ai testé votre programme en modifiant plusieurs fois votre constante "sit" avec un certain nombre d'adresses différentes.
Chaque fois qu'une de ces adresses renvoyait au moins une erreur (facile à vérifier dans l'onglet "lot"), l'userform "Recherche" était intempestivement fermé, puis j'ai fini par chercher le mot "orange" sur le site de Orange (l'adresse figure dans le test joint) et là, pas de fermeture intempestive.
En cherchant sur le même site le mot "dur" (choisi au hasard) => fermeture intempestive !
Je livre cela à votre réflexion.
Cordialement,
 

Pièces jointes

  • test.xlsm
    37.3 KB · Affichages: 3

patricktoulon

XLDnaute Barbatruc
re
et oui une réponse booléenne false pour un réponse string ou long attendue
selon le poids ben c'est (et là je le dis en français) "mémoire insuffisante" qui se traduit sur 2007 par un whitescreen voir un plantage d'excel et sur mon 2013 la fermeture du userform
car j'ai augmenté ma mémoire disp (2g -->3,69 G) avec le patch LAA qui est un KB pour office 2013
2016 et supérieur Étant déjà aussi à 4 g (3,89 en vrai) l'userform se ferme aussi
 

TooFatBoy

XLDnaute Barbatruc
Je n'ai toujours pas de fermeture du UserForm...

Est-ce que la quantité de RAM joue ???
Je ne sais pas si j'ai 4 g de RAM comme le Pat car perso je ne me suis pas amusé à la peser, mais je sais qu'en quantité je n'ai que 8 Gio de RAM sur ce PC car il a presque 15 ans...
 

patricktoulon

XLDnaute Barbatruc
@TooFatBoy
si tu a 2007 ou 2013 tu a 2 G
sinon si tu a 2013 + kb comme moi tu a 4 G
si tu 2016 ou plus tu a 4 G
Pour info les versions 64 ne sont pas limitées la seule limmite c'est ce qui est dispo dans le pc
je dis ca c'est théorique je n'ai jamais poussé a l'extreme un fichier excel mais je suis allé assez loin pour dire que si un fichier fait ça c'est que soit il a un probleme soit une variable qui n'est pas du bon type et l'operation qui est faite avec tourne en boucle et sature la mémoire
 
Dernière édition:

fanch55

XLDnaute Barbatruc
Re-bonsoir,
Utilisez "WinHttp.WinHttpRequest.5.1" à la place de "microsoft.xmlhttp".
Après le send de la requête, testez le code retour de la requête ( un code "erreur" peut mettre un peu n'importe quoi dans responsetext ).
VB:
    R_Q.send
    DoEvents
    If R_Q.Status < 400 Then
        Set doc = CreateObject("htmlfile")
        With doc
            .body.innerhtml = R_Q.responsetext
            tmp = .ParentWindow.clipboardData.SetData("text", .body.innerhtml)
        End With
        With wj
            .Activate
            .Cells(1, 1).Activate
            .Paste
            tmp = doc.ParentWindow.clipboardData.ClearData("text")
            DoEvents
            For Each img In .Shapes
                img.Delete
            Next img
        End With
    Else
        wj.Cells.Clear
        wj.[A1] = R_Q.Status & " " & R_Q.StatusText
    End If
 

Gégé-45550

XLDnaute Accro
Bonsoir,
avec ce code et "WinHttp.WinHttpRequest.5.1", toujours le même retour ("Bad Request") mais pas de fermeture du usf.
 

Discussions similaires

Réponses
27
Affichages
1 K
Les cookies sont requis pour utiliser ce site. Vous devez les accepter pour continuer à utiliser le site. En savoir plus…