Valeur de sortie d'une programme [Résolu]

Messages postés
297
Date d'inscription
dimanche 14 mars 2004
Dernière intervention
18 décembre 2014
- 27 août 2007 à 16:52 - Dernière réponse :
Messages postés
297
Date d'inscription
dimanche 14 mars 2004
Dernière intervention
18 décembre 2014
- 31 août 2007 à 09:02
Bonjour,

J'aimerais savoir comment faire pour assigner une valeur de sortie à un programme et la récupérer dans un autre.
Pour mieux comprendre, j'ai un programme de gestion de compte bancaire qui utilise un TProcess pour executer un autre programme qui permet d'imprimer un relevé de compte. J'ai séparé les deux car le programme de gestion est enorme, et windows a du mal à gérer la mémoire.
Donc j'aimerais que mon programme d'impression puisse renvoyer une valeur comme en C ( int main(void) ) désolé pour l'exemple en C. Le programme de gestion récupére cette valeur pour l'utiliser : savoir si l'impression s'est bien passé, si l'utilisateur a annuler l'impression, etc...

Merci

A bientot
Afficher la suite 

Votre réponse

12 réponses

Meilleure réponse
Messages postés
3982
Date d'inscription
mardi 8 mars 2005
Dernière intervention
7 novembre 2014
- 29 août 2007 à 13:44
3
Merci
Salut,

Si tu veux vraiment faire un deuxième programme qui renvoie une valeure de retour, c'est tout à fait possible. Il faut créer le processus avec CreateProcess. Le programme appelé peut par exemple utiliser ExitProcess pour renvoyer un code d'erreur. Il faut ensuite que le créateur attende le deuxième processus, avec WaitForSingleObject par exemple (Peut être sur un thread pour ne pas le figer...).

Finalement, un appel à GetExitCodeProcess permet de récupérer le code renvoyé (En lui passant le hanlde récupéré dans le CreateProcess).

Pour avoir un dépassement de pile sous Windows sans faire de récursif, il faut y aller vraiment (très) (très) très fort sur les variables locales. Et un processus doit pouvoir allouer au moins 1Go de mémoire globale sans trops de soucis.

Là je suis sous FireFox qui consomme 216Mo de RAM + 213Mo de mémoire virtuelle (Mémoire virtuelle -> Windows met des données sensées être dans la RAM sur le dur pour que le PC est en apparence beaucoup de mémoire RAM).

Donc tes 25Mo....

Si ton programme rame au moment de l'impression, c'est certainement au niveau du dialogue avec l'imprimante qu'il y a un problème, ou que les fichiers à imprimer sont très gros. Tu peux éventellement essayer de réaliser l'impression sur un thread si ton programme ne répond pas pendant l'impression.

Merci cs_rt15 3

Avec quelques mots c'est encore mieux Ajouter un commentaire

Codes Sources a aidé 88 internautes ce mois-ci

Commenter la réponse de cs_rt15
Meilleure réponse
Messages postés
4580
Date d'inscription
samedi 19 janvier 2002
Dernière intervention
9 janvier 2013
- 30 août 2007 à 09:43
3
Merci
Bonjour,

Pour indiquer un code de retour d'un programme, il y a l'instruction suivante (et méconnue) :
Unité : System



Catégorie : routines de contrôle de flux



Syntaxe Delphi :


procedureHalt [(Exitcode:Integer)];



Description :


La procédure Halt exécute une fin anormale d'un programme et renvoie le contrôle au système d'exploitation.


Pour exécuter une fin normale d'une application Delphi,appelez la méthode Terminate sur l'objet global Application.Si l'application n'utilise aucune unitéfournissant un objet Application,appelez la procédure Exit àpartir du bloc de programme principal.


Exitcode est une expression facultative qui indique le code de sortie du programme.

Qui n'a jamais utilisé, dans des fichiers batch, un test du genre :
if errorlevel == ...
Eh bien, c'est ce genre de code que retournera l'application si l'on utilise l'instruction Halt.

Mais les remarques concernant l'optimisation du code s'appliquent toujours. Cette solution ne serait être qu'un pis-aller.

May Delphi be with you !





<hr color="#008000" />
Pensez à cliquer sur Réponse acceptée lorsque la réponse vous convient.
http://www.afipa.net/

Merci cs_Delphiprog 3

Avec quelques mots c'est encore mieux Ajouter un commentaire

Codes Sources a aidé 88 internautes ce mois-ci

