Newsgroup: it.comp.lang.visual-basic
Titolo: [?] vbCrLf

Salve a tutti.
Qual'è l'analogo della costante vbCrLf o vbTab in 
VB.NET
?
Ho cercato nella documentazione del Framework senza molta fortuna...

 Ho cercato nella documentazione del Framework senza molta fortuna...
Ecco, se lo trovi fammi un fischio: sono due giorni che cerco la risposta a
questa domanda (ovviamente senza usare la retro-compatibilità con VB4/5/6).
Ciao
--
y = f(
http://neodatatype.interfree.it/index.html
)

 questa domanda (ovviamente senza usare la retro-compatibilità con
VB4/5/6).
Da MSDN:
      Visual Basic 6.0 Visual Basic .NET Equivalent
      vbBack ControlChars.Back
      vbCr ControlChars.Cr
      vbCrLf ControlChars.CrLf
      vbFormFeed ControlChars.FormFeed
      vbLf ControlChars.Lf
      vbNewLine ControlChars.NewLine
      vbNullChar ControlChars.NullChar
      vbNullString Nothing keyword
      vbObjectError vbObjectError
      vbTab ControlChars.Tab
Se avete seguito alcuni thread di un mesetto fa, vedrete che questa è la
prima volta che si verifica quanto discusso nel thread.
Infatti ControlChars.CrLf vale CR+LF, mentre ControlChars.NewLine significa
"Nuova Linea", anche nei sistemi in cui la nuova linea NON è CR+LF.
Ciao
Alberto

       vbBack ControlChars.Back
[SNIP]
L'unica cosa e' che Zanna vuole tenersi per quanto possibile "neutro" nei
confronti del linguaggio, e la classe ControlChars e' inserita nella
namespace Microsoft.VisualBasic
Ciao
--
Luca Dormio - 
luca....@tin.it
________________________________
"Marty, non stai ragionando in maniera quadridimensionale"
Dr. Emmett L. Brown

 namespace Microsoft.VisualBasic
Se hai un minuto mi presenti meglio l'argomento del restare 'neutro'?
Capisco voler restare neutro rispetto alla piattaforma, ma il namespace
Microsoft.Visualbasic è presente nel framework di qualunque piattaforma.
Restare neutro rispetto al linguaggio non riesco a capirlo. Se uno scrive in
VB.Net, credo sia pressochè costretto ad utilizzare le classi di 
VB.NET
.
O mi sbaglio di grosso?
Ciao
Alberto

 O mi sbaglio di grosso?
