HDSoftware Skrevet 30. september 2008 Del Skrevet 30. september 2008 Folkens! Gitt følgende situasjon: Program1 er skrevet i Clarion (eller hva som helst annet egentlig) Program2 er skrevet i C#/.NET Program2 er selve starteren som tar seg av innlogging, backoffice, reports etc., men avhengig av innstillinger så sparker det igang hovedprogrammet (Program1) som er en helt ordinær EXE fil. Dagens løsning er bygget slik at Program2 logger inn bruker. Starter Program1 og avslutter. Så ved behov, vil Program1 starte Program2 med dertil egnede parametere, for å sette igang forskjellige hendelser. Denne løsningen er både klønete og håpløs å holde orden på. Jeg ser derfor for meg følgende nytt alternativ: Program2 starter opp, logger inn bruker og starter Program1, for så å legge seg i SystemTray. Program1 oppretter en komunikasjonslinje til Program2 og dermed kan de snakke sammen og utveksle data og funksjoner. Dette løste jeg tidligere ved å bruke DDE, men DDE er vel ikke akkurat det som gjelder for tiden ;-) Jeg kan også bruke OLE, men det krevert at jeg registrerer .NET programmet og det er håpløst fordi dette skal kjøre på terminal servere etc. der IT personellet neppe vil ha noe av slikt. Såh - jeg kaster derfor ballen videre: Hvordan ville dere løst dette? Kan jeg bruke TCP/IP og LocalHost? Vil i så fall dette skape problemer med brannmurer? Kan jeg bruke Named Pipes? Vil det skape Brannmur problematikk? Andre løsninger tas imot som vanlig med stormende jubel!!! Lenke til kommentar
GeirGrusom Skrevet 30. september 2008 Del Skrevet 30. september 2008 Det er også mulig å bruke windows message queue, som også er ganske enkelt og greit å få til. Men pipes er vel den mest elegante løsningen. Lenke til kommentar
Manfred Skrevet 30. september 2008 Del Skrevet 30. september 2008 MS MessageQueue er både enkelt og effektivt, og er innebygget i Windows Server. Via message queuing kan man sende objekter eller verdier inn i en kø, som det andre programmet kan stå og lytte på Lenke til kommentar
HDSoftware Skrevet 30. september 2008 Forfatter Del Skrevet 30. september 2008 Det er også mulig å bruke windows message queue, som også er ganske enkelt og greit å få til. Men pipes er vel den mest elegante løsningen. Da skal jeg forske litt på Pipes. Hvis dette ikek skaper problemer i brannmurer så er nok dette veien å gå. Var også inne på tanken å bruke Windows Message Queue så jeg får vel kikke litt på den også. Må velge det som egner seg mest og det jeg trenger er full komunikasjon mellom disse programmene. Eksempelvis skal jeg gjøre fritekst søk i dokuementer og skal returnere til det andre programmet en liste over alle dokumenter som inneholder søkebegrepene. Denne lista kan være enorm. Ser for meg at Windows Message Queue kansje ikke er løsningen av den grunn, men jeg vet for lite om den. Finner vel dette ut... Takker iallefall Lenke til kommentar
HDSoftware Skrevet 1. oktober 2008 Forfatter Del Skrevet 1. oktober 2008 MS MessageQueue er både enkelt og effektivt, og er innebygget i Windows Server. Via message queuing kan man sende objekter eller verdier inn i en kø, som det andre programmet kan stå og lytte på joda, det er lagt ved i XP også, men jeg kan ikek benytte en teknologi som krever en administrasjon på selve maskinen. Når jeg leverer software så er det en SETUP som må gjøre alt og ingen innblanding av noe som helst er aktuellt. Ser at Message Queue ikke blir installert som default på XP så derfor må jeg nok se mere på named pipes tenker jeg, med mindre du har et forslag... ;-) Lenke til kommentar
Manfred Skrevet 1. oktober 2008 Del Skrevet 1. oktober 2008 Nei, det er ikke installert som standard på server en gang, og krever en AD eller noe slikt, så det er litt klønete på klientmaskiner, dersom de ikke står i et domene. Så da er det named pipes, ellers så kan du jo kommunisere med Atoms da, men det er begrenset hvor mye informasjon som kan inn der Lenke til kommentar
HDSoftware Skrevet 1. oktober 2008 Forfatter Del Skrevet 1. oktober 2008 Nei, det er ikke installert som standard på server en gang, og krever en AD eller noe slikt, så det er litt klønete på klientmaskiner, dersom de ikke står i et domene. Så da er det named pipes, ellers så kan du jo kommunisere med Atoms da, men det er begrenset hvor mye informasjon som kan inn der hehe, mn jeg fant på noe annet i stedet. Og det er rett og slett subclassing av WindowMessages. Jeg lagde et testeprogram i Clarion og der fikk jeg til å sende meldinger fra det ene programmet til det andre. Fungerer helt topp. Gjennstår bare å klare å få til dette i C# også... Lenke til kommentar
Manfred Skrevet 1. oktober 2008 Del Skrevet 1. oktober 2008 Du får poste løsningen når den foreligger Lenke til kommentar
HDSoftware Skrevet 2. oktober 2008 Forfatter Del Skrevet 2. oktober 2008 (endret) Du får poste løsningen når den foreligger Will do, i mellom tiden kan jo du fortelle meg hvordan du bruker Messaging Queues og hva disse kan brukes til.. edt: Og ikek minst - kan installasjonen av denne tjenesten automatiseres? Endret 2. oktober 2008 av HDSoftware Lenke til kommentar
Manfred Skrevet 2. oktober 2008 Del Skrevet 2. oktober 2008 (endret) Installasjonen veit jeg ikke om kan automatiseres, da dette er et windows-komponent. Og den krever også at maskinen enten kjører AD eller står satt opp i et registrert domain (altså ikke en workgroup). Når først dette er OK, så er det ikke store jobben som gjøres for å sende og motta meldinger: // Starten, .\\ angir at køen er lokalt på maskinen if(!MessageQueue.Exists(".\\myQueue")) MessageQueue.Create(".\\myQueue"); using(MessageQueue mq = new MessageQueue(".\\myQueue")) { // Meldingene kan inneholde et vilkårlig objekt, men vi velger en string string myMessageContent = "Heisann hoppsann"; using(Message myMessage = new Message(myMessageContent, new BinaryMessageFormatter())) { mq.Send(message); } } Og for å motta: using(MessageQueue mq = new MessageQueue(".\\myQueue")) { mq.Formatter = new BinaryMessageFormatter(); using(Message msg = mq.Receive()) //Denne står og venter til det kommer noe { MessageBox.Show(msg.Body as string); } } Noe slikt... Du kan også sette på prioritet på en melding og slikt (msg.Priority = MessagePriority.High f.eks) Endret 2. oktober 2008 av Manfred Lenke til kommentar
Anbefalte innlegg
Opprett en konto eller logg inn for å kommentere
Du må være et medlem for å kunne skrive en kommentar
Opprett konto
Det er enkelt å melde seg inn for å starte en ny konto!
Start en kontoLogg inn
Har du allerede en konto? Logg inn her.
Logg inn nå