VB.NET eigen functie om spaties in array te vervangen

[Montaner]

Hallo,

Heb een eigen functie gemaakt om meerdere waardes van een bepaald object te filteren van spaties (en eventueel andere zaken). Zie hieronder als voorbeeld met textboxen:

Visual Basic .NET:

    Protected Sub Replace(ByVal c1 As Char, ByVal c2 As Char, ByVal ParamArray fields() As TextBox)

        For Each field As TextBox In fields
            field.Text = field.Text.Replace(c1, c2)
        Next

    End Sub

Wordt aangeroepen als volgt:

Visual Basic .NET:

Replace(" ", "", _
                TextBox1, _
                TextBox2 _
                )

of

Visual Basic .NET:

Replace(" ", String.Empty, _
                TextBox1, _
                TextBox2 _
                )

Echter, nu wordt de tekst in de tekstboxen volledig verwijderd NA de spatie zodra er een spatie in zit. De c2 vervangen door 2 dubbele quotes lost het probleem op, maar daarmee is de essentie van de functie weg.

Bijvoorbeeld;

in: broodje aap
uit: broodje
verwacht: broodjeaap

Dit lijkt mij een bug in .NET? Of zie ik iets over het hoofd?

[ Voor 3% gewijzigd door Montaner op 02-05-2014 13:24 ]

[BasieP]

Ten eerste even over je globale oplossing.

Ik vind het vreemd dat je een functie maakt die alleen met textbox-en kan omgaan. Waarom maak je niet een functie die gewoon strings snapt? dan kan je hem ook voor andere dingen gebruiken.

Je zou zelfs je bestaande tekstbox kunnen uitbreiden met een functie die dit doet, zodat je bijv dit kunt doen:

Visual Basic .NET:

Textbox1.Replace(" ", "")

Dit kun je doen door 'extentions' (google)


Over je probleem.
Volgens mij kun je dit gewoon debuggen. Hier op got zijn daar handleidingen voor te vinden (zie de sticky's bovenin het forum)
Ik kan je vertellen dat het geen bug in .net is.

Hak je probleem in stukjes en kijk mee.

Bijv. om te testen of de replace functie het doet:

Visual Basic .NET:

var resultaat = "ik ben broodje aap".Replace(" ", "")

En ja daar komt gewoon "ikbenbroodjeaap" uit

[Montaner]

Textboxen zijn een voorbeeld, om een aantal pagina's aan code van mijn eigen class hier neer te zetten heeft niet zoveel zin.

En uiteraard, zoals je aangeeft, Replace(" ","") werkt prima, maar niet als je dit via de functie aanroept. Waarom zit hier verschil in? En waar zit het verschil? In beide gevallen is de 2e param van de replace functie leeg.

[Icekiller2k6]

Bij VB.net moet je oplette met byref of byval.

Ik raad je aan om de tekst als een value te sturen lokaal te bewerken in een var en terug te sturen. Dit zou geen issue geven dan.

[Montaner]

Ik heb de char parameters maar aangepast naar strings. Een lege character bestaat niet (althans, niet zoals bv. String.Empty), dus daarvoor een lege string meegeven geeft rare resultaten.

Visual Basic .NET:

    Protected Sub Replace(ByVal c1 As String, ByVal c2 As String, ByVal ParamArray fields() As TextBox)

        For Each field As TextBox In fields
            field.Text = field.Text.Replace(c1, c2)
        Next

    End Sub

[Woy]

Het punt is inderdaad dat vb.net hier een string literal automatisch omzet naar een char. Een Empty string literal zal waarschijnlijk omgezet worden naar een \0 char, en dus wordt de string op die plek afgekapt.

Als je Option Strict On had gebruikt had je waarschijnlijk ook al wel een foutmelding gekregen dat hij een string niet automatisch naar een char kan converteren.

trix0r schreef op vrijdag 02 mei 2014 @ 13:22:
Dit lijkt mij een bug in .NET? Of zie ik iets over het hoofd?

Niet dat er geen bugs in .NET kunnen zitten, maar op het moment dat je dat denkt zit je 99,9% van de tijd verkeerd

[ Voor 14% gewijzigd door Woy op 02-05-2014 14:34 ]

[LiquidT_NL]

Het is natuurlijk ook geen super-obscure en complexe functie. Als Replace het niet meer doet in VB.NET dan valt de boel een beetje uit elkaar

Overigens, zolang je niet heel bekend bent met een taal en datatypes kan ik je sterk aanraden Option Strict en eventueel Option Explicit te hanteren. Geeft wat meer feeling voor dit soort problemen.

[RobIII]

LiquidT_NL schreef op vrijdag 02 mei 2014 @ 14:54:
Overigens, zolang je niet heel bekend bent met een taal en datatypes kan ik je sterk aanraden Option Strict en eventueel Option Explicit te hanteren. Geeft wat meer feeling voor dit soort problemen.

Ook als je wel bekend bent met de taal en/of de datatypes: die opties horen gewoon by default aan te staan en te blijven.

[LiquidT_NL]

RobIII schreef op vrijdag 02 mei 2014 @ 14:55:
[...]

Ook als je wel bekend bent met de taal en/of de datatypes: die opties horen gewoon by default aan te staan en te blijven.

Deels eens, maar ik develop soms tools in VB.NET/VBA, en die tools gebruik ik maar eenmalig voor een simpele analyse. Dan skip ik het wel eens (afhankelijk van het risico op problemen). Maar granted, het aan laten staan geniet de voorkeur.