Non e' detto, e infatti c'e una sottile differenza tra "sviluppare in
VB.NET
" e "siluppare in .NET usando VB".
La maggior parte delle classi del framework sono generiche da questo punto
di vista e puoi semplicemente decidere di usare il dialetto VB piuttosto che
quello di un altro linguaggio facendo riferimento ai medesimi oggetti; se
hai velleita' di passare in futuro ad altri linguaggi in maniera' il piu'
possibile indolore puoi scegliere di evitare l'uso di namespace troppo
specifiche e cercare funzioni equivalenti in altre classi, come sta facendo
Zanna
Per fare un esempio banale, gli stessi tipi di dato base, esistono in
versione neutra e in versione legata al linguaggio e puoi comunque scegliere
quale usare
'VB
Dim i As Integer
Dim i As System.Int32
'C#
int i;
System.Int32 i;
sono esattamente la stessa cosa, ma nel secondo caso hai usato lo stesso
tipo per entrambi.
Quindi dipende da come vuoi regolarti... nota peraltro che la namespace
Microsoft.VisualBasic e' comunque come tutte le altre, e puo' essere usata
comodamente in altri linguaggi; questo per esempio e' un programma C# che
compila tranquillamente:
using System;
using Microsoft.VisualBasic;
namespace ConsoleApplication2
{
  class Class1
  {
    [STAThread]
    static void Main(string[] args)
    {
      Console.WriteLine("rava" + ControlChars.NewLine + "fava");


 compila tranquillamente:
Ecco, il punto era questo.
Siccome Microsoft.VisualBasic è una namespace presente nel framework, ed
utilizzabile da C# e VC++, immagino che debba essere supportata da altre
implementazioni del Framework, anche per altre piattaforme.
Il rischio, altrimenti, è che si crei il caos già esistente per le Virtual
Machine Java (che dovevano essere framework perfettamente interpiattaforma,
e sappiamo benissimo che a seconda del produttore della VM abbiamo roba che
va o meno).
Comunque apprezzo il tuo post, e ne farò tesoro.
Sono sempre stato un sostenitore della massima portabilità e neutralità del
codice, per cui, quando mi metterò sotto con .Net (anche se credo che virerò
a C#), seguirò quanto il buon Zanna sta facendo...
Ciao
Alberto

 VB.Net, credo sia pressochè costretto ad utilizzare le classi di 
VB.NET
.
Beh, a parte tutti le porcate possibili dall'uso di tale namespace (come
diceva Luca, la possibilità di scrivere in C# usando funzioni di VB6...
brrrr), se si usa il framework .NET passare da un linguaggio ad un altro
diventa una banalità, ad es. convertire un prog. 
VB.NET
 in C# si riduce a
poco più che ad aggiungere i ";" a fondo linea.
Mentre è già un casino se si decide di convertire 
VB.NET
 in compatibilità in
VB.NET
 "puro".
E a parte tutte le disquisizioni tecniche mi pare un'idiozia rimanere legati
a vecchie tecnologie quando si possono sfruttare a pieno le nuove (e
migliori).


 nuove (e migliori).
Perfettamente d'accordo Fabio.
Saluti,
--
Antonio Cangiano
Webmaster di 
www.visualcsharp.it
Fondatore di free.it.comp.lang.csharp e free.it.comp.lang.vbnet
Segui il corso di C#!

Environment.NewLine
oppure
ControlChars.CrLf (con tutti gli aspetti che il thread ha sottolineato)
HTH
--
Corrado Cavalli
UGIdotNET - 
http://www.ugidotnet.org

 Perfettamente d'accordo Fabio.
Da almeno un paio di mesi stiamo valutando se passare o meno a .Net.
E' evidente che ci sarebbero problemi con i progetti già in corso, ma almeno
per i nuovi potrebbe essere interessante cominciare.
Quando, parecchi mesi fa, partecipammo ai primi incontri MS su .Net, ci
venne detto chiaro e tondo che per le applicazioni di automazione
industriale il framework imponeva dei ritardi spesso non tollerabili.
Soprattutto se consideriamo che i PC industriali esistenti negli
stabilimenti non sono certo quelli che troviamo in ufficio (lo stato
dell'arte è il PIII 1.0GHz), e che in molti casi ti impongono l'uso di
Disk-On-Chip, per cui ogni MB di disco significa costi spaventosi.
Se voi ci siete già passati, potete darmi qualche indicazione
sull'applicabilità di .Net a sistemi che devono dialogare via seriale, avere
tempi di risposta all'evento molto stretti, e operare in regimi con
pochissimi MB di disco liberi (quindi niente swap).
Grazie
Alberto

 in regimi con pochissimi MB di disco liberi (quindi niente swap).
Direi che per applicazioni di soft real-time ed affini,
l'uso di Visual C++ resti la scelta migliore.


 l'uso di Visual C++ resti la scelta migliore.
Io direi Borland C++ se c++ dev'essere! ;)

Vi ringrazio di cuore per l'aiuto chi vi avevo richiesto e per tutta la
discussione (involontariamente) scaturita da questo.

 ControlChars.CrLf (con tutti gli aspetti che il thread ha sottolineato)
Senza contare che ControlChars.NewLine e vbNewLine corrispondono a Chr(13) &
Chr(10), quindi non sono affatto "platform indipendent", ma sono appunto
legate al vecchio VB.
Environment.NewLine sembra essere corretta, anche se non è una costante.
Inoltre continuano a mancare altri valori come vbTab ecc... :(


 legate al vecchio VB.
[SNIP]
Non e' proprio cosi'... le vedi 13+10 proprio perche' hai installato questa
specifica implementazione del framework, se aprissi l'object browser in una
ipotetica versione per un'altra piattaforma vedresti il valore valido in
quel contesto.


 brrrr)
Beh... per come e' l'ambiente non e' che sia cosi' scandaloso; scommetto che
se la ns si fosse chiamata, invece di Microsoft.VisualBasic, System.Qualcosa
l'esempio ti sarebbe sembrato del tutto normale.
A parte quanto detto sulla portabilita', sul quale siamo d'accordo, il fatto
di integrare tanti linguaggi cosi' diversi in un unico ambiente e' una gran
cosa, ma necessariamente bisogna scendere a qualche compromesso; io sono
convinto che non solo quella namespace non sparira' in futuro (perche' non
serve solo al passaggio 
VB6-VB.NET
), ma via via che verranno supportati
nuovi linguaggi per la piattaforma .NET, verra' affiancata da altre analoghe
e specifiche per i vari dialetti (d'altra parte te li immagini C,VB,Java,
COBOl,Oberon e tutti gli altri che vogliono portare tutti insieme ;-))


 quel contesto.
Questo è quello che riporta la documentazione.


 e specifiche per i vari dialetti
Può darsi, ma saranno comunque pezzi *non* standard forniti dai vari
produttori, proprio come ha fatto M$, e *solo* per compatibilità:
Microsoft.VisualBasic
Borland.Delphi
Sun.Java
Infatti nota che per C# e J# esiste la sintassi ma non un namespace con
funzioni proprietarie.


 ha scritto nel messaggio
news:dKva9.14643$ub2.2...@news1.tin.it...
 Zanna wrote:
 > Const vbNewLine = Chr(13) & chr(10)
 Ehi  Zanna, forse ho la soluzione:
 Dim vbNewLinw As String = Convert.ToChar(13) & Convert.ToChar(10)
 --
 Dark Hado
 This posting is provided "AS IS" with no warranties, and confers no
 rights.
==============================
mi sembra proprio quello che cercavi :-)
onore a Dark Hado!

 COBOl,Oberon e tutti gli altri che vogliono portare tutti insieme ;-))
    A parte il nome della cosa, in tutto questo discorso mi sembra che ci si
dimentichi che esiste Office e la grande importanza che ha per Microsoft.
Vedi Visual Studio for Applications.
--
Ciao :-)
Maurizio
--------
?SPQR(C)
 X
--------