Επικοινωνια μεταξυ 2 Εφαρμογων

[ntaryl]

Καλησπερα

Παιδια Εχω ενα εκτελεσιμο σε visual basic 6.0 πως μπορω να το κανω να επικοινωνει με ενα αλλο εκτελεσιμο το οποιο βρισκετα στο ιδιο μηχανημα αλλα σε διαφορετικο καταλογο .

Μια πρωτη ιδεα ηταν να δοκιμασω το DDE(Dynamic Data Exchange )

καποια ιδεα παρακαλω ?

καλο βραδυ

[isim]

named pipes αλλα θα μπλεξεις με windows api

[dks_1979]

Όταν λες να επικοινωνεί τι εννοείς? Να είναι ανοικτά και τα δύο και να αλληλεπιδρούν πλήρως, να "σηκώνεις" το δεύτερο με παραμέτρους ή απλά να εκτελείς το δεύτερο?

[Directx]

Σε περίπτωση IPC χρησιμοποιώ παραδοσιακά το DDE, το οποίο υπήρξε ουσιαστικά το πρώτο πρωτόκολλο IPC (πέραν του άκομψου Clipboard) που υποστήριξαν τα MS-Windows.

 

Ο λόγος που το προτιμώ είναι διότι το εργαλείο οπτικού προγραμματισμού μου, προσφέρει εύχρηστα Components που καθιστούν την χρήση του DDE εύκολη, γρήγορη και σε γενικές γραμμές αποτελεσματική.

 

Όμως το DDE αποτελεί για την Microsoft πια παρελθόν καθώς βασιζόμενο σε ανταλλαγή μηνυμάτων μεταξύ εφαρμογών (θυμάται κανείς την ReplyMessage) παρουσιάζει προβλήματα απόδοσης και απόκρισης σε ορισμένες περιπτώσεις, οπότε έχει αντικατασταθεί από άλλες σύγχρονες μεθόδους, όπως οι Pipes, COM/OLE, File Mapping κ.α.

 

Παρόλα αυτά επιμένει, διότι όπως είπα τα οπτικά εργαλεία καθιστούν την χρήση του πολύ φιλική..

 

Υ.Γ.

Αν δοκιμάσετε να προγραμματίσετε το DDE σε καθαρό Windows API θα δείτε πως είναι αρκετά περίπλοκο και σαφώς δυσκολότερο από την χρήση Named Pipes..

[bookysmell2004]

Υπάρχει και η λύση των Sockets για IPC. Μπορείς να χρησιμοποιήσεις τη βιβλιοθήκη WinSock2 ή αν δεν θες να μπλέξεις με Win32 API χρησιμοποίησε VB2005 και .NET Sockets. Να ξέρεις.... Θα χρειαστεί να παρέμβεις στα εκτελέσιμα και να τα "μάθεις" να συνεργάζονται.

 

Δεν θα πρότεινα DDX μιας και είναι παλιό και δύσχρηστο ...

 

Να αναφέρω ονομαστικά επίσης τα Mailslots (μοιάζουν με τα pipes) και το RPC (Remote Procedure Call).

 

Το File Mapping δεν είναι λύση στο πρόβλημά σου μιας και δεν παρέχει επικοινωνία μεταξύ προγραμμάτων που τρέχουν σε διαφορετικά μηχανήματα.

[Directx]

Το File mapping είναι μια λύση στο πρόβλημα του (άκομψη για εμένα πάντως) διότι θέλει IPC μεταξύ δυο εφαρμογών που τρέχουν από κοινού στο ίδιο μηχάνημα καθώς ρωτά: πως μπορώ να το κάνω να επικοινωνεί με ένα άλλο εκτελεσιμο το οποίο βρίσκεται στο ίδιο μηχάνημά άλλα σε διαφορετικό κατάλογο .

 

Εγώ πάντως για να καταλήξουμε κάπου, του προτείνω DDE καθώς υποθέτω πως η VB 6 πρέπει να το υποστηρίζει πολύ καλά, διαφορετικά αν μπορεί ας ακολουθήσει κάποια νεώτερη τεχνολογία..

 

Αυτά..

 

Υ.Γ.

Α! επίσης θυμάται κανείς το netDDE;

[ntaryl]

