VS2005 debugger ikke skikkelig

[cub71]

Jeg har en feil i koden min som medfører en exeption. Når jeg kjører programmet i debug kommer feilmeldingne opp i en messagebox istdenfor at programmet stopper på riktig sted i koden som den pleier å gjøre. Slik ser meldingen ut:

 

 

foreach (DataRow rosterRad in firstRosterTable.Rows)
{
.........

subject = subject + (string)rosterRad["Orig"] + " - " 
                       + (string)rosterRad["Dest"];

.........
}

 

Ikke noe stort problem selve feilen, men hvorfor gjør VS det sånn?

Endret 11. januar 2008 av cub71

[Manfred]

...ikke for å pirke, men vil det ikke være bedre å enten bruke klassens ToString(), eller caste med 'as' mot en slik type casting du bruker?

 

rosterRad["Orig"].ToString() mener jeg vil være det beste, eller muligens (rosterRad["Orig"] as string)

[cub71]

Mulig det. Jeg vet ikke hva som er best, jeg bruker bare det som virker... I de andre feltene bruker jeg (DateTime) eller (bool). Det er vel derfor jeg endte opp med (string) også. Krever den mer resurser?

[Manfred]

Det er en litt sånn fy-fy eksplisitt cast... De fleste funksjoner har en ToString(). Skal du ha det til å bli en DateTime kan du enten bruke DateTime.Parse() (eller DateTime.TryParse()), eller (var as DateTime).

[cub71]

Slik?

 

secondRosterRow["Date"] = DateTime.Parse(rosterRad["Date"].ToString());

[Manfred]

DateTime myDate = DateTime.Parse(rosterRad["Date"].ToString()); Den returnerer en DateTime.

 

Eller så kan du bruke DateTime-funksjoner direkte på den:

 

DateTime.Parse(rosterRad["Date"].ToString()).ToString("yyyy-MM-dd");

DateTime.Parse(rosterRad["Date"].ToString()).AddDays(2).ToString("yy/MM yyyy");

 

osv osv...

[cub71]

OK, takk skal du ha.

 

Men tilbake til det egentlige problemet; Noen som vet hvorfor ikke VS debugger dette skikkelig?

[j000rn]

Jeg er ganske uenig med Manfred. Om man vet hvilken type det er så er det omvei å konvertere til string, for så å konvertere tilbake til den typen som man egentlig viste at det var i utgangspunktet...

 

//Lag en ny funksjon:
public type MyConvert<type>(object value)
{
return (value == null || value is DBNull) ? default(type) : (type)value;
}

//Og bruk denne:
secondRosterRow["Date"] = MyConvert<DateTime>(rosterRad["Date"]);

Endret 11. januar 2008 av jorn79

[Manfred]

Er ikke så dum du

 

Kanskje greit hvis man skal konvertere mye...

 

Btw: Hva vil default(DateTime) være?

Endret 11. januar 2008 av Manfred

[j000rn]

Er ikke så dum du

 

Kanskje greit hvis man skal konvertere mye...

 

Btw: Hva vil default(DateTime) være?

 

Jeg har dette som funksjonalitet i database klassen min, som wrapper / factory for iDBCommand/IDBConnection/IDBReader/etc....

 

1.1.1900? DateTime.MinValue? Ren gjetting.... hva med å prøve selv?

[Manfred]

Nå er du bare vanskelig

 

default(DateTime) = 01.01.0001 00:00:00

[j000rn]

Nå er du bare vanskelig

 

default(DateTime) = 01.01.0001 00:00:00

 

Da hadde jeg jo rett da

 

default(DateTime) == DateTime.MinValue == 01.01.0001 00:00:00

[kaffenils]

default(DateTime) == DateTime.MinValue == 01.01.0001 00:00:00

 

Litt kjipt at default(DateTime) ikke er veldig kompatibel med SQL Server, men jeg regner med at du har en config-fil for DAL som forteller deg hvilket RDBMS du bruker og at du håndterer DateTime minimumsverdier basert på dette

Endret 11. januar 2008 av kaffenils

[j000rn]

default(DateTime) == DateTime.MinValue == 01.01.0001 00:00:00

 

Litt kjipt at default(DateTime) ikke er veldig kompatibel med SQL Server, men jeg regner med at du har en config-fil for DAL som forteller deg hvilket RDBMS du bruker og at du håndterer DateTime minimumsverdier basert på dette

 

Håndtere? Som i throw new CatastropicErrorException();?

 

