Jag håller på med ett program som kommer skicka stora mängder data mellan olika klienter, och ibland även flera stora mängder samtidigt.
Jag håller på att göra en User Control som sköter det, en sänd och mottagar modul helt enkelt och när man ska sända flera olika data samtidigt så skapar man bara en till sådan modul i programmet, med olika Index då.
Så långt fungerar det bra men min fråga är vad som är bäst rent prestanda mässigt. Att komplilera kontrollen till en .dll-fil eller ha den som den är, en vanlig User Control alltså.
När sändning/mottagning pågår kommer ju kontrollen jobba rätt mycket (det är därför jag gjort en egen kontroll av den och inte har det direkt i programmet) så vad är bäst? Enklast är ju att slippa .dll-filer om man behöver ändra eller så i kontrollen.
Om jag ska vara ärlig så förstår jag inte riktigt frågan:
Undrar du över skillnaden mellan en ActiveX Control och en ActiveX Dll? Eller över skillnaden mellan att ha koden direkt i exe:n gentemot att ha den i en separat kontroll?
Mellan att ha det i exe:n och en separat kontroll.
Jag har dock redan fått svar på pellesoft.se och det gör ingen skillnad om man inte skulle skapa dll:en i Delphi eller C, görs den i VB bar det ingen betydelse då den inte blir StandAlone då.
.. och det gör ingen skillnad om man inte skulle skapa dll:en i Delphi eller C, görs den i VB bar det ingen betydelse då den inte blir StandAlone då.
Det där låter i mina öron mest som kvalificerat svammel. Men visst, är du nöjd med det så ..
/red: För att förtydliga: Om dll:en är "standalone" (jag antar att det betyder att de använder VB:s run-time) eller inte är knappast relevant eftersom VB:s run-time redan är mappad i den process som laddar dll:en.
Kan inte du då förklara hur det egentligen står till?
Om man ifrån en exe läser in binär kod som ligger i en dll/ocx/com-komponent eller liknande så kommer man alltid att få en liten (inital) "performance-hit" gentemot om koden var lagrad direkt i exe:n. När koden väl är laddad så körs den som en del av samma process och det finns ingen skillnad.
Men å andra sidan: Anledningen till att man skriver en dll/ocx/com-komponent har ju inget att göra med prestanda. Anledningen är istället helt enkelt att man vill skapa kod-moduler som man själv (och andra) på ett smidigt sätt kan återanvända.
Vad gäller snacket om att en VB-dll inte är "standalone": Alla dll:er som överhuvudtaget gör något vettigt "laddar" och är beroende av massvis med andra dll:er (kernel32.dll, user32.dll, gdi32.dll, wsock32.dll osv ..) oavsett om de är skrivna i VB, Delphi, C++ eller något annat. I den bemärkelsen är inga dll:er "standalone" och det har heller ingen relevans för din fråga. Det verkar som om personen som skrev det tror att du vill skriva en vanlig Windows-dll, vilket du ju inte vill och vilket heller inte går i VB.