καλησπερα Παιδια

Ευχαριστω για τις γρηγορες απαντησεις

Και τα 2 εκτελεσιμα ειναι κατασκευη δικη μου .Την επικοινωνια την χρειαζομαι για Τοπικο επιπεδο (ιδιοα μηχανημα )

Συγκεκριμενα αυτο που θελω να κανω ειναι να υπαρχει η κεντρικη εφαρμογη με καποιες βασικες λειτουργιες απο μονη της.Ετσι να υπαρχουν σαν Plugins (extra files)τα οποια το καθενα θα κανει καποια συγκεκριμενη extra λειτουργια .Για παραδειγμα αν στο μηχανημα υπαρχει το plugin που βοηθαει για την αποστολη email τοτε στο menu της κεντρικης εφαρμογης θα υπαρχει ενεργοποιημενη αυτη η επιλογη αλλιως θα ειναι Γκριζα.

Υ.Γ Παρακαλω Δωστε καποιες πληροφοριες για τα pipes

και αν υπαρχει κανενα παραδειγμα η How to

καλο βραδυ

[Directx]

Το DDE, μιας και έχω κάνει το ίδιο για μια δικιά μου εφαρμογή (που όταν την σχεδίαζα δεν υπήρχαν εναλλακτικές λύσεις) νομίζω ότι θα σε βολέψει..

 

Για Named Pipes και VB 6 δες για αρχή εδώ:

http://support.microsoft.com/kb/177696

 

..και εδώ ένα άρθρο για όλες τις διαθέσιμες μεθόδους IPC των Windows:

http://support.microsoft.com/kb/95900/EN-US/

 

Καλή συνέχεια!

[ntaryl]

thanks man

Πολυ ωραιος

[alkisg]

AFAIK, pipes κτλ χρησιμοποιούνται όταν και οι δύο εφαρμογές εκτελούνται, δηλαδή μεταξύ processes, όχι .exe αρχείων.

 

Στην περίπτωση του ntaryl, το plugin δεν θα εκτελείται εκείνη τη στιγμή που θα θέλει να ενημερώσει το check box, απλά θέλει να το εντοπίσει και να το φορτώσει (=δημιουργήσει process) στη συνέχεια.

 

Εμένα δηλαδή μου φαίνεται πιο λογικό

1) Το plugin να είναι ένα .dll που κατά την εγκατάστασή του θα γράφει στο μητρώο το φάκελο που εγκαταστάθηκε

2) Το main .exe να κοιτάει στο μητρώο για την παρουσία του plugin και να ενημερώνει κατάλληλα το checkbox

3) Όταν χρειαστεί κλήση, απλά να καλεί την LoadLibrary για να φορτώσει το .dll και την GetProcAddress για να πάρει τη διεύθυνση της διαδικασίας που θέλει να φορτώσει. Έτσι έχει και το επιπλέον πλεονέκτημα ότι το plugin τρέχει στο ίδιο address space και έτσι μπορεί να περάσει κανονικά παραμέτρους σε όποια διαδικασία καλέσει.

 

Με τον ίδιο τρόπο δουλεύει π.χ. το 7-zip που φορτώνει τα διάφορα dll plugins για αποσυμπίεση πολλών φορμάτ αρχείων.

[Directx]

Εξαρτάται.

 

Η χρήση των DLL μπορεί να διευκολύνει μέσο “exported functions” για παράδειγμα την επικοινωνία της κεντρικής εφαρμογής (ας την πούμε Server) με το plug-in της (ας το πούμε Client) από την άλλη πλευρά όμως η αντίστροφη επικοινωνία με πρωτοβουλία του δεύτερου (Client->Server), καθίσταται σχετικά δύσκολη.

 

Βέβαια εδώ εξαρτάται τι μοντέλο Plug-in σχεδιάζεις για το λογισμικό σου..

 

Ύστερα η ανάπτυξη μιας DLL εκ φύσεως απαιτεί από τον προγραμματιστή την εφαρμογή ορισμένων κανόνων (πχ. Global Memory handles –ακα. C pointers) που καθιστούν την ανάπτυξη του λογισμικού αλλά και το συνολικό debugging της, λίγο ως πολύ ταλαιπωρία -σε αυτές τις περιπτώσεις γράφω πάντα την DLL function πρώτα για ένα EXE με όλους τους κανόνες ανάπτυξης DLL βέβαια και ύστερα αφού την ελέγξω για bugs την τοποθετώ ως export function στην DLL μου.

 

