Catch closing and saving Exel file

Version imprimable

11/11/2013, 11h45
m3allem001

Catch closing and saving Exel file

Bonjour,

J'ai une application java swing.J'ai crée un bouton qui fait l'export des données d'un JTable vers un fichier excel .Je veux que le fichier s'ouvre directement après l'export, puis je décide de l'enregistrer ou l'abandonner.
J'ai fait une recherche sur le net, j'ai conclu que je doit forcément l'enregistrer avant son ouverture.(s'il y a une autre idée, merci de m'aider).
Pour cela j'ai choisi un répertoire temporaire comme destination.
Maintenant, je veux savoir s'il y a une méthode pour faire le catch de l’événement de fermeture ou enregistrement du fichier excel temporaire déjà ouvert, pour le supprimer du disque.

Merci
11/11/2013, 11h48
JoeChip

Pourquoi ne pas le fermer avant de le supprimer ? En principe l'OS est censé refuser la suppression si le fichier est ouvert...
11/11/2013, 11h53
m3allem001

si je ne veux pas l’enregistrer, je dois le fermer donc un catch de close Event le supprime.
si je veux l'enregistrer, après il reste ouvert mais avec le nouveau emplacement.
je dois donc supprimer celui initial.
11/11/2013, 12h14
joel.drigo

Salut,

de base , ton programme java ne peut pas connaitre ce que fait excel (que cela soit une sauvegarde ou autre chose).

En plus, le fichier exporté devra être créé et fermé avant de pouvoir être ouvert dans excel, donc pour excel, sans faire une modification dans excel, il n'y aura aucune raison de proposer la sauvegarde du fichier.

