Προς το περιεχόμενο

Αρχειοθετημένο

Αυτό το θέμα έχει αρχειοθετηθεί και είναι κλειστό για περαιτέρω απαντήσεις.

  • 0
ntaryl

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

Ερώτηση

Καλησπερα

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

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

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

καλο βραδυ

Κοινοποιήστε αυτήν την ανάρτηση


Σύνδεσμος στην ανάρτηση
Κοινοποίηση σε άλλες σελίδες

Προτεινόμενες αναρτήσεις

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

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

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

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

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

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

καλο βραδυ

Κοινοποιήστε αυτήν την ανάρτηση


Σύνδεσμος στην ανάρτηση
Κοινοποίηση σε άλλες σελίδες

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

 

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

 

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

 

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

Κοινοποιήστε αυτήν την ανάρτηση


Σύνδεσμος στην ανάρτηση
Κοινοποίηση σε άλλες σελίδες

Εξαρτάται.

 

Η χρήση των 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 (είναι που είναι τίγκα από μόνο του σε δεδομένα.. :D) προτιμώ ένα αρχείο σε κάποιον φάκελο της εφαρμογής μου με μερικές γραμμές που περιγράφουν την θέση των DDE-Clients κτλ.

Κοινοποιήστε αυτήν την ανάρτηση


Σύνδεσμος στην ανάρτηση
Κοινοποίηση σε άλλες σελίδες

ntaryl,

 

Κάποτε για να κάνω κάτι παρόμοιο χρησιμοποίησα μια πολύ απλή μέθοδο. Κάθε plugin ήταν και ένα dll. Κάθε dll εξάγει και ένα class (με το ίδιο όνομα με το dll). Έτσι μπόρεσα και έφτιαξα έναν απαριθμητή dll κάθε φορά που ξεκινάει η εφαρμογή που να διαβάζει αυτά τα plugin.

 

Στη δικιά μου περίπτωση όλα τα "plugin" εκτελούσαν ακριβώς την ίδια δουλειά με διαφορετικό τρόπο και ήταν γραμμένα αποκλειστικά από μένα, συνεπώς ήταν εύκολο να τα χρησιμοποιήσω μιας και ήξερα εκ των προτέρων το που χρησιμοποιούνται και πως.

 

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

 

Όσων αφορά runtime dynamic linking δεν μπορώ να σε βοηθήσω μιας και δεν ξέρω Vb 6.0 αλλά είμαι σίγουρος πως θα βρεις αρκετό υλικό.

 

Για την αναγνώριση του φακέλου στον οποίο βρίσκονται τα plugins μπορείς απλά να τον διαβάζεις από ένα αρχείο σε text μορφή παρέα με το εκτελέσιμο ή ακόμα να κάνεις κάτι σαν αρχείο ρυθμίσεων της εφαρμογής με τις βασικές παραμέτρους του γραμμένες σε αυτό.

Κοινοποιήστε αυτήν την ανάρτηση


Σύνδεσμος στην ανάρτηση
Κοινοποίηση σε άλλες σελίδες
Και αν η "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 της είναι πολύ ικανά.. ;)

Κοινοποιήστε αυτήν την ανάρτηση


Σύνδεσμος στην ανάρτηση
Κοινοποίηση σε άλλες σελίδες

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

 

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

 

Αυτά..

 

Υ.Γ.

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

Κοινοποιήστε αυτήν την ανάρτηση


Σύνδεσμος στην ανάρτηση
Κοινοποίηση σε άλλες σελίδες

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

 

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

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

 

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

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

 

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

:)

Κοινοποιήστε αυτήν την ανάρτηση


Σύνδεσμος στην ανάρτηση
Κοινοποίηση σε άλλες σελίδες

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

Κοινοποιήστε αυτήν την ανάρτηση


Σύνδεσμος στην ανάρτηση
Κοινοποίηση σε άλλες σελίδες
Υ.Γ.

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

 

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

 

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

Κοινοποιήστε αυτήν την ανάρτηση


Σύνδεσμος στην ανάρτηση
Κοινοποίηση σε άλλες σελίδες

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

 

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

 

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

 

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

 

Υ.Γ.

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

Κοινοποιήστε αυτήν την ανάρτηση


Σύνδεσμος στην ανάρτηση
Κοινοποίηση σε άλλες σελίδες

Συγνώμη εάν προτάθει και δεν το πρόσεξα

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

 

Σε προειδοποιώ ότι αυτή η μέθοδος είναι "μπακαλίστικη" και μπορεί να αποδειχθει πιο μάπα από ότι φένεται αλλά σκέφτικά να το γράψω μιά και εγώ αυτό θα έκανα.

Κοινοποιήστε αυτήν την ανάρτηση


Σύνδεσμος στην ανάρτηση
Κοινοποίηση σε άλλες σελίδες

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

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

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

καλο βραδυ

Κοινοποιήστε αυτήν την ανάρτηση


Σύνδεσμος στην ανάρτηση
Κοινοποίηση σε άλλες σελίδες
×
×
  • Δημιουργία νέου...