Halloj, många saker i luften nu:)

Jag har två progs gjorda i VB6, dessa är fristående men arbetar ihop.
Det ena är ett GUI och det andra är en modul som bara snurrar och gör lite saker.

Nu kör jag timers på dessa och det blir fördröjning på det modulen gör o det jag ser i gui:t.
Jag vill att det modueln gör ska synas direkt i gui:t.

Idag har jag denna ful-lösning: En textfil som får värdet 1 när modulen gjort nått o gui:t läser via timer o ser den "1" så uppdaterar den (från deras gemensamma databas) o så skriver den "0" i textfilen.

Detta funkar bra tills det krockar. vilket händer för ofta.

Hur ska jag få detta att funka på bästa sätt?

/B

Det första jag tänkte på är att skriva i minnet som båda prpgrammen använder (har dock ingen kod).När det gäller textfilen, öppnar du med:

open "kalle.txt" for input shared access read as #1 ?

Om inte, gör det...

Hej P.

"open "kalle.txt" for input shared access read as #1 ? "
Antar att det är som det står, den delar?

/B

Mmm, flera program kan läsa i den samtidigt utan att få något fel med exklusiv läsning som sker i traditionella fall.

Tack!

/B

En alternativ väg är att göra en activex-exe av det ena programmet som kan skicka events till det andra, då kan man dels köra de båda programmen fristående men också som instanser av varandra. Ett annat sätt är att lära sig DDE och använda det, men det suger (dock inte lika hårt som textfiler)...

Jag tyckte pelles exempel verkade passa mig, dock undrar jag över detta med FSO som jag använder för att läsa filen med:

<code>
Dim size As Double, textData As String
Dim CrLf, st, fso

Set st = CreateObject("ADODB.Stream")
Set fso = CreateObject("Scripting.FileSystemObject")


size = fso.GetFile(FileName).size

st.Open
st.Charset = "windows-1252"
st.LoadFromFile (FileName)

textData = st.ReadText
st.Close
OutPut = textData
</code>

Kan jag ändra i denna så den öppnar på annat vis? Som det är nu låser den tydligen filen.

Jag kan visserligen köra pelles exempel men GÅR det att öppna med FSO på annat vis?

/B

Du kan ju alltid använda MB InterProcess Control.

här kommer lite info och länk

This control lets you have two applications that communicate with each other. Just select the target application by its handle or partial/whole caption, set the string or the Long data to send, and then call the Send method. The target application - that must host an instance of the InterProcess control - receives a DataReceived event and can therefore retrieve the data sent and the sender's handle and caption, and even reply to the message.

http://www.vb2themax.com/mbgallery/Controls.aspx

hej, din länk verkar inte funka?

Det verkade ju bra i sig men det måste ju gå bra me pelles variant.

Fler tips mottages varmt /B

Jadu; jag har inga problem med att få http://www.vb2themax.com/mbgallery/Controls.aspx att fungera. Själv tycker jag att det är ett snyggt sätt att skicka saker på; ska nog se ifall man kan göra något liknande i .net också...

[EDIT]
Om nu någon skulle vara intresserad så hittade jag något liknande i .net; http://www.vbaccelerator.com/home/NET/Code/Libraries/Windows_Messages/Simple_Interprocess_Communication/article.asp
[/EDIT]

Systemvariabler?

Hur funkar det då?

/B

Hej
Det enklaste för att komma förbi dina problem med att det "krockar" är ju att lägga "text-filen" i din databas i stället. Där kan du enklare hantera flera användre samtidigt.

Mvh
JonBer

Hur stora datamängder är det tal om?
Om det är små datamängder är det ingen vidare bra idé att använda "databaser"
(förresten är en textfil en databas).
Systemvariabler fungerar ju perfekt, och de lever bara "för stunden" (så länge inte datorn startas om eller loggas ut(antagligen)).

Om du skall använda typ en accessdatabas så måste du ha kontroller som skall laddas och ditt program kommer genast att kräva mer minne, bli långsammare (inte för att dagens program brukar vara speciellt tidskritiska men...)
Handlar det om större datamängder (typ mer än 256 byte?) är väl textfiler att föredra då systemvariabler istället blir instabilt.

Med vänliga hälsningar
EBCDIC

Jag förespråkar fortfarande en ActiveX-Exe och en vanlig Exe-version av programmen, på så vis är det skitenkelt att kommunicera mellan dom, ActiveX-exen får innehålla Egenskaper och Händelser som det andra programmet sen utnyttjar för att se vad respektive berätta vad som händer...

Jag brukar lösa detta genom att använda sockets.

Började med det en gång på OS/2 och Unix tiden och har fortsatt under windows, även i VB. Fungerar stabilt och bra (till skillnad från t.ex. DDE) och dessutom både mellan olika maskiner och inom samma maskin utan ändringar i koden.

Har den trevliga egenskapen att disconnect osv. hanteras snyggt och inte orsakar hängningar i delsystemen som många andra lösningar gör.

Tänk bara på att välja en port som inte används av någon känd funktion.

Hej på er, kort o gott:

