Hej Ja Matthias kom igen ... (antar att du syftar till MS inlägg;) string fel_namn = "Matthias"; >Hur skall man göra för att dra nytta av dessa funktioner i C#? Skall inte allt kunna användas överallt (hänvisar till tidigare diskussioner)? Men om det är en ASP.NET sida? Det är ju inte alltid man vill kompilera en dll. I ASP.NET ligger väl 'globala referenserdeklarationer' i config-filen? Kolla i machine.config i ditt .NET directory i C:\winnt Är det <add assembly.../> du tänker på eller? Fick inte till det riktigt iallafall... Hur är det förresten med prestandaskillnader på ett vs-projekt och ett "Notepad-projekt"? VS genererar ju till synes en hel del onödig kod. vad för onödig kod genererar vs ?? Själv har jag inte upptäckt ngt som är speciellt onädigt i det som den slänger upp .. Ordet 'onödig' beror på okunnighet från min sida. Jag syftar på code-behind conceptet. Speciellt om man gör en väldigt liten sida så känns det som overkill att det skapas en aspx, en aspx.cs och en dll (plus lite till). Så i detta läge undrar jag om det ger nån vinning...? Nu e inte jag speciellt insatt i asp.net, men är du säker på att du måste ha aspx.cs ?? inte overhead -overkill. Alltså, blir lite onödigt komplext... Men skit samma, jag är intresserad av en förklaring om varför det är bra, inte en argumentation ang om det är bra eller inte.stränghanteringsfunktioner i C#
Jag tyckte att det skulle vara trevligt att använda lite vb6 funktioner, som tex Left, och hittade följande exempel i .net sdk dokumentationen
subString = Microsoft.VisualBasic.Left(myString, 5)
och det fungerade ju bra om jag körde vb, men inte i C#.
Hur skall man göra för att dra nytta av dessa funktioner i C#? Skall inte allt kunna användas överallt (hänvisar till tidigare diskussioner)?
Om det nu bara går att använda dessa funktioner i VB, finns det nåt liknande till C#?Sv: stränghanteringsfunktioner i C#
Hur många stränghanteringsfunktioner finns det i C# jämfört med VB :)Sv: stränghanteringsfunktioner i C#
...Men borde man inte kunna komma runt det på nåt sätt? funktionen som finns i Microsoft.VisualBasic namespace borde väl rimligtvis ligga i en class (eller?) och då bör man kunna instansiera den för att sedan använda funktionen.
Fast det är klart; det går ju att göra rätt mycket med Substring -funktionen...
Men ändå!Sv: stränghanteringsfunktioner i C#
string rätt_namn = fel_namn.Substring(0, 4) + fel_namn.Substring(5, 3);
:-)
MSSv: stränghanteringsfunktioner i C#
Detta bör fungera
subString = Microsoft.VisualBasic.Strings.Left(myString, 5);
Du måste även komma ihåg att referera till Microsoft.VisualBasic.dll, antingen med /r parametern om du kompilerar från kommandoraden, eller genom att lägga till den till References i Solution Explorer i VS.NET.
MSSv: stränghanteringsfunktioner i C#
Varför är det så förresten, att man måste lägga till en referens till Microsoft.VisualBasic? Det behöver man ju tex inte med System.Data... Eller är dessa inte rena .net klasser?
Angående ditt Substring -inlägg så skrev jag redan innan
>>Fast det är klart; det går ju att göra rätt mycket med Substring -funktionen...Sv: stränghanteringsfunktioner i C#
Sv: stränghanteringsfunktioner i C#
fast skapar man ett webbprojekt i vs är det lätt att lägga till referensen.Sv: stränghanteringsfunktioner i C#
Vet ni nått om detta?Sv: stränghanteringsfunktioner i C#
Sv: stränghanteringsfunktioner i C#
Sen fattar jag inte varför .cs filen skall finnas med i slutprodukten om det ändå skapas en dll? Skulle det inte kunna räcka med den?
Förmodligen har väl Microsoft tänkt igenom det och det är säkert den bästa lösningen, men det hade ändå varit trevligt med en förklaring.Sv: stränghanteringsfunktioner i C#
Hela konceptet med code-behind är att du istället för att tolka en script sida rad för rad, så kompilerar du din sida till IL kod som sedan CLR'n exekverar.
Dessutom ser jasg inte antalet filer som någon form av overhead, varför skull det vara det?Sv: stränghanteringsfunktioner i C#
Angående om man behöver cs-filen eller inte så behövs den. iallafall om man inte gör nån slags specialare, men då är man ju där igen...