Rechnen mit Strings (?)

naja - Intellisense hat so einen sehr stark fokussierten Blickwinkel - quasi durchs Schlüsselloch geguckt.

Also Vorsicht vorm OB!
Da läuft man immer Gefahr, so nebenbei auch mal neue Sachen zu lernen, die man noch nicht kannte!
Sowas wie Double.TryParse, oder Double.ParseExact und so Zeugs.

Was einem IntelliSense auch zeigt. Nachdem man Double. eingibt, werden alle öffentlichen Eigenschaften, Funktionen und Konstanten angezeigt.

Ja, recherchiere du dir dein KnowHow durchs Schlüsselloch zusammen.
Ich nehme dafür lieber den dafür vorgesehenen Browser. Da kriege ich eine ordentliche Aufstellung der Gegebenheiten, und die verschwindet auch nicht, wenn ich mitte Maus klicke.
Und mittm Browser kann ich browsen - weil die unendlich vielen Bezüge der Klassen untereinander sind da ja sehr intuitiv durch Verlinkung zueinander abgebildet.

Und wenn der OB nicht reicht, dann kann man auch noch die MSDN Seite <das hier> betrachten, bevor man ,wie schön von @ErfinderDesRades "ErfinderDesRades" genannt, schaut!

Auf MSDN selbst findet sich ja niemand zurecht - ich jedenfalls habe deren Suche-Funktion noch nicht verstanden.
Auf MSDN greift man indirekt zu, etwa indem man im Code F1 drückt, oder im ObjectBrowser F1 drückt.
Oder man verwendet Google als die Suche-Funktion, die MSDN selbst nicht hat.
Hingegen die OB-Suche funzt ungefähr so, wie man von einer Suche-Funktion erwartet: gib Double ein, dann kriegst du Double.

Also ich finde mich bei MSDN wesentlich besser zurecht, als im OB. Dort ist mMn alles so schön aufgelistet, man hat ein schönes Beispiel, kann direkt die Syntax von etwas einsehen usw.

OB zu benutzen wäre nur ein Grund für mich, wenn ich eine Lib nutze, für die es keine gescheite Doku gibt, da ist dann auch IntelliSense nicht so wirklich hilfreich, da alles durchzuforsten, während ich im OB evtl schneller fündig werde. Aber sonst MSDN, ist mMn immer noch am Besten.

Also ich kriege immer Anfälle wenn sich der OB (ausversehen) öffnet. Man bekommt fast alle Infos und Referenzen durch IntelliSense, notfalls noch Beispiele von MSDN, aber der OB gibt mir weder mehr noch ust er schneller. Das ist doch der Sinn von einer guten Architektur, wie im FW, dass man nicht Stunde lang durch irgendwelche Browser gucken muss, sondern sich alles durchn paar Blicke aufs IntelliSense erschließt.

Trade schrieb:

Also ich finde mich bei MSDN wesentlich besser zurecht, als im OB. Dort ist mMn alles so schön aufgelistet

Mitte Beispiele hast du recht, für Beispiele gehe man auf MSDN.
Aber die Auflistung der Klassen-Member ist im OB besser.
Im OB sind alle Member mit Datentyp gelistet, und alle Überladungen einschließlich Parameter-Typen direkt zum angugge.
Auf MSDN ist nur angegeben, dass die Member überladen sind, aber weder Datentypen noch Parameter sind zu sehen - also ist man gezwungen, weiter rumzuklicksen, wo man im OB schon längst im Bilde ist.
Sind dir die Datentypen und Parameter nicht wichtig, oder wie kommts, dass du dich auf MSDN besser zurechtfindest?

Ma abgesehen, dass MSDN immer paar Sekunden braucht (bei meim INet), der OB nur einen Sekundenbruchteil.

Und eben MSDN hat gar keine Suche-Funktion. Da muss man googeln oder eben erst mittm OB suchen, und dann F1.

ErfinderDesRades schrieb:

Und eben MSDN hat gar keine Suche-Funktion. Da muss man googeln oder eben erst mittm OB suchen, und dann F1.

Ich nutze immer google als Suche für die MSDN ... einfach MSDN vor meinen Suchbegriff da kommen meist bessere Treffer raus wie bei der "MSDN-Suche"

@Schamash
Das hat EDR schon mehrmals erwähnt:

ErfinderDesRades schrieb:

Oder man verwendet Google als die Suche-Funktion, die MSDN selbst nicht hat.

ErfinderDesRades schrieb:

Da muss man googeln

Ich nutze beides, OB und MSDN. Je nachdem, ob ich eine detaillierte Beschreibung einer bestimmten Funktion/Klasse brauche (dann MSDN), oder eher stöbern will, welche Member die Klasse hat (dann OB).

übrigens gibts kein double.parseexact (hat einer oben erwähnt)

Wie hast du das herausgefunden - mit Intellisense?

Dann nächste Übung: Wo gibts ParseExact? (und wie findest du das raus?)

bei DateTime

Wie ich das rausfinde?
Habs im kopf (im Notfall einfach vb.net parseexact googlen)

ErfinderDesRades schrieb:

Wie hast du das herausgefunden - mit Intellisense? <img src="http://www.vb-paradise.de/wcf/images/smilies/wink.png" alt=";)" />

Dann nächste Übung: Wo gibts ParseExact? <img src="http://www.vb-paradise.de/wcf/images/smilies/biggrin.png" alt=":D" /> (und wie findest du das raus?)

Über google - ganz klar.

ErfinderDesRades schrieb:

Dann nächste Übung: Wo gibts ParseExact? (und wie findest du das raus?)

Objektkatalog spuckt zumindest keine Sucherergebnisse für "parseexakt" raus Google dagegen sofort.

Falsch eingegeben?


EDIT: habe erst jetzt gesehen, dass es um "parseexakt" geht

Stimmt, mein Fehler

naja - so funden wir immerhin heraus, dass man mit google-Msdn sogar schreibfehlertolerant suchen kann.
Ich bin nicht gegen Msdn, und tatsächlich (anners als bei Intellisense) geeehts auch ohne OB, wenn man Google-Msdn zu nutzen weiß.
Es sind verschiedene Tools, mit unterschiedlichen Stärken - auf eines zu verzichten ist Dummheit.

Übrigens OB ist zwar nicht schreibfehlertolerant, allerdings kann man immerhin auch wortfetzen suchen - "parseexa" bringt dieselben Treffer.

Und an den oben gezeigten Treffern ist nun gleich wieder interessant: Wusstet ihr, dass auch guid ein ParseExact hat?
Und v.a.: Dass es ühaupt eine Structure DateTimeOffset gibt - auch parseable?

Aber ich bin wirklich immer irritiert, wenn gesagt wird, Msdn sei grad übersichtlicher

Hier sind die Operatoren mal ausgeblendet, und ich sehe Functions und Properties.
Da sehe ich, die Days-Property ist Integer, gibt also die ganzen Tage eines Timespans an.
Hingegen TotalDays ist Double, das ist also die genaue Umrechnung der Zeitspanne in Tage + Tagesbruchteile.

Solche Sachen gibts im OB mit einem Guck

Übrigens empfehle ich als "Durchsuchen" - Einstellung nicht das ganze Framework, sondern "meine Projektmappe" einzustellen. Das ist viel schneller, und blendet Treffer in Libs aus, die eh nicht eingebunden sind.