Commenter la réponse de cs_Delphiprog
- 27 août 2007 à 17:30
0
Merci
Salut Oniria,

Moi à ta place je serai plus préoccupé par le fait que mon application pédale . En général c'est le signe que le projet a été mal codé ou mal pensé : style des variables globales plutot que des variables locales, libération d'objets à des moments non opportuns(d'ou l'interet des variables locales) ou pas du tout, mauvaise gestion des tableaux ect ect.

Je pense pas que d'inclure la procédure d'impréssion  dans ton premier soft change grand chose en terme de ressources .

Une solution qui n'est pas des plus jolies mais qui est simple et efficace est d'utiliser les fichiers Ini pour faire une telle chose : ca te permettra de comparer facilement la valeur assigné à ta variable. L'avantage aussi c'est que l'acces à ces fichiers est rapide et peu gourmand.

Pour revenir à ton probleme : j'essayerai plutot de l'optimiser à ta place. Imagine Delphi fait 500Mo et il rame pas :meme sur un 486 (Si si j'ai essayé ). Je pense pas que ton soft soit aussi conséquent que notre IDE favoris .
Commenter la réponse de Utilisateur anonyme
Messages postés
4304
Date d'inscription
samedi 16 octobre 2004
Dernière intervention
9 mars 2018
- 27 août 2007 à 18:07
0
Merci
"J'ai séparé les deux car le programme de gestion est enorme, et windows a du mal à gérer la mémoire."






Haaa elle est pas mal celle la ... genre c'est la faute a wouindoz...

j'imagine bien si Adobe ou Discreet venaient a dire "c'est la faute a windows".

lol
Commenter la réponse de f0xi
Messages postés
297
Date d'inscription
dimanche 14 mars 2004
Dernière intervention
18 décembre 2014
- 27 août 2007 à 20:36
0
Merci
bonjour,

Peut-etre que vous avez raison, le probléme est que en effet,  le programme tout compilé fait 15 Mo, en execution, en regardant le gestionnaire de tache, on passe à 25 Mo, Il y a 40 fiches différentes que je ne peut pas assembler entre elles car elles sont différentes. Il existe surement des méthodes permettant d'optimiser le programme mais je ne les maitrise pas . Le phénoméne qui se produit est simple, lorsque j'ai ajouté une fiche suplémentaire avec toutes les fonctions associées (dans mon cas, une fiche avec des statistiques), mon programme s'est mis à planter sur les autres fiches alors que celle-ci n'avaient pas été touché. Dans les fiches, j'utilise des variables globales directement dans la section VAR, ces variables sont souvent utilisées par d'autres fiches. Sinon, j'utilise des  variables déclarées dans  la partie  public de la classe TForm de la fiche. Il arrive aussi que le programme plante à l'initialisation des fiches (Application.createForm()).

Mais l'option d'un fonctionnement déporté à beaucoup d'avantage : Un code beaucoup plus simple : chaque fonction élémentaire est dans un process à part.
Lors de la mise au point, la concentration n'est que sur un bout de code. Le Nouveau process dispose de plus de mémoire (au niveau de la pile).
Et dans mon cas, je peut archiver les impressions avant de les faire réellement.

Je ne suis pas un pro de delphi, avant je travaillait sur Turbo pascal 7 et j'ai quelque lacune sur la programmation Windows.

Mais si l'option du fichier ini entre les deux applis est la solution, je vais faire de plus ample recherche sur le partage de zone mémoire entre deux process.

Merci de vous interresser à mon probléme.
Commenter la réponse de Oniria
- 27 août 2007 à 22:02
0
Merci
Oniria :

Ton fichier fait 15 Mo et c'est ca que tu appelles une grosse application ? . Moi j'appelle cela une petite application .

Si tu vends un soft non optimisé, tot ou tard tu vas payer la facture : il faudrait mieux que tu optimises ton source maintenant pluot que d'aller au devant de sacrés problèmes juridiques (les proces ce n'est pas qu'à la télé ). En plus si tu dois retoucher ton probleme dans 6 mois ca va etre dur de s'y remettre et une sacrée perte de temps.

Tu parles d'optimisation en utilisant différents process : tu fais erreur sur toute la ligne car ce n'est pas aussi simple que cela. Appeler 2 programmes demandent plus en ressource que d'en appeler un seul qui contient les deux . Ensuite si tu as utilisés des variables globales c'est qu'effectivement mal codé : il est tres souvent possible de créer des unités contenant des fonctions et des procédures appelant des Variables globales.

Procedure TForm1.Alert;
Var
str:string;
Begin
Str : = 'WARNING, WINDOWS IS EXPLOSED';
Form2.ShowText(Str);
End;

Procedure TForm2.ShowAlert(AText:String);
Begin
ShowMessage(AText);

End;

Plutot que de faire de la bidouille, optimise ton code .
Commenter la réponse de Utilisateur anonyme
- 27 août 2007 à 22:04
0
Merci
Pardon pour la boulette : il est tres souvent possible de créer des unités contenant des fonctions et des procédures appelant des Variables locales.
Commenter la réponse de Utilisateur anonyme
Messages postés
297
Date d'inscription
dimanche 14 mars 2004
Dernière intervention
18 décembre 2014
- 28 août 2007 à 08:59
0
Merci
Bonjour,

C'est vrai, mais si windows travaille comme le dos, les variables globales sont alouées dans l'espace mémoire des données alors que les variables locale sont dans l'espace de la pile.  Si je ne dis pas de bétise,  l'espace de la pile  n'est  pas  infini,  au contraire,  il est limité.  Le fait  d'avoir  plein  de  procedure  et  de fonction  à appeler,  la pile va se remplir rapidement et déborder (on y arrive très facilement sous dos).
Sinon, FRANCKY, je ne comprend pas bien pourquoi tu me dis que l'utilisation de variable globale est mauvais.  Pourquoi  ?  Lorsque  je  crées  un objet contenant une variable, celui ci prend bien plus de place qu'une simple variable globale. De même pour une procedure par rapport à une variable.

Si je pose toutes ces questions, c'est pour justement optimiser mon prog car je suis justement pour l'optimisation de taille qui a beaucoup de vertu, Et il faut vraiment que je m'améliore dans la programmation Windows pour réussir à tenir cet objectif. J'essaye de mieux comprendre la gestion de la mémoire car je ne comprend pas très bien ce que fait windows.

En tout cas, merci pour l'intérêt.

Oniria
Commenter la réponse de Oniria
Messages postés
2684
Date d'inscription
jeudi 15 janvier 2004
Dernière intervention
26 juillet 2018
- 28 août 2007 à 10:44
0
Merci
Salut Oniria,

Peut-être une voie de recherche qui pourrait te rendre service :
utiliser la même technique que Windows, à savoir les DLL.

En utilisant des liaisons dynamiques, les DLL ne sont chargées en mémoire que lorsque c'est nécessaire.
Ca répondrait bien à ton souci de morceler ton code et en faciliterait la maintenance(?).

Mais la gestion de la mémoire reste toujours délicate avec les DLL, et Borland recommande l'utilisation des fichiers projetés en mémoire.

En tout cas, la 1ère chose à faire, comme dit Francky, c'est d'optimiser ton code. DLL ou pas, c'est incontournable.

@+
Commenter la réponse de Caribensila
Messages postés
297
Date d'inscription
dimanche 14 mars 2004
Dernière intervention
18 décembre 2014
- 28 août 2007 à 14:21
0
Merci
Bonjour,

Caribensila, tu parle des fichiers projetés en mémoire, qu'est ce que c'est ? Ce sont des TMemoryStream ?

Par contre, je suis en train d'optimiser à fond, d'ailleur, je vais poster une autre question pour me premettre de mettre la gestion d'impression dans mon soft principal.

Merci
Commenter la réponse de Oniria
- 28 août 2007 à 15:41
0
Merci
Salut,

Comme tu viens de le dire une variable est stockée en mémoire. Après utilisation la mémoire est libérée : Donc en globale la libération a lieu à la fermeture de l'application alors qu'en globale à la fin de la procédure qui l'utilise.
Commenter la réponse de Utilisateur anonyme
Messages postés
297
Date d'inscription
dimanche 14 mars 2004
Dernière intervention
18 décembre 2014
- 31 août 2007 à 09:02
0
Merci
Bonjour,

Merci à vous tous pour votre aide, justement, je vais travailler sur tout ca... Ca m'a vraiment aidé....

Oniria
Commenter la réponse de Oniria

Vous n'êtes pas encore membre ?

inscrivez-vous, c'est gratuit et ça prend moins d'une minute !

Les membres obtiennent plus de réponses que les utilisateurs anonymes.

Le fait d'être membre vous permet d'avoir un suivi détaillé de vos demandes et codes sources.

Le fait d'être membre vous permet d'avoir des options supplémentaires.