Hej ! Rickard, Hej och tack för det snabba svaret! Hej Rickhard. Rickard, Johan och Andreas jag tackar er ödmjukast - jag hade aldrig löst det här själv. Det funkar helt klockrent och ni skrev väldigt pedagogiskt så jag förstod vad det var som hände. Skulle ni vara här nu skulle ni få varsin stor puss !!! Rickard, Rickard, Andreas, Rickard, Okej då förstår jag, jag trodde nämligen att när man satte ett objekt till nothing - Rickard, Serverkontroll - Läsa från egen fil
Jag håller på att skriva en sådan "composite" serverkontroll och har fastnat på en grej.
Istället för att bygga upp kådsnuttar manuellt och lägga till med Page.RegisterClientScriptBlock,
så vill jag läsa allt från en textfil till en sträng, och lägga till denna sträng.
Det är så jobbigt med alla citattecken hit och dit, när man ska redigera kåden.
Mkt bättre att då ha javascriptkåden i en enskild fil.
Så jag lade helt enkelt till en custom.js fil i mitt serverkontrollprojekt, men frågan är hur kommer jag åt denna fil?
Alla sökvägar i Page.Request objektet kommer ge fel address eftersom de visar bara på
webprojektet som använder min serverkontroll.
Så hur sjutton hittar jag till katalogen där min serverkontrolls .dll fil ligger? för det är väl där jag måste läsa in min textfil ..
Hoppas ni förstår mitt problem och att det går att lösa ...
MVH RickardSv: Serverkontroll - Läsa från egen fil
Du använder <b>Server.MapPath</b> för att få fram relativasökvägar till ditt webbprojekt, dvs sökvägar som börjar med ditt webbprojekt som root. För att se arbeta med filen så använder du dig av diverse klasser från <b>System.IO</b> namnrymden.Sv:Serverkontroll - Läsa från egen fil
Problemet är dock att textfilen tillhör själva serverkontroll projektet (eget kompilerat projekt). I slutändan blir det ju en kompilerad dll, som man t.ex kan dra in till en webform. (Den läggs upp i toolbar i designläge efter man angett referens till denna dllfil)
Så egentligen så spelar webprojektet som används ingen roll i detta sammanhang..
Min undran är alltså var denna textfil tar vägen och hur jag kommer åt den från mitt serverkontrollprojekt... den kanske försvinner nånstans på vägen när projektet kompileras ? :o
Inte den blekaste, ...
Har försökt med dessa sökvägar för att hitta textfilen men det går inte
system.Environment.CurrentDirectory
system.AppDomain.CurrentDomain.BaseDirectory
......
Någon som vet?Sv: Serverkontroll - Läsa från egen fil
Din fil följer inte med själva kontrollen om det inte är så att du embedar den till din DLL (med andra ord ser till så den bakas in som en resurs.) att föredra i detta fall.
Annars får du kopiera filen för hand o lägga den i ditt web projekt där din kontrol kommer leta efter den. ex. ~/data/mintextfil.txt eller liknande.
Mvh JohanSv:Serverkontroll - Läsa från egen fil
Om du nu har gjort som Johan sa - lagt till din fil som en Embedded Resource i ditt projekt (genom att ändra Build Action på filen i Visual Studio) så kommer du åt filen genom att använda <b>GetManifestResourceStream</b> metoden som finns på ditt <b>Assembly</b> objekt. Du kommer lämpligast åt din assembly genom att använda <b>GetExecutingAssembly</b> metoden, som är en statisk metod på Assembly klassen.
Allt detta hittar du i <b>System.Reflection</b> namnrymden. Till GetManifestResourceStream metoden skall du skicka in namnet på din fil, tillsammans med den namnrymnd som den hamnar i. Om du root-namnrymden i ditt projekt heter MinRoot och filen heter MinJS.js så skickar du med MinRoot.MinJS.js som värde.
GetManifestResourceStream returnerar en <b>Stream</b> som du sen kan skicka vidare till t.ex en <b>StreamReader</b>, som du hittar i <b>System.IO</b> namnrymden, för att läsa av din fil.
Hoppas det löser sig!Sv: Serverkontroll - Läsa från egen fil
Såhär blev då den slutgiltiga lösningen, då filen heter "customjs.js" :
<code>
'** register my custom javascript **
Dim rdr As IO.StreamReader
Dim asm As System.Reflection.Assembly
Dim cjs As String
asm = asm.GetExecutingAssembly()
rdr = New IO.StreamReader(asm.GetManifestResourceStream("AvcTree.customjs.js"))
cjs = rdr.ReadToEnd()
Page.RegisterClientScriptBlock("MyJS", cjs)
rdr.Close() : rdr = Nothing
asm = Nothing
cjs = Nothing
</code>
Hoppas att andra kan ha nytta av lösningen, tack än en gång för svaren och tiden ni bjöd på!Sv:Serverkontroll - Läsa från egen fil
Som "tack" för mitt deltagande i ditt problem så skall jag kräva en motprestantion från din sida. Detta gör jag i egenskap av Moderator här på pellesoft. Vad jag skulle vilja att du gör är att du från och med nu tar för vana att markera dina trådar enligt deras gällande status.
Detta gör du genom att markera trådar som <b>Löst</b> om de innehåller fråga + ett svar som du är nöjd med, samt som <b>Stängd</b> om du har startar en tråd som du inte fick något svar som du var nöjd med men har slutat att övervaka den tråden.
Dessa små saker gör det väldigt mycket enklare för andra besökare, både de som letar efter svar själv men även de som hjälper till att svara på frågor, genom att de enkelt kan se statusen på tråden. Du hjälper även de som svarat i din tråd med att förbättra sin statistik då deras "medverkar i lösta trådar" räknare ökar. Sv:Serverkontroll - Läsa från egen fil
Vill även passa på och ge en del små tips på hur du kan optimera din kod. Eftersom GetManifestResourceStream finns som en statisk-metod, dvs en metod som du kan anropa direkt på klassen och inte behöver ett objekt, så finns det ingen vits att först skapa ett <b>Assembly</b> objekt.
'** register my custom javascript **
Dim rdr As IO.StreamReader
Dim cjs As String
rdr = New IO.StreamReader(Assembly.GetExecutingAssembly().GetManifestResourceStream("AvcTree.customjs.js"))
cjs = rdr.ReadToEnd()
Page.RegisterClientScriptBlock("MyJS", cjs)
rdr.Close()
Vidare behöver du inte sätta dina variabler till <b>Nothing</b> som du behövde i VB då .NET använder något som heter <b>Garbage Collection</b>, läs mer om detta här http://www.pellesoft.se/documents/pageblank.aspx?id=12004
Ha de bra!
Sv: Serverkontroll - Läsa från egen fil
Tackar, men:
Angående garbagecollectorn, är det inte bättre att stänga mina objekt på en gång och tvinga dem till nothing, (med tanke på att det bl.a är en instantierad fil-stream läsare, för att snabbt fria upp minne) ?
Vet att collectorn ligger och kör sina disposes och hämtar skräp då och då, men det kändes bättre att tvinga upp dem på en gång .....Sv:Serverkontroll - Läsa från egen fil
Att stänga dem och anropa <b>Dispose</b>-metoden på de objekt som stöder det, är något som du alltid skall göra. Men att sätta dem till <b>Nothing</b> medför inget, eftersom det sker automatiskt när variablen kommer utan för <b>scope</b>.
Med scope innebär den region av kod som variablen kan nås, t.ex om du skapar en variable inne i en metod så är den enbart tillgänglig inne i samma metod, dvs den har metod-scope. Så när en variabel hamnar ur scope, t.ex när du lämnar metoden, och det inte finns några andra referenser till den (det skulle det kunna finnas om du skickat vidare en lokal variablen (om det är en reference-type) någon annanstanns och det då finns ytterligare en aktiv root kvar till minnet som variabeln använder. Även i detta fallet skulle <b>Nothing</b> inte göra någon skillnad för det finns en aktiv root någon annanstanns.Sv: Serverkontroll - Läsa från egen fil
så anropades .Dispose funktionen automatiskt först...... Inte tvärtom :o
Självklart så försöker jag alltid stänga objekten (t.ex ado.net objekt, streamläsare etc)Sv:Serverkontroll - Läsa från egen fil
Var bara försiktig när du kör MemmoryStream, för den är lite annorlunda gällande Close.
Nu kör du ju inte denna, men det kan ju komma tiden då du vill. Det som då händer när du kör close är att datan du nyttjar oxå dör. Ex om du kör MemmoryStrem till en Bitmap så dör denna bitmap om du kör close. Lite knöligt det där. Dock är det ju skillnad om man kör stateles eller kör i state.
DVS, ha kontakt med huvudkällan eller ej.
Web är stateless (tillståndslöst) medans winform hållet state (tillstånd).
Nu har vi nog fått in de flesta paranteser här ;-) Så snart är du Stream Master på .Net ;-)
Mvh Johan