Hallo Leute,

ich bin gerade dabei mein vb.net Programm von alten Visual Basic 6 Code zu befreien.
Jetzt stolpere ich über Zeilenumbrüche. Ich habe einige String-Konstanten, die Zeilenumbrüche enthalten.
Gibt es einen "Konstanten" Ersatz für vbCrLf? System.Environment.Newline ist selbst keine Konstante. Somit kann ich das nicht verwenden.

VG
hotte

Diese Konstanten kann man immer noch genauso gut verwenden. Da man in VB.NET keine Sequenzen wie \r\n schreiben kann, um einen Umbruch zu erzeugen, bist du wohl daran gebunden.

hotte schrieb:

Somit kann ich das nicht verwenden.

In welchem Kontext?

Warum brauchst du eine Konstante? Environment.NewLine ist das OOP Pendant zu der Konstanten, welches du verwenden solltest.

Auch vbCrLf ist keine Konstante sondern ebenso nur aus dem Microsoft.VisualBasic Namespace Microsoft.VisualBasic.Constants.vbCrLf

Eigentlich schon eine Konstante.

Dodo schrieb:

Auch vbCrLf ist keine Konstante sondern ebenso nur aus dem Microsoft.VisualBasic Namespace Microsoft.VisualBasic.Constants.vbCrLf

Intellisense sagt aber bei Auswahl von vbCrLf: Public Const vbCrlF As String.
Somit ist das doch eine Konstante? Jedenfalls kann ich diese folgendermaßen verwenden:
Private Const sText As String = "text" & vbCrLF & "text2"

mit System.Environment.NewLine klappt das nicht, weils keine Konstante ist. D.h. also, verzichte ich auf den Verweis auf "Microsoft.VisualBasic", dann kann ich Konstanten in dieser bisherigen Form nicht mehr verwenden, richtig?

Wieso klappt das nicht?



Das geht genauso.

Das ist richtig. Ist dann aber keine Konstante. Der Text sollte halt unveränderlich sein. Das wollte ich mit dem Code bereits ausdrücken. Dann werde ich mir ein anderes Konzept überlegen. Danke euch

Schau mal hier:
[VB.NET] Microsoft.VisualBasic.ControlChars

@Dodo
Eine Konstante ist nichts böses, vbCrLf ist einfach nur das VB-Pendant zu "\n".

@Artentus
Nein, vbCrLf ist \r\n. \n und \r sind zwei unterschiedliche Chars.
So ist's richtig:

@nafets3646:
Ja stimmt. Da hätte ich einfach mal auf Lukas' Screenshot schauen sollen.
Aber in C# benutze ich immer nur \n, funktioniert bestens.

Hi
außerdem können Konstanten direkt vom Compiler konkateniert werden, das muss nicht zur Laufzeit oder JITC-Zeit geschehen. Bei Environment.NewLine ist das nicht der Fall. Wie immer gilt: Nachdenken und selber auf Sinnhaftigkeit entscheiden.

\r ist übrigens Carriage return, \n new line

Gruß
~blaze~

vbCrlf ist eine Konstante, im bösen Namespace MS-Visualbasic.
Daher von abzuraten, weil derselbe Wert (sogar Systemabhängig korrekt) ist auch annerswo definiert, etwa als Environment.Newline.

Oder man importet halt explizit MS-Visualbasic.ControlChars: böse Funktionen vermeiden(post#4)

Ich würde das jetzt trotzdem nochmal gerne aus der Welt schaffen, da ich immernoch nicht überzeugt bin. Warum nicht vbNewLine verwenden? Das ist an sich keine veraltete Funktion oder dergleichen, sondern eine sinnvolle Konstante, die konkret für VB Sinn macht. Nicht die Microsoft.VisualBasic-Bibliothek ist böse, sondern große Teile des Inhalts, aber pauschal alles daraus abzulehnen ist, als würde man intrinsische, naja, "Funktionen", wie CInt bei primitiven Typen abschaffen wollen, oder etwa nicht?
Klar, Environment.NewLine könnte theoretisch eine andere Zeichenfolge bereitstellen, aber \n ist nun mal Linefeed, da gibt's nicht viel zu rütteln, da das Unicode-Standard ist. Nicht dass man noch mehr Korinthen auswerfen müsste, als eh schon verstreut sind, aber dann wären die meisten Programme verwerflich. An sich sollte derjenige, der die Darstellung vornimmt derjenige sein, der für die korrekte Interpretation für \r\n / \n\r / \n oder \r verantwortlich ist und \n sollte explizit als Zeilenumbruch mit Wagenrücklauf zusammen interpretiert werden, wenn es nicht explizit anders gefordert wird. Zumindest ist das das Standardverhalten, das die meisten Programme aufzeigen würden.

Gruß
~blaze~

also Environment.Newline hat schomal den Vorzug, dasses Systemunabhängig ist.

ansonsten - wie gesagt - der Namespace MS.VisualBasic ist voll mit Schrott und Zeugs, auf das man gut verzichten kann, und es gibt - ebenfalls bereits gesagt (gugge tut) - nur 2 Dinge von Nutzen darin, den Rest braucht man nicht.
Also meinetwegen benutze Microsoft.Visualbasic.Constants.vbCrlf, aber wovon ich abrate, ist Microsoft.Visualbasic als Import zu setzen, um vbCrlf in Kurzschreibweise verwenden zu können.
Weil mti dem Import hast du den ganzen Schrott ebenfalls in Kurzschreibweise verfügbar, und Intellisense versucht bei jeder Gelegenheit, dir was davon anzudrehen.

Dann also leiber ein Import auf Microsoft.Visualbasic.ControlChars, sodass man die Konstante CrLf in Kurzschreibe nutzen kann. Die ist ebensogut wie vbCrLf, nur um die kurzzuschreiben musst du nicht soviel Mist in den lokalen Namensraum aufnehmen.

Mir passiert das an sich eher nicht mehr, dass ich VB6-Funktionen erwische (sieht man ja, wenn sie nicht auf dem aktuellen Typen definiert sind und die Funktionen selber sind nicht ohne Grund hässlich), aber insgesamt sicher sinnvoll.
Also an sich gibt's an vbCrLf nichts auszusetzen? Oder wäre dann vbNewLine nicht besser, da es quasi betriebssystemabhängig ist, ähnlich wie Environment.NewLine, nur dass vbNewLine direkt im Framework auf seinen Wert festgelegt werden muss? vbCrLf wäre ja konkret auf \r\n festgelegt, diese Einschränkung hätte dann vbNewLine nicht.

Gruß
~blaze~

was stört dich anne ControlChars-Enumeration?

Was mich an MS-Visualbasic stört habichja ausgebreitet: das zu importieren bevölkert den lokalen Namensraum mit allerlei schrott.
Mir isses wichtig, den lokalen Namensraum eher zielgerichtet zu befüllen, weil zb Intellisense liefert mir dann bessere Vorschläge.
(und ich veröffentliche ja auch gelegentlich, und iwelchen unbedarften Usern willich den Visualbasic-Namespace nicht antun)

Oha stimmt, das ist 'ne komplett andere Klasse. Stimmt, da hast du recht. Ich kannte ControlChars selber gar nicht. Das steht jetzt sicher auch nicht im Gegensatz zu meiner vorherigen Aussage, dass mir das mit dem VB6-Zeug nicht passiert.

Gruß
~blaze~