Jag har redan en databas som jag läser o skriver data i.
vi har proggA & proggB.

ProggA skriver ett värde i databasen, proggB ska läsa detta o endast läsa databasen då det verkligen FINNS nått o läsa. Den ska då känna värde nånstans att "nu ska du läsa".

ibland skriver proggB o då ska proggA läsa o göra sin uppdatering.

Nu har ja testat me textfil & registernyckel, inget funkar bra.

Skulle ja kunna köra me en DLL som ja ger värden i? ProggA ger DLL:en värdet o proggB kollar i samma DLL?

/B

Men läs mitt förslag, med det kan du skicka meddelande mellan programmen för att meddela om ProgA eller ProgB gjort något i databasen, du behöver inte ens ta omvägen genom databasen för att lösa detta problemet. För övrigt så är förslaget med sockets också ett mycket bra förslag om lite besvärligare att koda.

Hej, det va ditt förslag jag tänkte på när jag snackade om DLL:en, är inte det samma sak som en activeX?

Edit:
Jag har nu läst lite kring detta o ser en LITEN skillnad på activeX.EXE & .DLL, namnet!
Jag förstår inte hur mitt proggA som jobbar som en service ska kunna skicka data till en annan exe (proggB) som är ett gui?

jag behöver nog få mer info kring detta för att förstå detta.


det enda ja vill är att dessa 2 proggs, A & B ska kunna säga till varann när det e dags o kolla i databasen.

EDIT2...känns som mycket jobb bara för att få lite snabbhet i detta. tittade på msdn´s coffeemonitor-proj, det e ju hur mycket kod som helst!

/B

Testa
--------
Private Declare Sub CopyMemory Lib "kernel32" Alias "RtlMoveMemory" (dest As _
Any, source As Any, ByVal bytes As Long)

' write a byte into memory

Sub PokeB(ByVal address As Long, ByVal value As Byte)
CopyMemory ByVal address, value, 1
End Sub

' write an integer into memory

Sub PokeI(ByVal address As Long, ByVal value As Integer)
CopyMemory ByVal address, value, 2
End Sub

' write a Long value into memory

Sub PokeL(ByVal address As Long, ByVal value As Long)
CopyMemory ByVal address, value, 4
End Sub


---------
Private Declare Sub CopyMemory Lib "kernel32" Alias "RtlMoveMemory" (dest As _
Any, source As Any, ByVal bytes As Long)

' read a byte from memory

Function PeekB(ByVal address As Long) As Byte
CopyMemory PeekB, ByVal address, 1
End Function

' read an integer from memory

Function PeekI(ByVal address As Long) As Integer
CopyMemory PeekI, ByVal address, 2
End Function

' read a Long value from memory

Function PeekL(ByVal address As Long) As Long
CopyMemory PeekL, ByVal address, 4
End Function

Sök lite på RtlMoveMemory för att ta reda på hur du bestämmer vilken adress du skall använda.

<b>Jag har nu läst lite kring detta o ser en LITEN skillnad på activeX.EXE & .DLL, namnet!</b>

Skillnaden är större, en ActiveX-Exe kan du köra som ett program eller en ActiveX-kontroll.

<b>Jag förstår inte hur mitt proggA som jobbar som en service ska kunna skicka data till en annan exe (proggB) som är ett gui?</b>

Genom att ditt ProggA instancierar ProggB som en ActiveX så kan ProggB användas som både en ActiveX och ett normalt program parallellt, enda regeln är att ProggA alltid är den som ska instanciera och starta upp ProggB.

För övrigt är Sockets ett enkelt sätt att komma runt hela problematiken precis som nämnts tidigare, för exempel på sådana kan du kika på chatprogrammet som byggs med WinSock-kontrollen, problemet är att den inte är helt klockren och inte lika lätt att få att funka.

Tack grabbar.

Med sockets är det en winsock vi snackar om här? Det kanske är en enklare väg för mig då jag sysslat en del me dessa:)

Ska ge mig på det genast.

EDIT: Fast.....om ja har proggB som e "formulärlöst" då? Då lär ju inte winsock funka?!

/B

Kan du inte dra upp ett formulär som du döljer?
Annars får du koda direkt mot winsck.dll eller vad den heter.
Sök efter det på Google så hittar du nog nått.


Thomas

ska kolla:)

/B

Jag gillar själv att använda mig utav sockets för att kommunicera...
Men jag gillar absolut inte winsock kontrollen. trög och opålitlig.
Därför har jag skapat en TCP server och client klasser som gör vad som behövs.
Dessa klasser kan du antingen kompilera som en activeX.dll eller integrera med ditt projekt direkt.
Du hittar källkoden här http://www.planet-source-code.com/vb/scripts/ShowCode.asp?txtCodeId=52837&lngWId=1

Dessa klasser använder jag i flera projekt, även i NT-Services. Kan kanske vara nåt för dig ?

Halloj, jag fixade saken med winsock-kontrollen:)

Den länken om TCP var intressant o ska kollas på.

Tackar:)


/B

Nu börjar ja få trassel me dubbelposter...som SvenPon har jag läst.

/B