A part faire des trucs compliqués à partir de macros excel, je vois pas de façon de faire ça.
Par exemple, une solution théorique (je ne sais pas d'avance si ça peut fonctionner) : trouver un moyen de lancer une macro excel (peut être en créant un fichier excel avec la macro (ce qui ne peut pas être fait avec poifs ), et s'arranger pour qu'elle s'éxécute à l'ouverture) : qui qui créé un nouveau classeur à partir de celui contenu dans le fichier temporaire exporté, le ferme ensuite, et lance la sauvegarde. A la fin la macro doit "s'auto fermer". En lançant la commande excel en mode wait, tu pourras savoir quand effacer ton fichier temporaire.

La question à se poser maintenant : c'est pourquoi tu veux faire ça ? Pour avoir un aperçu du fichier avant de le sauvegarder ? Pourquoi ne pas créer un aperçu java ? Tu veux un aperçu aussi fidèle que possible ? Peut être qu'en affichant le document dans excel (ou en html peut être), mais en contrôlant sa sauvegarde définitive en java.
11/11/2013, 14h29
m3allem001

l'utilisateur ne doit pas se rendre compte de la sauvegarde temporaire car lui, n'a pas encore choisi l'emplacement qu'il désire.Le fichier excel doit s'ouvrir comme aperçu, il peut lui apporter des modifications et faire la sauvegarde, comme il peut se contenter de la simple lecture du fichier et le ferme, sans besoin de sauvegarde.Donc la copie temporaire est à supprimer dans les deux cas.
C'est ainsi q'un catch de la fermeture ou sauvegarde résout le problème.
11/11/2013, 14h33
joel.drigo

Citation:

Envoyé par m3allem001

l'utilisateur ne doit pas se rendre compte de la sauvegarde temporaire car lui, n'a pas encore choisi l'emplacement qu'il désire.Le fichier excel doit s'ouvrir comme aperçu, il peut lui apporter des modifications et faire la sauvegarde, comme il peut se contenter de la simple lecture du fichier et le ferme, sans besoin de sauvegarde.Donc la copie temporaire est à supprimer dans les deux cas.
C'est ainsi q'un catch de la fermeture ou sauvegarde résout le problème.

Mais pourquoi ne pas faire ça avant dans ton prog java (l'aperçu, les modifications, le choix de l'emplacement) avant la création du fichier excel ?
11/11/2013, 14h47
m3allem001

les données tu fichier excel est un flux provenant d'une autre machine.
Donc l'utilisateur final peut garder du fichier ou supprimer ce qu'il veut selon son besoin.
11/11/2013, 15h00
joel.drigo

Citation:

Envoyé par m3allem001

les données tu fichier excel est un flux provenant d'une autre machine.
Donc l'utilisateur final peut garder du fichier ou supprimer ce qu'il veut selon son besoin.

Tu parlais de données exportées d'un jtable vers un fichier excel : ça n'a rien à voir !

Ensuite, "flux provenant d'une autre machine" ? c'est quoi ? Le fichier excel téléchargé depuis un serveur ftp, partage cifs, ou un serveur http ? Des données lues dans un sgbd via jdbc et que tu exportes dans un fichier xls par poifs ? Provenant d'un webservice, en xml ? lues au format json depuis une url http ? Flux ça veut pas dire grand chose dans le contexte de ta question...

Une chose est sure : si tu ouvres un fichier excel dans excel, via une commande lançée depuis ton programme java, tu n'auras pas de moyen (simple) de savoir ce qu'il se passe dans excel, ni de moyen de forcer l'utilisateur de faire quoique ce soit. Un utilisateur lambda se contentera de fermer excel : les données resteront dans le fichier temporaire, et tu n'auras pas de moyen de savoir si ça été annulé, modifié (ou peut être sur le timestamp du fichier), sauvegardé ailleurs, ou autre. Et tu vas te compliquer la vie, pour faire quelque chose qui n'est pas forcément nécessaire (qui peut être fait autrement techniquement parlant) !

En fait le flux dont je parle est sauvegardé dans une BDD oracle qui alimente ensuite le Jtable.

après avoir fait l'export,

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
TableModel model = table.getModel();
	        FileWriter excel = new FileWriter(file);
 
	        for(int i = 0; i < model.getColumnCount(); i++){
	            excel.write(model.getColumnName(i) + "\t"); 
	        }
 
	        excel.write("\n");
 
	        for(int i = 0; i < model.getRowCount(); i++) {
	            for(int j = 0; j < model.getColumnCount(); j++) {
	                excel.write(model.getValueAt(i,j).toString()+"\t");
	            }
	            excel.write("\n");
	        }
	        excel.close();

le fichier excel s'ouvre

Code:

1
2
3
 
	        Desktop dt = Desktop.getDesktop();
	        dt.open(file);

et je parviens à faire des modifications et le sauvegarder où je veux.

11/11/2013, 15h49
joel.drigo

Deja, c'est pas un fichier excel que tu créés, mais un fichier texte (au format tab-separated).

Tu ne peux pas forcer l'utilisateur à ne pas sauvegarder dans ce fichier en plus. Il restera au format tab-separated si l'utilisateur ne choisit pas le format excel. A l'ouverture du fichier, l'utilisateur aura un message qui dit que c'est pas du excel, avec une confirmation (lourd).

Tu peux même pas forcer l'utilisateur à fermer le doc, ou excel.

Ces modifications ne peuvent elle être faite en java, dans la jtable directement avant export ? Quel besoin d'ouvrir excel pour créer un fichier tab-separated ? Parce que c'est de la bricole que de chercher à utiliser excel pour modifier des datas d'une jtable !!!

sinon, tu peux ouvrir ton fichier temporaire avec le switch /t ou /n (avec ProcessBuilder au lieu Desktop) : il sera considéré comme template, donc les modifications faites par l'utilisateur ne pourront être sauvegardées dans le fichier temporaire

Mais reste 2 problèmes :
- impossible de forcer l'utilisateur à sauvegarder le fichier s'il ne fait pas de modif (la fermeture ne fera rien)
- impossible de savoir si et quand (et ou) l'utilisateur a sauvegardé (ou pas facile, parce qu'on pourrait imaginer scruter tout le disque (enfin si on est un ouf déglinguo ;)))
- impossible de savoir si et quand excel est fermé
- comme excel se lance dans un process non synchrone, impossible de savoir quand effacer le fichier temporaire (seule solution, un peu pourrie, attendre quelques secondes avant de l'effacer) ; éventuellement, il y a la solution de créer un fichier temporaire qui s'efface tout seul à la fermeture de l'application java.

De toute manière, avec la classe Desktop et Excel, impossible de savoir quand excel se ferme !

(quand je dis impossible, je veux dire sans passer un temps fou à faire une usine à gaz qui fonctionne dans 99% de cas, parce que rien n'est jamais vraiment impossible en informatique)
11/11/2013, 16h21
m3allem001
Citation:

Envoyé par joel.drigo

Deja, c'est pas un fichier excel que tu créés, mais un fichier texte (au format tab-separated).

J'ai oublié cette ligne :
Code:

1 2 File file = new File("c:\\temp",table.getName() + ".xls");
Citation:

Envoyé par joel.drigo

- impossible de forcer l'utilisateur à sauvegarder le fichier s'il ne fait pas de modif (la fermeture ne fera rien).

je parviens ,encore, à exporter le fichier, le modifier et le sauvegarder. ça tourne!
11/11/2013, 16h42
joel.drigo
Citation:
Envoyé par m3allem001

J'ai oublié cette ligne :

Code:

1 2 File file = new File("c:\\temp",table.getName() + ".xls");
L'extension du fichier n'a rien à voir avec le format du fichier ! Tu crois que si tu renommes un fichier png en xls ça en fait un fichier excel ? tu as qu'a essayer pour voir ce que ça fait !

Citation:

Envoyé par m3allem001

J'ai oublié cette ligne :
je parviens ,encore, à exporter le fichier, le modifier et le sauvegarder. ça tourne!

Oui, tu sais ce qu'il faut faire et tu y tiens. Je dis pas que ça marche pas. Je dis que c'est une façon approximative et aléatoire de procéder.
Sans mode d'emploi, un utilisateur lambda ne saura pas quoi faire, et même si tu lui dit quelles manip il doit faire, tu n'auras aucune garantie qu'il les fasse comme tu t'y attends (entre ceux qui s'en foutent des procédures (ou même les pseudos-rebelles qui font exprès de faire ce qu'il ne faut pas faire), ceux qui n'ont rien compris, ceux qui peuvent pas s'empêcher de toucher à tout et n'importe quoi, et ceux qui ont pas envie de se faire chier et qui veulent faire un minimum de manip, genre cliquer sur suivant, suivant, suivant, fin). Il peut par exemple très bien sauvegarder dans ton fichier temporaire par exemple(tu peux le savoir certes en comparent timestamp avant et après), ou pas sauvegarder du tout.

Ca me dit pas pourquoi tu as besoin d'excel dans l'histoire...

Dans les procédures d'export de mes applications, l'utilisateur lance une commande d'export (PDF, EXCEL, XML...), choisi un emplacement, coche éventuellement une boite à cocher "ouvrir automatiquement dans l'application xxx", et fait ok. la ça exporte, et il fait ce qu'il veut ensuite, je m'en fous complètement : c'est le principe d'un export en fat.
Et quand les datas peuvent/doivent être modifiées, c'est avant export, ou pendant éventuellement, mais sur les données avant export. Quand je fais du PDF, j'ouvre pas Acrobat en disant aux utilisateurs, ajouter moi les annotations que vous voulez et sauvegardez ! Je m'arrange pour qu'ils puissent annoter dans mon appli et j'exporte les annotations quand je construis le doc ! En plus, pas besoin d'imposer aux utilisateurs d'avoir Acrobat
11/11/2013, 17h52
m3allem001

Citation:

Envoyé par joel.drigo

Ca me dit pas pourquoi tu as besoin d'excel dans l'histoire...

L'utilisateur a besoin d'excel, il peut faire des calculs,.... , le fichier peut être le un consommable par d'autres applications.

Mon souci n'est plus si l'utilisateur fait des modifications ou pas mais plutôt
savoir quand supprimer le fichier temporaire.

Bref, J'ai ajouté un WindowListener au frame principale, au moment de quitter l'application je vide le repertoire temporaire, ça m'arrange

merci bq.
11/11/2013, 18h03
joel.drigo

Citation:

Envoyé par m3allem001

L'utilisateur a besoin d'excel, il peut faire des calculs,.... , le fichier peut être le un consommable par d'autres applications.

Mon souci n'est plus si l'utilisateur fait des modifications ou pas mais plutôt
savoir quand supprimer le fichier temporaire.

Pourquoi créer alors un fichier temporaire ? Exportes directement ton fichier et laisses le vivre sa vie à l'exterieur de ton appli...

Citation:

Envoyé par m3allem001

Bref, J'ai ajouté un WindowListener au frame principale, au moment de quitter l'application je vide le repertoire temporaire, ça m'arrange

merci bq.

Pour info, tu peux créer des fichiers qui se suppriment tout seul quand ton appli est terminée (File.deleteOnExit()).

Mais ta suppression des fichiers temporaires ne garantit en rien que tu ne supprimeras pas des fichiers modifiés par l'utilisateur : pour peu qu'il ait passé 2 heures dessus, il va être content quand tu lui supprimeras :O ou alors il faut que tu testes le timestamp du fichier pour savoir que le fichier n'a pas été modifié après que tu l'as créé (donc que tu stockes la liste des fichiers créés avec le timestamp de création dans une variable de ton appli).
11/11/2013, 18h24
m3allem001

je peux appliquer directement

Code:

File.deleteOnExit()

car le fichier temporaire se trouve dans un répertoire autre que celui choisi par l'utilisateur au moment de sauvegarde.
NB :l’utilisateur ne sait pas qu'il existe un répertoire temporaire

merci.
11/11/2013, 18h31
joel.drigo

Citation:

Envoyé par m3allem001

je peux appliquer directement

Code:

File.deleteOnExit()

car le fichier temporaire se trouve dans un répertoire autre que celui choisi par l'utilisateur au moment de sauvegarde.
NB :l’utilisateur ne sait pas qu'il existe un répertoire temporaire

merci.

Quand tu ouvres ton fichier temporaire, je sais pas, c:/temp/truc.xls, l'utilisateur le voit le path du fichier (il est dans le titre de la fenêtre) !!!
Et il s'il modifie le classeur et fait enregistrer, puis ok (je simplifie toutes les questions) : il écrit bien ses modifications dans ce fichier (temporaire) !!! Qu'est qui peut bien garantir que le fichier créé par l'utilisateur dans excel (lors du Save as, ou du Save) ne soit pas dans le dossier temporaire (dont il ne sait pas qu'il soit temporaire d'ailleurs comme tu le remarques...) ?
11/11/2013, 18h37
m3allem001

Citation:

Envoyé par joel.drigo

Qu'est qui peut bien garantir que le fichier créé par l'utilisateur dans excel (lors du Save as, ou du Save) ne soit pas dans le dossier temporaire (dont il ne sait pas qu'il soit temporaire d'ailleurs comme tu le remarques...)

toute application nécessite quelque part l'intervention humaine avec un minimum d'intelligence:lol:

Si après tout ça il ne fait pas save as au lieu save, tant pis pour lui:mouarf:

généralement, il y a un dossier par défaut réservé aux sauvegardes.
11/11/2013, 19h08
joel.drigo

Citation:

Envoyé par m3allem001

toute application nécessite quelque part l'intervention humaine avec un minimum d'intelligence:lol:

Si après tout ça il ne fait pas save as au lieu save, tant pis pour lui:mouarf:

généralement, il y a un dossier par défaut réservé aux sauvegardes.

Ca, c'est de la théorie ! Dans les faits, les utilisateurs ont tellement de boulot qu'il n'ont pas forcément envie de perdre du temps à se poser des questions, et détestent par dessus tout avoir à faire des trucs manuellement. Sans parler de perdre leur boulot : surtout si c'est ton application qui supprime les fichiers à leur insu... C'est pas une question d'intelligence, c'est une question de productivité (un exemple classique : les utilisateurs ne pensent jamais à sauvegarder régulièrement pendant qu'ils bossent. c'est pourtant une évidence pour ne pas perdre son boulot, et pourtant, on nous demande de faire des sauvegardes temporaires régulières automatiques au cas où...)
En tout cas beaucoup d'utilisateurs préfèrent les applications qui font le boulot à leur place. Quand c'est possible, et qu'une appli le fait, c'est celle là qui sera préférée à celle qui oblige à faire des manips multiples.

En tout cas, dans ton cas, il est bien plus simple de directement exporter vers le fichier final, que de sauvegarder dans un fichier temporaire et de demander à l'utilisateur de faire un Save as...
11/11/2013, 20h03
JoeChip

D'accord avec joel.drigo : tu te complique la vie, juste pour compliquer celle de l'utilisateur, au lieu de simplement lui demander où exporter le fichier, libre à lui ensuite de le modifier.