THIERRY TILLIER a écrit :
Bonjour,

Il y a peut-être mieux mais je propose ceci :
L'application A écrit dans un fichier type ini et met à une "variable" à vrai
La procédure de l'application B va lire cette même variable (via un timer toutes les secondes), si la "variable" est à vrai alors exécute la procédure et on met la "variable" du fichier ini à faux.
Ou bien cette variable est dans un fichier de données.

Cela suppose que les deux applications soient lancées.
Voilà ce qui me vient à l'esprit, sans vouloir faire trop compliqué.


Coucou THIERRY,

Je ne pense pas que cela soit chose à faire.

J'insite sur mutex + zone mémoire partagé :




--
In üs we trust - #92i

Pistolet en Belgique - #DébrouillardAJamais
Wódka en Pologne - #RegardeLàOùJeSuisCarJeSuisLàOùIlFautÊtre
Message modifié, 18 octobre 2018 - 15:04

@Charly CANDO

Je te remercie beaucoup de t'inquiéter de mes développements futurs, mais je n'en ai pas besoin. Je remarque d'ailleurs, après m'être longuement documenté, que j'applique une grande partie de ces principes sans même les avoir lus, ce qui prouve que je dois avoir une once de bon sens.

Je vois que ta bible est le TDF, grand bien te fasse, mais il ne faut pas tout prendre pour argent comptant. Le principe de LEAN que tu cites est principalement de factoriser le code au maximum pour écrire le moins de code possible. Cela a aussi des effets pervers de complexifier un code qui au départ était simple en y rajoutant des cas tordus, avec le risque de ne jamais réussir à le debugger. C'est aussi préciser dans la méthode LEAN.

Lorsque je prévois un développement, j'essaye de penser au plus de choses possibles sans me perdre dans les détails.

De plus je doute que coder des sockets soit plus long et contraignant que la zone mémoire, les mutex et les threads. Dans la méthode des sockets qui mettra autant de temps que celle que tu proposes, si le cas se présente, je pourrais l'utiliser sur un réseau de machines sans modification. Dans ton cas, il faudra tout reprendre et repartir de zéro, ce qui va à l'encontre des principes de LEAN que tu sembles affectionner tout particulièrement. Cela entraîne un coût supplémentaire de développement, non prévu par le client, qui peut parfois être extrêmement important.

Maintenant nous avons tous une façon différente de développer et à priori nous n'avons pas la même.

Je te conseille donc de te renseigner correctement lorsque tu annonces quelque chose et ne pas te baser que sur une vidéo pour tes recommandations.

Pour info, voici quelques liens sur LEAN:
http://www.disciplinedagiledelivery.com/lean-principles/
http://agile-lean-et-compagnie.com/2014/01/lart-du-lean-software-developpement/
https://agilevelocity.com/lean/7-principles-of-lean-software-development/
https://www.cs.colorado.edu/~kena/classes/5828/s12/presentation-materials/schweikertmarcbubernakchris.pdf
http://ses-perso.telecom-paristech.fr/LEANSI/2008-11%20LeanSI%20%2030%20min%20-%20Yahoo.pdf

et même un petit bouquin en pdf pour tes longues nuits d'hiver: http://ptgmedia.pearsoncmg.com/images/9780321150783/samplepages/0321150783.pdf

Bonne lecture, tu comprendras assez rapidement que ce que tu proposes va à l'encontre de ton principe de la méthode LEAN.

--
Cordialement,

Philippe SAINT-BERTIN

Dans une autre vie (C, C++) pour répondre à ce genre de problématique, la solution retenu était les canaux nommés (PIPE), ils fonctionnent aussi en réseau

Bonjour,

On utilise les fonctions DDE pour faire communiquer les applications que nous développons.