Du könntest an der Stelle oben einen Import für den VisualBasic-Namespace machen. Wichtig wäre nur, dass der Generalimport rausgenommen wird.
Ich mach das z.B. an einer Stelle in meinem Programm, weil ich IsNumeric benötige.

Gute Idee, das werd ich mal testen. Dann müsste es für val ja vermutlich auch eine recht simple Alternative geben..

Hm, ob es dafür eine Alternative gibt, ich bin mir nicht sicher. Aber falls es dich interessiert, schau dir mal eine Implementierung von Val bei github an (aus Mono). Hier kannst du dich ein wenig inspirieren lassen

Elephant schrieb:

Wenn man bei Importierte Namesspaces Microsoft.Visual Basic rausnimmt, kennt er Val nicht mehr.

VollQualifizierrt kennt er es nachwievor:

@Elephant Wie sieht so ein Zahlenstring aus?
Poste mal ein paar signifikante Beispiele.

Elephant schrieb:

Die schauen Köpfe hier sagen aber man soll sich von dem ganzen VB6 Kram verabschieden.
Ob es dann so sinnvoll ist, das bei jedem Befehl, den man grade braucht wieder zu benutzen?

Des sagich auch.
Aber ich sag auch, es gibt tatsächlich einige wenige vb6-Elemente, die nützlich sind.

Und nützliches, was schon da ist, soll man halt benutzen - selbst wenns aus dem vb6-Namespace.
Ich bezweifel aber, dass vb6.Val() zu den nützlichen Dingen gehört. Was kann vb6.Val(), was Double.TryParse() nicht kann?

ErfinderDesRades schrieb:

Was kann vb6.Val(), was Double.TryParse() nicht kann?

So was:

Für ganz grosse Zahlen als String gibt es den BigInteger. Aus dem BigInteger kann die Zahl dann in jeden Zahlen-Datentype konvertiert werden.

BigInteger.Parse("123456789...............")

Für Zahlen im NormalBereich, die von EDR und RFG erwähnte Double.TryParse(). Es kommt halt noch drauf an, ob die gewünschten Zahlen die umgewandelt werden sollen Ganzzahlen sind, oder Zahlen mit Nachkommastellen.


EDIT:
Deinen letzten Post habe ich nicht gesehen.
Wenn es um Zeit und Datumangaben handelt, dann stehen dir sicher mal zwei Möglichkeiten zur Verfügung.
1. Alle Zeit und Datumangaben lassen sich in eine Zahl (Integer oder Long) umwandeln. Diekönnte man nutzen um Zahlen zu arbeiten.
Die andere Möglichkeit ist du machst die selber was. Vorteil wäre, das eigenen gemachte Sachen dann auch so gestaltet werden können, dass sie für den gewünschten Zweck optimal sind.


Freundliche Grüsse

exc-jdbi

Elephant schrieb:

ErfinderDesRades schrieb:

Was kann vb6.Val(), was Double.TryParse() nicht kann?

Die obigen Bespiels sind so etwas. TryParse prüft ja den ganzen String und sagt bei den Beispielen dann halt False weil nicht nur Zahlen im String sind.

Na, wenn vb6.Val() ist, was du brauchst, nimm vb6.Val().
Nicht das Rad neu erfinden.
Aber wegen dieser einen Methode jetzet nicht den ganzen MVB-GeneralImport wieder hineinnehmen!

ich verwende übrigens folgenden GeneralImport:
VB6 = Microsoft.VisualBasic
Dann kann ich vb6-Methoden recht komfortabel verwenden, und weiss trotzdem auch, wo das herkommt:

Um aller Art bestimmte Dinge aus Strings rauszuholen gibts aber auch schon eine andere tolle Sache, ich wurd kürzlich wieder dran erinnert.

Elephant schrieb:

Gib mir bitte aber den ganzen Syntax für VB6 = Microsoft.VisualBasic denn so wird es nicht akzeptiert.

Das ist die ganze Syntax.

Ein General-Import halt

Man kann bei Regex natürlich auch den Punkt als Dezimaltrennzeichen festlegen, oder sogar beides, aber dann muss man bei dem Double.Parse nochmal fuchsen.
Habe auch mal in die Performance reingeguckt, Val() muss keinen Speicher allokieren. Da würd ich gern mal wissen, wie das funktioniert.^^ Wahrscheinlich prüfe ich das nicht richtig.

Einer der kleinen Nachteile von Val.

Es gibt keine Möglichkeit die Kultur einzubinden. Ansonsten scheint die Methode dir ja zu passen. Ich habe sie früher auch gerne benutzt. Heute versuche ich einfach mehr DotNet-Konform zu bleiben.