System.Data.SqlTypes.SqlDateTime håndterer dette selv ved å kaste en exception:

SqlTypeException:

SqlDateTime overflow. Must be between 1/1/1753 12:00:00 AM and 12/31/9999 11:59:59 PM.

(.Net 3.5)

 

Lurer på om det kommer en ServicePack på dette som gjør System.Data.SqlClient kompatibelt med SQL Server 2008....

Endret 11. januar 2008 av jorn79

[GeirGrusom]

Grunnen til at feilmeldingen havner i en messagebox, er fordi du har en try...catch på et høyere nivå som tar imot feilmeldingen.

 

Når det gjelder datetime, har jeg aldri forstått hvorfor dette har vært et så stort problem siden 70 tallet.... hvorfor ikke bare lagre datetime som +-millisekunder etter år 0, istedet for sekunder etter 1974 og alt det tøvet der? det er da ikke rakettvitenskap, så hvorfor ikke bare gjøre det riktig med én gang? bransjen vår er full av dårlig planlegging og sneversynte mennesker...dessverre. alt for mange som har sagt "Denne halvveisløsningen er bra nok."

eksempler:

-20-bit adressering (i286<)

-datostempling i databaser

-MS sin 640k minnebegrensing i DOS

-Windows 9x sitt 16/32 bit driversystem

-Linux bruker interrupts for å kommunisere mellom prosesser, noe som begrenser systemet en del.

-Standardbrukeren i Vista er administrator, selvom alle vet at det er idioti.

-IBM satset videre på 16-bit (OS/2) etter at de lanserte ny PC med 32-bit prosessor

 

Når man snakker om adressebredde, så er jo faktisk Windows XP første ekte 32-bit windows versjon for forbrukermarkedet, og den kom i 2001, mens 386 ble utgitt rundt... 91/92?

 

Argh! gjør det riktig første gang, så hadde vi sluppet idiotien rundt dette

En ting som også hadde vært fint, var om Norge bruke punktum istedet for komma som desimaltegn... dette fører også til mye frustrasjon.

[kaffenils]

Når det gjelder datetime, har jeg aldri forstått hvorfor dette har vært et så stort problem siden 70 tallet.... hvorfor ikke bare lagre datetime som +-millisekunder etter år 0, istedet for sekunder etter 1974 og alt det tøvet der?

 

Derfor. Datofunksjoner ville blit et sant mareritt å implementere.

 

Why is 1753 the earliest date for datetime?

Good question. It is for historical reasons. In what we sometimes refer to as the western world, we have had two calendars in modern time: the Julian and the Gregorian calendars. These calendars were a number of days apart (depending on which century you look at), so when a culture that used the Julian calendar moved to the Gregorian calendar, they dropped from 10 to 13 days. Great Britain made this shift in 1752 (1752-09-02 were followed by 1752-09-14). An educated guess why Sybase selected 1753 as earliest date is that if you were to store an earlier date than 1753, you would also have to know which country and also handle this 10-13 day jump. So they decided to not allow dates earlier than 1753. Note, however that other countries did the shift later than 1752. Turkey, for instance, did it as late as 1927.

Being Swedish, I find it a bit amusing that Sweden had the weirdest implementation. They decided to skip the leap day over a period of 40 years (from 1700 to 1740), and Sweden would be in sync with the Gregorian calendar after 1740 (but meanwhile not in sync with anyone). However, in 1704 and 1708 the leap day wasn't skipped for some reason, so in 1712 which was a leap year, they inserted yet an extra day (imagine being born in Feb 30!) and then did the shift over a day like everyone else, in 1753.

[GeirGrusom]

Dette sier meg at alle moderne datoer er feil, altså vi kan ikke bare telle år fra en hvilken som helst dato før 1753, fordi det uannsett vil bli feil? er ikke dette et stort problem for museer eller historiske bøker? og hvorfor er dette relevant for datolagring? det vil jo si at kalenderen vår ikke er matematisk, men kun historisk... jeg ser mange problemer med dette, og løsningen min hadde vært å stryke over det.

[Manfred]

Kan vi ikke bare følge StarTrek og begynne med Star Date, så hadde alle GeirGrusoms problemer vært løst!!

[GeirGrusom]

ja, ingen tenker på problemene mine *snufs*

[cub71]

Grunnen til at feilmeldingen havner i en messagebox, er fordi du har en try...catch på et høyere nivå som tar imot feilmeldingen.

 

Ja det stemte visst. Takk skal du ha.