Μια κακογραμμένη DLL στο address space της εφαρμογή σου δεν είναι ότι το καλύτερο..

 

Υ.Γ.

Αντί του Registry (είναι που είναι τίγκα από μόνο του σε δεδομένα.. ) προτιμώ ένα αρχείο σε κάποιον φάκελο της εφαρμογής μου με μερικές γραμμές που περιγράφουν την θέση των DDE-Clients κτλ.

[alkisg]

Υ.Γ.

Αντί του Registry (είναι που είναι τίγκα από μόνο του σε δεδομένα.. ) προτιμώ ένα αρχείο σε κάποιον φάκελο της εφαρμογής μου με μερικές γραμμές που περιγράφουν την θέση των DDE-Clients κτλ.

 

Και αν η "server" εφαρμογή έχει εγκατασταθεί στον φάκελο P:\Some\Weird\Folder\Path πώς θα εντοπίσει η "client" εφαρμογή τον φάκελο εγκατάστασης; Ψάχνοντας σε όλον τον σκληρό, σε όλα τα δικτυακά shares κτλ;

 

Παλιότερα δουλεύαμε με .ini αρχεία στον φάκελο των Windows, αλλά τώρα αναγκαστικά για windows logo compliancy πρέπει να χρησιμοποιείται το μητρώο.

[bookysmell2004]

Το File mapping είναι μια λύση στο πρόβλημα του (άκομψη για εμένα πάντως) διότι θέλει IPC μεταξύ δυο εφαρμογών που τρέχουν από κοινού στο ίδιο μηχάνημα καθώς ρωτά: πως μπορώ να το κάνω να επικοινωνεί με ένα άλλο εκτελεσιμο το οποίο βρίσκεται στο ίδιο μηχάνημά άλλα σε διαφορετικό κατάλογο.

 

Σωστά! Πρέπει να ήταν πολύ αργά όταν το πρωτοδιάβαζα

[Directx]

Και αν η "server" εφαρμογή έχει εγκατασταθεί στον φάκελο P:\Some\Weird\Folder\Path πώς θα εντοπίσει η "client" εφαρμογή τον φάκελο εγκατάστασης; Ψάχνοντας σε όλον τον σκληρό, σε όλα τα δικτυακά shares κτλ;

 

Παλιότερα δουλεύαμε με .ini αρχεία στον φάκελο των Windows, αλλά τώρα αναγκαστικά για windows logo compliancy πρέπει να χρησιμοποιείται το μητρώο.

 

Για τον εντοπισμό του Server σε τέτοιες περιπτώσεις η χρήση του Registry είναι μονόδρομος (έχεις απόλυτο δίκιο!), όμως εδώ μιλάμε για τα plug-ins εκ-κινούμενα από τον Server τα οποία έχουν δυνατότητες Server<->Client επικοινωνίας, μην το ξεχνάς αυτό, οπότε το ζητούμενο είναι αν μπορούμε να αποφύγουμε το registry pollution εισάγοντας τα και αυτά (δηλαδή τα plug-ins) εκεί μέσα..

 

Το να γράψουμε που βρίσκεται (το path) του Server μας δεν είναι κακό, αλλά το να περάσουμε στο Registry 10-15 plug-in entries για να τα βρίσκει ο Server εγώ θεωρώ πως είναι κακό.

 

Βέβαια όπως προείπα, εξαρτάται πάντα η επιλεγμένη δομή της εφαρμογής μας..

 

Υ.Γ.

Απλά δεν μου αρέσει να μεγαλώνω το Registry -- με την VCL είναι πολύ εύκολο να τα γυρίσουμε όλα σε Registry καθώς όπως γνωρίζεις τα Registry non-visual components της είναι πολύ ικανά..

[ntaryl]

καλησπερα και παλι

Παιδια τα plugins θα βρισκονται σε ενα συγκεκριμενο φακελο

το Ζητουμενο ειναι το τι να επιλεξω για επικοινωνια μεταξυ τους

καλο βραδυ