De nouveau le même problème, je dois exporter ma table "TablePointés" qui
fait partie de la fenetre "FenPointés" vers un fichier Excel.
Ca marche lorsque mon bouton EXPORT se trouve dans la fentre FenPointé, mais
si je mets cette procédure ailleurs, ca plante sur la ligne
TableVersExcel...
Je sais qu'à ce niveau, la fenetre FenPointés est fermée et que la merde
vient suremetn d'ici. Juste avant la ligne "TableVersExcel ..." j'ai marqué
:
- Ouvre(Pointés,HorsEcran)
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Michel
titi a écrit :
Bonjour,
De nouveau le même problème, je dois exporter ma table "TablePointés" qui fait partie de la fenetre "FenPointés" vers un fichier Excel.
Ca marche lorsque mon bouton EXPORT se trouve dans la fentre FenPointé, mais si je mets cette procédure ailleurs, ca plante sur la ligne TableVersExcel...
Je sais qu'à ce niveau, la fenetre FenPointés est fermée et que la merde vient suremetn d'ici. Juste avant la ligne "TableVersExcel ..." j'ai marqué : - Ouvre(Pointés,HorsEcran)
Voila voila ...
Comment veux tu faire référence à un contenu en mémoire si celui-ci n'est justement plus en mémoire ?
c'est "Pointés" le nom de la fenêtre ou "FenPointés" ?
si tu fait un ouvre comme cela, la fenètre va bien s'ouvrir hors ecran mais elle va prendre le focus donc ton code TableVersExcel ne s'executera que lorsque cette fenetre sera fermé et donc plantera.
regardes les modes d'ouverture sous Windev (en fait sous Windows)
Le plus logique serait de n'autoriser l'ouverture de fenetres qui contiennent du code relatif à une autre fenetre qu'a partir de cette premiere fenetre, non ?
Dans FenPointé un bouton avec ouvre("FenAvecBoutonExport")
ou bien autre idée, dans le code d'ouverture des fenetre utilisant cette focntionnalité, testé si la fenetre "FenPointé est ouverte, sinon faire un OuvreFille en mode hors ecran.
Lors de la fermeture, la fenetre fille sera automatiquement refermée.
Michel
titi a écrit :
Bonjour,
De nouveau le même problème, je dois exporter ma table "TablePointés" qui
fait partie de la fenetre "FenPointés" vers un fichier Excel.
Ca marche lorsque mon bouton EXPORT se trouve dans la fentre FenPointé, mais
si je mets cette procédure ailleurs, ca plante sur la ligne
TableVersExcel...
Je sais qu'à ce niveau, la fenetre FenPointés est fermée et que la merde
vient suremetn d'ici. Juste avant la ligne "TableVersExcel ..." j'ai marqué
:
- Ouvre(Pointés,HorsEcran)
Voila voila ...
Comment veux tu faire référence à un contenu en mémoire si celui-ci
n'est justement plus en mémoire ?
c'est "Pointés" le nom de la fenêtre ou "FenPointés" ?
si tu fait un ouvre comme cela, la fenètre va bien s'ouvrir hors ecran
mais elle va prendre le focus donc ton code TableVersExcel ne
s'executera que lorsque cette fenetre sera fermé et donc plantera.
regardes les modes d'ouverture sous Windev (en fait sous Windows)
Le plus logique serait de n'autoriser l'ouverture de fenetres qui
contiennent du code relatif à une autre fenetre qu'a partir de cette
premiere fenetre, non ?
Dans FenPointé un bouton avec ouvre("FenAvecBoutonExport")
ou bien autre idée, dans le code d'ouverture des fenetre utilisant cette
focntionnalité, testé si la fenetre "FenPointé est ouverte, sinon faire
un OuvreFille en mode hors ecran.
Lors de la fermeture, la fenetre fille sera automatiquement refermée.
De nouveau le même problème, je dois exporter ma table "TablePointés" qui fait partie de la fenetre "FenPointés" vers un fichier Excel.
Ca marche lorsque mon bouton EXPORT se trouve dans la fentre FenPointé, mais si je mets cette procédure ailleurs, ca plante sur la ligne TableVersExcel...
Je sais qu'à ce niveau, la fenetre FenPointés est fermée et que la merde vient suremetn d'ici. Juste avant la ligne "TableVersExcel ..." j'ai marqué : - Ouvre(Pointés,HorsEcran)
Voila voila ...
Comment veux tu faire référence à un contenu en mémoire si celui-ci n'est justement plus en mémoire ?
c'est "Pointés" le nom de la fenêtre ou "FenPointés" ?
si tu fait un ouvre comme cela, la fenètre va bien s'ouvrir hors ecran mais elle va prendre le focus donc ton code TableVersExcel ne s'executera que lorsque cette fenetre sera fermé et donc plantera.
regardes les modes d'ouverture sous Windev (en fait sous Windows)
Le plus logique serait de n'autoriser l'ouverture de fenetres qui contiennent du code relatif à une autre fenetre qu'a partir de cette premiere fenetre, non ?
Dans FenPointé un bouton avec ouvre("FenAvecBoutonExport")
ou bien autre idée, dans le code d'ouverture des fenetre utilisant cette focntionnalité, testé si la fenetre "FenPointé est ouverte, sinon faire un OuvreFille en mode hors ecran.
Lors de la fermeture, la fenetre fille sera automatiquement refermée.
Michel
titi
> c'est "Pointés" le nom de la fenêtre ou "FenPointés" ?
C'est "FenPointés", c'est le fichier HF qui s'appelle POINTES
si tu fait un ouvre comme cela, la fenètre va bien s'ouvrir hors ecran mais elle va prendre le focus donc ton code TableVersExcel ne s'executera que lorsque cette fenetre sera fermé et donc plantera.
regardes les modes d'ouverture sous Windev (en fait sous Windows)
Le plus logique serait de n'autoriser l'ouverture de fenetres qui contiennent du code relatif à une autre fenetre qu'a partir de cette premiere fenetre, non ?
Dans FenPointé un bouton avec ouvre("FenAvecBoutonExport")
Tu pourrais mieux m'expliquer cela ? J'ai écrit dans ma fenetre isolée : ouvre(FenPointés.Exporter) => EXPORTER étant le nom du bouton ou se trouve ma procédure d'export. Mais j'ai encore un plantage. Est ce qu'il fallait faire ca ?
ou bien autre idée, dans le code d'ouverture des fenetre utilisant cette focntionnalité, testé si la fenetre "FenPointé est ouverte, sinon faire un OuvreFille en mode hors ecran.
Cela impose d'avoir une fenetre mère en MDI, ce que j'ai essayé de faire, mais ca m'a fait tout un bric a brac. Je suis pas encore assez musclé pour ca !
La première solution me parait bien ... Je rappelle que je dois automatiser une procédure d'exportation à l'ouvrture du programme, je ne peux donc pas demander à l'utilisateur d'aller dans telle et telle fenetre pour faire cela... cette procédure doit se trouver impérativement dans le code d'initialisation de ma 1° fenetre...
>
c'est "Pointés" le nom de la fenêtre ou "FenPointés" ?
C'est "FenPointés", c'est le fichier HF qui s'appelle POINTES
si tu fait un ouvre comme cela, la fenètre va bien s'ouvrir hors ecran
mais elle va prendre le focus donc ton code TableVersExcel ne s'executera
que lorsque cette fenetre sera fermé et donc plantera.
regardes les modes d'ouverture sous Windev (en fait sous Windows)
Le plus logique serait de n'autoriser l'ouverture de fenetres qui
contiennent du code relatif à une autre fenetre qu'a partir de cette
premiere fenetre, non ?
Dans FenPointé un bouton avec ouvre("FenAvecBoutonExport")
Tu pourrais mieux m'expliquer cela ? J'ai écrit dans ma fenetre isolée :
ouvre(FenPointés.Exporter) => EXPORTER étant le nom du bouton ou se trouve
ma procédure d'export. Mais j'ai encore un plantage. Est ce qu'il fallait
faire ca ?
ou bien autre idée, dans le code d'ouverture des fenetre utilisant cette
focntionnalité, testé si la fenetre "FenPointé est ouverte, sinon faire un
OuvreFille en mode hors ecran.
Cela impose d'avoir une fenetre mère en MDI, ce que j'ai essayé de faire,
mais ca m'a fait tout un bric a brac. Je suis pas encore assez musclé pour
ca !
La première solution me parait bien ...
Je rappelle que je dois automatiser une procédure d'exportation à l'ouvrture
du programme, je ne peux donc pas demander à l'utilisateur d'aller dans
telle et telle fenetre pour faire cela... cette procédure doit se trouver
impérativement dans le code d'initialisation de ma 1° fenetre...
> c'est "Pointés" le nom de la fenêtre ou "FenPointés" ?
C'est "FenPointés", c'est le fichier HF qui s'appelle POINTES
si tu fait un ouvre comme cela, la fenètre va bien s'ouvrir hors ecran mais elle va prendre le focus donc ton code TableVersExcel ne s'executera que lorsque cette fenetre sera fermé et donc plantera.
regardes les modes d'ouverture sous Windev (en fait sous Windows)
Le plus logique serait de n'autoriser l'ouverture de fenetres qui contiennent du code relatif à une autre fenetre qu'a partir de cette premiere fenetre, non ?
Dans FenPointé un bouton avec ouvre("FenAvecBoutonExport")
Tu pourrais mieux m'expliquer cela ? J'ai écrit dans ma fenetre isolée : ouvre(FenPointés.Exporter) => EXPORTER étant le nom du bouton ou se trouve ma procédure d'export. Mais j'ai encore un plantage. Est ce qu'il fallait faire ca ?
ou bien autre idée, dans le code d'ouverture des fenetre utilisant cette focntionnalité, testé si la fenetre "FenPointé est ouverte, sinon faire un OuvreFille en mode hors ecran.
Cela impose d'avoir une fenetre mère en MDI, ce que j'ai essayé de faire, mais ca m'a fait tout un bric a brac. Je suis pas encore assez musclé pour ca !
La première solution me parait bien ... Je rappelle que je dois automatiser une procédure d'exportation à l'ouvrture du programme, je ne peux donc pas demander à l'utilisateur d'aller dans telle et telle fenetre pour faire cela... cette procédure doit se trouver impérativement dans le code d'initialisation de ma 1° fenetre...
Michel
titi a écrit :
c'est "Pointés" le nom de la fenêtre ou "FenPointés" ?
C'est "FenPointés", c'est le fichier HF qui s'appelle POINTES
si tu fait un ouvre comme cela, la fenètre va bien s'ouvrir hors ecran mais elle va prendre le focus donc ton code TableVersExcel ne s'executera que lorsque cette fenetre sera fermé et donc plantera.
regardes les modes d'ouverture sous Windev (en fait sous Windows)
Le plus logique serait de n'autoriser l'ouverture de fenetres qui contiennent du code relatif à une autre fenetre qu'a partir de cette premiere fenetre, non ?
Dans FenPointé un bouton avec ouvre("FenAvecBoutonExport")
Tu pourrais mieux m'expliquer cela ? J'ai écrit dans ma fenetre isolée : ouvre(FenPointés.Exporter) => EXPORTER étant le nom du bouton ou se trouve ma procédure d'export. Mais j'ai encore un plantage. Est ce qu'il fallait faire ca ?
ou bien autre idée, dans le code d'ouverture des fenetre utilisant cette focntionnalité, testé si la fenetre "FenPointé est ouverte, sinon faire un OuvreFille en mode hors ecran.
Cela impose d'avoir une fenetre mère en MDI, ce que j'ai essayé de faire, mais ca m'a fait tout un bric a brac. Je suis pas encore assez musclé pour ca !
La première solution me parait bien ... Je rappelle que je dois automatiser une procédure d'exportation à l'ouvrture du programme, je ne peux donc pas demander à l'utilisateur d'aller dans telle et telle fenetre pour faire cela... cette procédure doit se trouver impérativement dans le code d'initialisation de ma 1° fenetre...
Je penses que tu dois avoir tes raisons de faire cela mais si tu veux exporter qqchose automatiquement pourquoi passer par un TableVersExcel qui est plutôt adapté qd l'utilisateur a la table affichée devant ses yeux et dont le contenu est le résultat d'une sélection particulière.
Est-ce parce que tu penses que c'est plus simple ?
Il y a des classes toutes faites pour piloter Excel sur le site de l'asso.
Tu fait un parcours de ton fichier et tu construit chaque ligne de ton fichier Excel. En plus ce sera plus clean car tu pourras avoir un document avec un formatage précis, logo etc...
Michel
titi a écrit :
c'est "Pointés" le nom de la fenêtre ou "FenPointés" ?
C'est "FenPointés", c'est le fichier HF qui s'appelle POINTES
si tu fait un ouvre comme cela, la fenètre va bien s'ouvrir hors ecran
mais elle va prendre le focus donc ton code TableVersExcel ne s'executera
que lorsque cette fenetre sera fermé et donc plantera.
regardes les modes d'ouverture sous Windev (en fait sous Windows)
Le plus logique serait de n'autoriser l'ouverture de fenetres qui
contiennent du code relatif à une autre fenetre qu'a partir de cette
premiere fenetre, non ?
Dans FenPointé un bouton avec ouvre("FenAvecBoutonExport")
Tu pourrais mieux m'expliquer cela ? J'ai écrit dans ma fenetre isolée :
ouvre(FenPointés.Exporter) => EXPORTER étant le nom du bouton ou se trouve
ma procédure d'export. Mais j'ai encore un plantage. Est ce qu'il fallait
faire ca ?
ou bien autre idée, dans le code d'ouverture des fenetre utilisant cette
focntionnalité, testé si la fenetre "FenPointé est ouverte, sinon faire un
OuvreFille en mode hors ecran.
Cela impose d'avoir une fenetre mère en MDI, ce que j'ai essayé de faire,
mais ca m'a fait tout un bric a brac. Je suis pas encore assez musclé pour
ca !
La première solution me parait bien ...
Je rappelle que je dois automatiser une procédure d'exportation à l'ouvrture
du programme, je ne peux donc pas demander à l'utilisateur d'aller dans
telle et telle fenetre pour faire cela... cette procédure doit se trouver
impérativement dans le code d'initialisation de ma 1° fenetre...
Je penses que tu dois avoir tes raisons de faire cela mais si tu veux
exporter qqchose automatiquement pourquoi passer par un TableVersExcel
qui est plutôt adapté qd l'utilisateur a la table affichée devant ses
yeux et dont le contenu est le résultat d'une sélection particulière.
Est-ce parce que tu penses que c'est plus simple ?
Il y a des classes toutes faites pour piloter Excel sur le site de l'asso.
Tu fait un parcours de ton fichier et tu construit chaque ligne de ton
fichier Excel.
En plus ce sera plus clean car tu pourras avoir un document avec un
formatage précis, logo etc...
c'est "Pointés" le nom de la fenêtre ou "FenPointés" ?
C'est "FenPointés", c'est le fichier HF qui s'appelle POINTES
si tu fait un ouvre comme cela, la fenètre va bien s'ouvrir hors ecran mais elle va prendre le focus donc ton code TableVersExcel ne s'executera que lorsque cette fenetre sera fermé et donc plantera.
regardes les modes d'ouverture sous Windev (en fait sous Windows)
Le plus logique serait de n'autoriser l'ouverture de fenetres qui contiennent du code relatif à une autre fenetre qu'a partir de cette premiere fenetre, non ?
Dans FenPointé un bouton avec ouvre("FenAvecBoutonExport")
Tu pourrais mieux m'expliquer cela ? J'ai écrit dans ma fenetre isolée : ouvre(FenPointés.Exporter) => EXPORTER étant le nom du bouton ou se trouve ma procédure d'export. Mais j'ai encore un plantage. Est ce qu'il fallait faire ca ?
ou bien autre idée, dans le code d'ouverture des fenetre utilisant cette focntionnalité, testé si la fenetre "FenPointé est ouverte, sinon faire un OuvreFille en mode hors ecran.
Cela impose d'avoir une fenetre mère en MDI, ce que j'ai essayé de faire, mais ca m'a fait tout un bric a brac. Je suis pas encore assez musclé pour ca !
La première solution me parait bien ... Je rappelle que je dois automatiser une procédure d'exportation à l'ouvrture du programme, je ne peux donc pas demander à l'utilisateur d'aller dans telle et telle fenetre pour faire cela... cette procédure doit se trouver impérativement dans le code d'initialisation de ma 1° fenetre...
Je penses que tu dois avoir tes raisons de faire cela mais si tu veux exporter qqchose automatiquement pourquoi passer par un TableVersExcel qui est plutôt adapté qd l'utilisateur a la table affichée devant ses yeux et dont le contenu est le résultat d'une sélection particulière.
Est-ce parce que tu penses que c'est plus simple ?
Il y a des classes toutes faites pour piloter Excel sur le site de l'asso.
Tu fait un parcours de ton fichier et tu construit chaque ligne de ton fichier Excel. En plus ce sera plus clean car tu pourras avoir un document avec un formatage précis, logo etc...
C'est surement pas très propre, mais ca marche ... merci.
titi
Je ne connais pas cette methode, mais ca a l'air effectivement + propre qu'avec TableVersExcel qui marche très bien lorsque la fenetre ou se trouve la table est ouverte.
Quel est la procédure ?
Je ne connais pas cette methode, mais ca a l'air effectivement + propre
qu'avec TableVersExcel qui marche très bien lorsque la fenetre ou se trouve
la table est ouverte.
Je ne connais pas cette methode, mais ca a l'air effectivement + propre qu'avec TableVersExcel qui marche très bien lorsque la fenetre ou se trouve la table est ouverte.
Quel est la procédure ?
Michel
titi a écrit :
Je ne connais pas cette methode, mais ca a l'air effectivement + propre qu'avec TableVersExcel qui marche très bien lorsque la fenetre ou se trouve la table est ouverte.
Quel est la procédure ?
Si tu ne veux pas utiliser une classe, tu peux aussi dire utiliser directement OLE : Exemple à vérifier car je tape cela directement dans le mail donc des erreurs se glissent certainement.
sfic = "Monfichier.xls" nLigne = 4 //Par exemple, on commence à écrire à partir de la 4eme ligne nColonne = 3 //Par exemple // On récupére l'objet Excel éventuellement déjà en mémoire xl est un objet OLE dynamique = ObjetActif("Excel.Application") // Allocation d'un objet Excel si non-trouvé SI xl=Null ALORS xl=allouer un objet OLE "Excel.Application" xl>>Visibleúux // Excel n'apparait pas à l'écran // Ouverture du document xl>>WorkBooks>>Open(sFic)
// Parcours du fichier sablier(vrai) HlitPremier(NomFichier,MaCle) Tantque pas Hendehors(NomFichier) nLigne++
// Envoi des données dans les cellules d'Excel xl>>Cells(nLigne,nColonne)>>Value=NomFichier.Champ1 xl>>Cells(nLigne,nColonne+1)>>Value=NomFichier.Champ2 ....... ....... HLitSuivant(NomFichier) FIN
xl>>ActiveWorkBook>>Save() // Enregistrement du document modifié xl>>ActiveWorkBook>>Close(Faux) // Fermeture du document xl>>Quit() // Fermeture d'Excel libérer xl // Libération de l'objet Excel // Affichage du document ?
Sablier(Faux) SI OuiNon("Fichier Excel enregistré."+RC+"Souhaitez vous voir le résultat ?") ALORS LanceAppliAssociée(sFic) FIN FIN
titi a écrit :
Je ne connais pas cette methode, mais ca a l'air effectivement + propre
qu'avec TableVersExcel qui marche très bien lorsque la fenetre ou se trouve
la table est ouverte.
Quel est la procédure ?
Si tu ne veux pas utiliser une classe, tu peux aussi dire utiliser
directement OLE :
Exemple à vérifier car je tape cela directement dans le mail donc des
erreurs se glissent certainement.
sfic = "Monfichier.xls"
nLigne = 4 //Par exemple, on commence à écrire à partir de la
4eme ligne
nColonne = 3 //Par exemple
// On récupére l'objet Excel éventuellement déjà en mémoire
xl est un objet OLE dynamique = ObjetActif("Excel.Application")
// Allocation d'un objet Excel si non-trouvé
SI xl=Null ALORS xl=allouer un objet OLE "Excel.Application"
xl>>Visibleúux // Excel n'apparait pas à l'écran
// Ouverture du document
xl>>WorkBooks>>Open(sFic)
// Parcours du fichier
sablier(vrai)
HlitPremier(NomFichier,MaCle)
Tantque pas Hendehors(NomFichier)
nLigne++
// Envoi des données dans les cellules d'Excel
xl>>Cells(nLigne,nColonne)>>Value=NomFichier.Champ1
xl>>Cells(nLigne,nColonne+1)>>Value=NomFichier.Champ2
.......
.......
HLitSuivant(NomFichier)
FIN
xl>>ActiveWorkBook>>Save() // Enregistrement du document modifié
xl>>ActiveWorkBook>>Close(Faux) // Fermeture du document
xl>>Quit() // Fermeture d'Excel
libérer xl // Libération de l'objet Excel
// Affichage du document ?
Sablier(Faux)
SI OuiNon("Fichier Excel enregistré."+RC+"Souhaitez vous voir le
résultat ?") ALORS
LanceAppliAssociée(sFic)
FIN
FIN
Je ne connais pas cette methode, mais ca a l'air effectivement + propre qu'avec TableVersExcel qui marche très bien lorsque la fenetre ou se trouve la table est ouverte.
Quel est la procédure ?
Si tu ne veux pas utiliser une classe, tu peux aussi dire utiliser directement OLE : Exemple à vérifier car je tape cela directement dans le mail donc des erreurs se glissent certainement.
sfic = "Monfichier.xls" nLigne = 4 //Par exemple, on commence à écrire à partir de la 4eme ligne nColonne = 3 //Par exemple // On récupére l'objet Excel éventuellement déjà en mémoire xl est un objet OLE dynamique = ObjetActif("Excel.Application") // Allocation d'un objet Excel si non-trouvé SI xl=Null ALORS xl=allouer un objet OLE "Excel.Application" xl>>Visibleúux // Excel n'apparait pas à l'écran // Ouverture du document xl>>WorkBooks>>Open(sFic)
// Parcours du fichier sablier(vrai) HlitPremier(NomFichier,MaCle) Tantque pas Hendehors(NomFichier) nLigne++
// Envoi des données dans les cellules d'Excel xl>>Cells(nLigne,nColonne)>>Value=NomFichier.Champ1 xl>>Cells(nLigne,nColonne+1)>>Value=NomFichier.Champ2 ....... ....... HLitSuivant(NomFichier) FIN
xl>>ActiveWorkBook>>Save() // Enregistrement du document modifié xl>>ActiveWorkBook>>Close(Faux) // Fermeture du document xl>>Quit() // Fermeture d'Excel libérer xl // Libération de l'objet Excel // Affichage du document ?
Sablier(Faux) SI OuiNon("Fichier Excel enregistré."+RC+"Souhaitez vous voir le résultat ?") ALORS LanceAppliAssociée(sFic) FIN FIN
