Booleant problem

Hej! Jag har en funktion som jag vill använda för att kolla datatypen på en viss variabel. Variabeln kommer in som varInput och den förväntade datatypen kommer som sträng i variabeln sDataType. Jag kör nu funktionen med följande värden:

varInput ="arne"
sDatatype="datum"

Resultat:
booly blir false som förväntat, men msgboxen dyker upp ändå på nästa rad

Public Class Validator
    Public Function Validate(ByVal varInput As Object, ByVal sDatatype As String) As Boolean
        Dim booly As Boolean
        Select Case sDatatype
            Case "date"
                booly = IsDate(varInput) 'Booly blir false  precis som förväntat.
                If IsDate(varInput) = True Then MsgBox("Sant")' Msgbox visas trots att den inte borde det.:o 
   'Övrig kod utelämnad då den är irrelevant

        End Select
    End Function

End Class

Nu undrar jag varför...

Kan inte detta vara något att kolla på för dig? :)

Det borde väl vara sDatatype="date" i stället för sDatatype="datum". Det är mao en annan MessageBox du ser?

niko skrev:

Det borde väl vara sDatatype="date" i stället för sDatatype="datum". Det är mao en annan MessageBox du ser?

Jo jag skrev fel :r
Men även om jag har sDatatype="date" så visas msgboxen (den enda som finnes...) :q

clarkbones skrev:

Men även om jag har sDatatype="date" så visas msgboxen (den enda som finnes...)

Du får ursäkta, men om du inte använder en kompilator som du köpt på extrapris hos Galne Gunnar så känns det totalt omöjligt att MessageBoxen skulle visas samtidigt som "booly" blir false på raden innan.

Kan du zippa ihop och lägga upp ett minimalt projekt där problemet uppstår?

/red:

Om det är en multitrådad applikation så finns det ju en teoretisk chans att du lyckas ändra på det som "varInput" refererar till mitt emellan de båda raderna (från en annan tråd). Men det känns så långsökt så det finns inte.

niko skrev:

Om det är en multitrådad applikation så finns det ju en teoretisk chans att du lyckas ändra på det som "varInput" refererar till mitt emellan de båda raderna (från en annan tråd). Men det känns så långsökt så det finns inte.

Eftersom "varInput" har skickats "ByVal", ter det sig som ännu mer långsökt. Jag följer tråden med intresse, och hoppas på att någon kommer på orsaken. :)

UlfT skrev:

Eftersom "varInput" har skickats "ByVal", ter det sig som ännu mer långsökt.

Nej, varför det? "ByVal" betyder i det här fallet att en kopia av referensen lagts på stacken. Objektet den i sin tur pekar på är fortfarande detsamma både innanför och utanför funktionen.

Men långsökt är det ju fortfarande ..

Jag har testat din kod, och den fungerar klockrent. Har inte lyckats återskapa problemet. Så själva problemet kan omöjligt (man ska iofs aldrig säga aldrig) finnas i denna kodsnutt.

Nej, varför det? "ByVal" betyder i det här fallet att en kopia av referensen lagts på stacken. Objektet den i sin tur pekar på är fortfarande detsamma både innanför och utanför funktionen.

nu kan jag inte VB, men betyder inte ByVal att man skickar in en kopia av värdet, och att förändringar på detta värde inte återspeglas på orginal variablen. Om man däremot skickar in med ByRef så skapas en referens till orginal variablen och förändringar i funktionern på verkar orginal variablen.

Om det är som jag tror kan inte en multitrådad applikation förändra värdet på varInput, eftersom varje tråd får en egen lite minnesrymd att ha sina variable data i.

Men om det är som du tror, och applikationen är multitrådad, så är det teoretiskt möjligt att en tråd andra på värdet i orginal variablen och detta då återspeglas i funktionen. Eftersom varej tråd har en egen stack, men alla trådar delar på heapen. (eller var det tvärtom, nej det är det inte, eller???)

- magnus

Gladh skrev:

nu kan jag inte VB, men betyder inte ByVal att man skickar in en kopia av värdet, och att förändringar på detta värde inte återspeglas på orginal variablen.

Jo, men kruxet är just vad som är "värdet". För klasser som allokeras på stacken (värdetyper) så sker en kopiering av datan. För objekt som allokeras på heapen (referenstyper) så sker bara en kopiering av referensen (adressen).

Det som sen krånglar till det är att vissa klasser (tex string) har sin tilldelningsoperator överlagrad och därför alltid klonas/kopieras vid varje tilldelning. I detta fall där inparametern är deklarerad som object så kommer ingen kopiering av datan att ske vid själva funktionsanropet. Däremot så ser en kopiering så fort du försöker använda det (som alltid med strängar). Men det är möjligt att ändra värdet på "arne" utifrån via unsafe-metoder oavsett om den skickas byref eller byval. Datan "arne" ligger på heapen och inte på funktionens lokala stack (det är allt som betyder nåt).

Gladh skrev:

Om det är som jag tror kan inte en multitrådad applikation förändra värdet på varInput, eftersom varje tråd får en egen lite minnesrymd att ha sina variable data i.

Nej. det är processer som har separata minnesrymder, trådar delar samma adressrymd. Om en adress är giltig och åtkomlig i en tråd så är den giltig och åtkomlig i alla andra trådar i samma process.

Gladh skrev:

Men om det är som du tror, och applikationen är multitrådad,

Alltså, nu _tror_ jag ju egentligen inte det. Jag sa att det var enda möjligheten (förutom en kass kompilator).

Nej. det är processer som har separata minnesrymder, trådar delar samma adressrymd

det var ludigt förklarat av mig. Vad jag försökte säga var att 2 trådar som kallar på en funktion där man skickar in en värdetyp kan inte skriva över varandras värden, även om de råkar vara i denna funktion samtidigt. Inte heller kan man komma åt och förstöra värdet i funktionen om en annan tråd kommer åt "orginal" variablen utanför funktionen.

Detta har ju inget med trådarna att göra egentligen utan mer att det skapas en ny variabel på stacken vid varje funktionsanrop.

Såg just nu att det var ett objekt som skickades in, och då blir det precis som du säger en referens som läggs på stacken som pekar på objektet på heapen. Och då spelar det ingen roll hur många olika referenser som läggs på stacken eftersom de allesammans kommer att peka på samma objekt på heapen.

Så vi är överens helt enkelt. Iallafall nu när jag granskat koden lite närmare, fy på mig, såg bara ingen anledning att skicka ett objekt som ByVal så jag tänkte inte på att de var ett objekt ens.

- M

Hehe, det var ju intressanta diskussioner mitt problem gav upphov till. Jag övergav klassen och pysslade med annat, därför har jag inte sett alla svar...

Hursomhelst verkar det blivit något tillfälligt fel i kompilatorn (nej, den är inte köpt på Galne Gunnar, de har lagt ned verksamheten tror jag). Det hela fungerar dock bra sedan jag startat om!