Aufrufen einer öffentlichen Prozedur in einer Access_DB
H.Blaese
Wollte gern mit einer Schaltfläche eine vorhandene Access Datenbank
aufrufen und dort eine öffentliche Prozedur aufrufen!
Habe die Connection zu dieser DB hergestellt, weiß aber nicht wie ich
diese Prozedur per Code ansprechen soll,
Die Prozedur in der Access DB heißt : Public Sub Geb()
Hier mein Versuch diese zu Öffnen:
Private Sub cmdGeburtstage_Click(ByVal sender As System.Object, ByVal e
As System.EventArgs) Handles cmdGeburtstage.Click
' Verbindung zur Datenbank herstellen
Dim myOleDbConnection As New OleDb.OleDbConnection
myOleDbConnection.ConnectionString =
"Provider=Microsoft.Jet.OLEDB.4.0;Data Source=
""C:\Users\Hans\Documents\Datenbanken\Arbeitsdatenbank.mdb"""
Try
myOleDbConnection.Open()
MsgBox("Verbindung wurde hergestellt")
Catch ex As Exception
MessageBox.Show(ex.Message, _
"Beim Öffnen der Datenbank ist ein Fehler aufgetreten.")
End Try
End Sub
Normalerweise rufe ich innerhalb der Access DB die Prozedur mit
Call Geb
auf, wie schaffe ich das nun von vb.net aus?
Danke schon mal,
Gruß Hans
![Stefan Falz [MVP]'s profile photo](https://lh3.googleusercontent.com/a/default-user=s40-c)
Stefan Falz [MVP]
"H.Blaese" schrieb:
> Habe die Connection zu dieser DB hergestellt, wei� aber nicht wie ich diese Prozedur per Code ansprechen soll,
> Die Prozedur in der Access DB hei�t : Public Sub Geb()
> ...
> Normalerweise rufe ich innerhalb der Access DB die Prozedur mit
>
> Call Geb
>
> auf, wie schaffe ich das nun von vb.net aus?
gar nicht, zumindest nicht �ber OleDbConnection oder �hnliches.
Schau mal hier, das k�nnte in deinem Fall was bringen:
http://support.microsoft.com/kb/306682
--
Tschau, Stefan
Microsoft MVP - Visual Developer ASP/ASP.NET
http://www.asp-solutions.de/ - Consulting, Development
http://www.aspnetzone.de/ - ASP.NET Zone, die ASP.NET Community
Peter Götz
> Wollte gern mit einer Schaltfläche eine vorhandene Access Datenbank
> aufrufen
Eine Datenbank aufrufen?
Ich denke eher eine Verbindung (Connection) zu einer
DB herstellen.
> und dort eine öffentliche Prozedur aufrufen!
> Habe die Connection zu dieser DB hergestellt, weiß aber nicht wie ich
> diese Prozedur per Code ansprechen soll,
> Die Prozedur in der Access DB heißt : Public Sub Geb()
Das ginge nur via Objektautomatisation, wozu Dir
Stefan Falz ja schon einen Hinweis (mit Link) gegeben
hat. Der Nachteil dabei wäre aber, dass auf dem
betr. System Access installiert sein müsste.
> Hier mein Versuch diese zu Öffnen:
>
> Private Sub cmdGeburtstage_Click(ByVal sender As System.Object, ByVal e As
> System.EventArgs) Handles cmdGeburtstage.Click
>
> ' Verbindung zur Datenbank herstellen
> Dim myOleDbConnection As New OleDb.OleDbConnection
> myOleDbConnection.ConnectionString =
> "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=
> ""C:\Users\Hans\Documents\Datenbanken\Arbeitsdatenbank.mdb"""
>
> Try
> myOleDbConnection.Open()
>
> MsgBox("Verbindung wurde hergestellt")
> Catch ex As Exception
>
> MessageBox.Show(ex.Message, _
> "Beim Öffnen der Datenbank ist ein Fehler aufgetreten.")
> End Try
>
> End Sub
>
> Normalerweise rufe ich innerhalb der Access DB die Prozedur mit
>
> Call Geb
>
> auf, wie schaffe ich das nun von vb.net aus?
s.oben:
Nur via Objektautomatisierung, was eben ein installiertes
Access voraussetzen würde.
Mit dem OleDbProvider (JetEngine) kann man auch
ohne installiertes Access auf die eigentlichen Daten
in einer *.mdb lesend und schreibend zugreifen.
Was genau macht denn diese Prozedur "Gelb"?
Vermutlich ist es einfacher und eben nicht von einem
installierten Access abhängig, wenn Du die Funktionalität
dieser Prozedur "Gelb" in Deinem Programmcode
entsprechend nachbildest. Der Zugriff auf Deine *.mdb
erfolgt dann über eine geöffnete OleDbConnection und
mit Hilfe eines DataAdapters oder DataReaders und/oder
über konkret im Code ausformulierte OleDbCommand-
Objekte.
Gruß aus St.Georgen
Peter Götz
www.gssg.de (mit VB-Tipps u. Beispielprogrammen)
H.Blaese
Danke für den Link:
http://support.microsoft.com/kb/306682
Hat auf diese Weise funktioniert, nur wird Access sichtbar gestartet
oAccess.Visible = True
habe mal probiert auf
oAccess.Visible = False
zu ändern, aber das wird ignoriert.
Aber es klappt zumindest mal
Gruß Hans
Am 15.04.2010 17:03, schrieb Stefan Falz [MVP]:
> Hallo H.,
>
> "H.Blaese" schrieb:
>
>> Habe die Connection zu dieser DB hergestellt, weiß aber nicht wie ich
>> diese Prozedur per Code ansprechen soll,
>> Die Prozedur in der Access DB heißt : Public Sub Geb()
>> ...
>> Normalerweise rufe ich innerhalb der Access DB die Prozedur mit
>>
>> Call Geb
>>
>> auf, wie schaffe ich das nun von vb.net aus?
>
> gar nicht, zumindest nicht über OleDbConnection oder ähnliches.
>
> Schau mal hier, das könnte in deinem Fall was bringen:
>
> http://support.microsoft.com/kb/306682
>
H.Blaese
Danke erst mal für deine Antwort und Hinweise.
Hatte dir eine Mail an deine Kontaktmailadresse auf deiner HP
geschrieben, aber bisher leider noch keine Antwort bekommen.
Werde das mal probieren was du geschrieben hast:
Mit dem OleDbProvider (JetEngine) kann man auch
ohne installiertes Access auf die eigentlichen Daten
in einer *.mdb lesend und schreibend zugreifen.
Die Verbindung zur mdb ist ja hergestellt, nur weiß ich nicht wie ich
ich die Prozedur dort aufrufe.
Gruß Hans
Armin Zingler
> Mit dem OleDbProvider (JetEngine) kann man auch
> ohne installiertes Access auf die eigentlichen Daten
> in einer *.mdb lesend und schreibend zugreifen.
>
> Die Verbindung zur mdb ist ja hergestellt, nur weiß ich nicht wie ich
> ich die Prozedur dort aufrufe.
Access führt den VBA-Code aus. Ist kein Access installiert, kann
der Code nicht ausgeführt werden.
--
Armin
Peter Götz
> Hatte dir eine Mail an deine Kontaktmailadresse auf deiner HP geschrieben,
> aber bisher leider noch keine Antwort bekommen.
Fragen zu VB-Themen bitte immer in einer der
passenden Newsgroups stellen. Aus zeitlichen
Gründen ist es mir nicht möglich, direkt an mich
gerichtete Mails mit entsprechenden Fragen
zu beantworten.
Wenn Du Deine Fragen in der passenden NG
stellst, haben andere auch was davon und Du
hast die Chance auch von anderen hier Mitlesenden
Antworten bzw. Lösungsvorschläge zu bekommen.
> Werde das mal probieren was du geschrieben hast:
>
> Mit dem OleDbProvider (JetEngine) kann man auch
> ohne installiertes Access auf die eigentlichen Daten
> in einer *.mdb lesend und schreibend zugreifen.
>
> Die Verbindung zur mdb ist ja hergestellt, nur weiß ich
> nicht wie ich ich die Prozedur dort aufrufe.
Wie schon im vorigen Posting und auch von Stefan Falz
erwähnt, geht das eben nicht über eine OleDbConnection,
sondern nur über Objektautomatisierung, was ein
installiertes Access voraussetzt.
Dein Programm wird sicher einfacher und flexibler,
wenn Du auf Objektautomatisierung verzichtest und
damit eben kein installiertes Access voraussetzt.
Dein Progamm kann dann auch auf Rechnern laufen,
auf denen gar kein Access installiert ist.
Meine Frage, was die Funktion "Gelb" in Deiner
*.mdb macht, bzw. machen soll, hast Du leider
nicht beantwortet. Ich kann Dir deshalb auch keine
praktikable Lösung für Dein Problem vorschlagen.
H.Blaese
Zu 1.) Ich hatte an deine Private Mailadresse geschrieben, weil der
Inhalt privat war und nicht in die Öffentlichkeit gehörte.
Zu 2.) Die Funktion soll "Geb" heißen und liest aus einer Unionabfrage
die aus mehreren Tabellen Daten erfasst, Geburtstage aus von heute,
morgen und übermorgen und gibt die Daten als MsgBox aus.
Starte diese bei Access über eine Befehlsschaltfläche:
Private Sub cmdGeburtstage_Click()
Call Geb
End Sub
LG Hans
H.Blaese
Hier der Inhalt der Funktion die ich über die Befehlsschaltfläche
Geburtstage starte:
Public Sub Geb()
Dim db As DAO.Database
Dim rs As DAO.Recordset
Dim Alter As Variant
Dim i As Integer
Dim j As Integer
Dim K As Integer
Dim strMsg As String
Dim strMsg1 As String
Dim strMsg2 As String
i = 0
j = 0
K = 0
Set db = CurrentDb()
Set rs = db.OpenRecordset("qry_Adressen")
With rs 'Tabelle Geburtstag für Durchsuchung vorbereiten
Do While Not .EOF
Alter = DateDiff("yyyy", rs!Geburtsdatum, Date) ' Jahr heute
minus Geburtsjahr = Alter
If Format(Date, "dd-mm") = Format(rs!Geburtsdatum, "dd-mm") Then
strMsg = strMsg & rs!Nachname & ", " & rs!Vorname & " " & Alter
& " " & "Jahre " & vbNewLine & vbNewLine & ""
i = i + 1
End If
If Format(Date + 1, "dd-mm") = Format(rs!Geburtsdatum, "dd-mm") Then
strMsg1 = strMsg1 & rs!Nachname & ", " & rs!Vorname & " " &
Alter & " " & "Jahre " & vbNewLine & vbNewLine & ""
K = K + 1
End If
If Format(Date + 2, "dd-mm") = Format(rs!Geburtsdatum, "dd-mm") Then
strMsg2 = strMsg2 & rs!Nachname & ", " & rs!Vorname & " " &
Alter & " " & "Jahre " & vbNewLine & vbNewLine & ""
j = j + 1
End If
.MoveNext
Loop
End With
rs.Close
db.Close
Set rs = Nothing
Set db = Nothing
If i = 1 Then
MsgBox strMsg & "hat heute Geburtstag", vbInformation, "Wir
gratulieren dem Jubilar"
ElseIf i > 1 Then
MsgBox strMsg & "haben heute Geburtstag", vbInformation,
"Wir gratulieren den Jubilaren"
Else
MsgBox "Heute hat niemand Geburtstag", vbInformation, "Kein
Jubilar heute"
End If
If K = 1 Then
MsgBox strMsg1 & "hat morgen Geburtstag", vbInformation, "Wir
werden gratulieren"
ElseIf K > 1 Then
MsgBox strMsg1 & "haben morgen Geburtstag", vbInformation,
"Wir werden gratulieren"
End If
If j = 1 Then
MsgBox strMsg2 & "hat übermorgen Geburtstag", vbInformation, "Wir
werden gratulieren"
ElseIf j > 1 Then
MsgBox strMsg2 & "haben übermorgen Geburtstag",
vbInformation, "Wir werden gratulieren"
End If
End Sub
Auruf über Schaltfäche:
Private Sub cmdGeburtstage_Click()
Call Geb
End Sub
LG Hans
Am 15.04.2010 19:41, schrieb Peter Götz:
Stefan Falz [MVP]
"H.Blaese" schrieb:
> Zu 2.) Die Funktion soll "Geb" heißen und liest aus einer Unionabfrage die aus mehreren Tabellen Daten erfasst, Geburtstage aus
> von heute, morgen und übermorgen und gibt die Daten als MsgBox aus.
Und wie soll diese MsgBox dann in deine Anwendung kommen? Solche Sachen
sollte man nicht von außen her aufrufen, sondern eher in der Anwendung
selbst implementieren.
Mittels OleDbDataAdapter, DataTable und einem OleDbCommand sollte das
problemlos klappen.
http://msdn.microsoft.com/de-de/library/system.data.oledb.oledbcommand.aspx
http://msdn.microsoft.com/de-de/library/system.data.oledb.oledbdataadapter.aspx
http://msdn.microsoft.com/de-de/library/system.data.datatable.aspx
Man kann natürlich auch einen OleDbDataReader verwenden, ich persönlich
mag DataReader aber wegen vielerlei Problemstellen nicht.
http://msdn.microsoft.com/de-de/library/system.data.oledb.oledbdatareader.aspx
Armin Zingler
> Nachtrag:
>
> Hier der Inhalt der Funktion die ich über die Befehlsschaltfläche
> Geburtstage starte:
>
> Public Sub Geb()
Ich wollte das "mal schnell" nach VB.Net übersetzen. Leider sind die
Inhalte und Titel der Msgboxen am schwierigsten umzusetzen gewesen. :-)
Na ja, relevant für dich dürfte die Übersetzung der "Kernlogik" sein.
Class Person
Public Alter As Integer
Public Nachname, Vorname As String
Public Overrides Function ToString() As String
Return Nachname & ", " & Vorname & ", " & Alter & " Jahre"
End Function
End Class
'...
Sub Holdrihö
Dim con As New OleDbConnection("Provider=Microsoft.Jet.OLEDB.4.0;Data Source=""C:\Dokumente und Einstellungen\bli-bla-blub.mdb""")
Dim cmd As New OleDbCommand("select * from adressen", con)
Dim dr As OleDbDataReader
Dim Personen(2) As List(Of Person)
Dim Days(2) As Date
Dim Tagbezeichnungen As String() = {"heute", "morgen", "übermorgen"}
For i = 0 To 2
Personen(i) = New List(Of Person)
Days(i) = DateTime.Today.AddDays(i)
Next
con.Open()
dr = cmd.ExecuteReader
Do While dr.Read
Dim Geburtstag = CDate(dr("Geburtsdatum"))
For i = 0 To 2
If DayAndMonthAreEqual(Days(i), Geburtstag) Then
Dim Alter = Days(i).Year - Geburtstag.Year
Personen(i).Add( _
New Person With { _
.Alter = Alter, _
.Nachname = dr("Nachname").ToString, _
.Vorname = dr("Vorname").ToString _
} _
)
End If
Next
Loop
dr.Close()
con.Close()
For TagOffset = 0 To 2
Dim AnzahlPersonen = Personen(TagOffset).Count
If AnzahlPersonen = 0 AndAlso TagOffset = 0 Then
MsgBox("Heute hat niemand Geburtstag", vbInformation, "Kein Jubilar heute")
ElseIf AnzahlPersonen > 0 Then
With New System.Text.StringBuilder
Dim Titel As String
For Each Person In Personen(TagOffset)
.AppendLine(Person.ToString)
Next
.AppendLine()
If AnzahlPersonen = 1 Then
.Append("hat ")
Else
.Append("haben ")
End If
.Append(Tagbezeichnungen(TagOffset))
.Append(" Geburtstag")
If TagOffset = 0 Then
If Personen(TagOffset).Count = 1 Then
Titel = "Wir gratulieren dem Jubilar"
Else
Titel = "Wir gratulieren den Jubilaren"
End If
Else
Titel = "Wir werden gratulieren"
End If
MsgBox(.ToString, MsgBoxStyle.Information, Titel)
End With
End If
Next
End Sub
Private Shared Function DayAndMonthAreEqual(ByVal Day1 As Date, ByVal Day2 As Date) As Boolean
Return Day1.Day = Day2.Day AndAlso Day1.Month = Day2.Month
End Function
--
Armin
Peter Götz
... schnipp...
> Die Funktion soll "Geb" heißen und liest aus einer Unionabfrage die aus
> mehreren Tabellen Daten erfasst, Geburtstage aus von heute, morgen und
> übermorgen und gibt die Daten als MsgBox aus.
Es gibt also keinen Grund, das Programm hierfür von
einem installierten Access abhängig zu machen.
Die entsprechende Abfrage kannst Du in Deinem
Programmcode durch einen entsprechenden
OleDbCommmand (Select....) realisieren, mit dessen
Hilfe Du die so gewonnenen Daten in z.B. eine
DataTable laden kannst.
Das Anzeigen der Daten aus der DataTable oder
eines Such- oder Filterergebnisses aus dieser
DataTable in einer Messagebox wird ebenso in
Deinem Programmcode realisiert.
Also wozu der Zugriff auf eine in der *.mdb enthaltene
Funktion?
Beispiele zum Lesen von Daten aus einer Datenbank
(auch *.mdb) via DataAdapter oder auch via DataReader
findest Du unter
www.gssg.de -> Visual Basic -> VB.net
-> Datenbank
Eine Reihe von Beispielen zum Finden, Filtern, Sortieren
usw. von in einer DataTable liegenden Daten findest Du
unter
www.gssg.de -> Visual Basic -> VB.net
-> DataGridView
-> DataTable / DataView / CurrencyManager
... schnapp....
> Starte diese bei Access über eine Befehlsschaltfläche:
>
.... schnipp....
Wie schon mehrfach erwähnt solltest Du Dich von
Deiner Access-VBA-Denkweise lösen. Du verbaust
Dir damit nur den Blick auf die wesentlich umfangreicheren
und flexibleren Funktionalitäten von .net und ADO.net.
Wichtig für Deine Aufgabenstellung ist vor allem, dass
Du die grundlegenden Abläufe beim Arbeiten mit
DataTables, DataViews und dem CurrencyManager
kennenlernst und verstehst.
Danach wirst Du die Arbeitsweise von Objekten wie
DataSet und Binding leichter durchschauen können.
In einem nächsten Schritt nimm Dir die Objekte
DataReader, DataAdapter, Connection und Command
vor. Erst mit diesem notwendigen Grundwissen wirst
Du dann in der Lage sein, einen den Möglichkeiten von
.net und ADO.net entsprechenden Programmablauf zu
konzipieren.
Mein Rat,
mache Dich erst mal mit den notwendigen Grundlagen
vertraut. Das ist am Anfang sicher auch einiges an
"trockenem" Lernstoff der Dir dann aber die spätere
Entwicklungsarbeit deutlich erleichtert. Eine Reihe von
Beispielen hierfür findest Du unter www.gssg.de -VB.net
und auf einer Vielzahl weiterer Internetpräsenzen.
Noch eine Bitte:
Kürze bei Deinen künftigen Postings zitierten Text
auf das zum Verständnis notwendige Mass und
hänge nicht jedesmal den kompletten Text des/der
vorhergehenden Postings an.
Peter G�tz
> Man kann nat�rlich auch einen OleDbDataReader verwenden, ich pers�nlich
> mag DataReader aber wegen vielerlei Problemstellen nicht.
Ich arbeite eigentlich sehr gerne mit DataReader, konkreten
CommmanObjekten u. Connection.Execute..., weil ich so
in speziellen DB-Klassenmodulen einzelne Funktionalit�ten
(Lesen, Schreiben, L�schen von Daten) leichter in kleine
spezialisierte Prozeduren aufteilen kann.
Auf welche konkreten "Problemstellen" beim DataReader
zielt Deine Anmerkung?
Gru� aus St.Georgen
Peter G�tz
H.Blaese
Hallo Peter!
> Wie schon mehrfach erwähnt solltest Du Dich von
> Deiner Access-VBA-Denkweise lösen. Du verbaust
> Dir damit nur den Blick auf die wesentlich umfangreicheren
> und flexibleren Funktionalitäten von .net und ADO.net.
> Wichtig für Deine Aufgabenstellung ist vor allem, dass
> Du die grundlegenden Abläufe beim Arbeiten mit
> DataTables, DataViews und dem CurrencyManager
> kennenlernst und verstehst.
> Danach wirst Du die Arbeitsweise von Objekten wie
> DataSet und Binding leichter durchschauen können.
> In einem nächsten Schritt nimm Dir die Objekte
> DataReader, DataAdapter, Connection und Command
> vor. Erst mit diesem notwendigen Grundwissen wirst
> Du dann in der Lage sein, einen den Möglichkeiten von
> .net und ADO.net entsprechenden Programmablauf zu
> konzipieren.
Werd ich tun...
> Mein Rat,
> mache Dich erst mal mit den notwendigen Grundlagen
> vertraut. Das ist am Anfang sicher auch einiges an
> "trockenem" Lernstoff der Dir dann aber die spätere
> Entwicklungsarbeit deutlich erleichtert. Eine Reihe von
> Beispielen hierfür findest Du unter www.gssg.de -VB.net
> und auf einer Vielzahl weiterer Internetpräsenzen.
Kannst du mir Literaturmaterial nennen, was mir den Lernstoff leicht
verständlich näher bringt?
Habe mir das Buch
Visual Basic .NET. Grundlagen, Programmiertechniken, Windows-Anwendungen
[ASIN: 382731982X]
bestellt.
Sicher gibt es noch bessere und hoffe auf eure Hinweise.
> Noch eine Bitte:
> Kürze bei Deinen künftigen Postings zitierten Text
> auf das zum Verständnis notwendige Mass und
> hänge nicht jedesmal den kompletten Text des/der
> vorhergehenden Postings an.
Ich denke, so sollte es nun i.O. sein... :-)
Gruß Hans
H.Blaese
> Ich wollte das "mal schnell" nach VB.Net übersetzen. Leider sind die
> Inhalte und Titel der Msgboxen am schwierigsten umzusetzen gewesen. :-)
> Na ja, relevant für dich dürfte die Übersetzung der "Kernlogik" sein.
Möchte mich dafür recht herzlich bedanken für die Mühe die du dir
gemacht hast.
Werde, wie ich dem Peter Götz schon geschrieben habe, mich mehr mit der
Theorie vertraut machen und Literatur studieren, die diese Thematik
behandelt.
Auch an dich die Frage:
Hast du einen Tipp für mich, welches Lernmaterial gut und leicht
verständlich geschrieben ist?
Ich sag schon mal danke im voraus.
Gruß Hans
H.Blaese
Habe deinen Code mal so eingefügt und angepasst, bekomme aber wegen
einer fehlenden Deklaration eine Fehlermeldung:
> For i = 0 To 2
> If DayAndMonthAreEqual(Days(i), Geburtstag) Then
> Dim Alter = Days(i).Year - Geburtstag.Year
DayAndMonthAreEqual
wurde nicht deklariert :-(!
Gruß Hans
Armin Zingler
> Hast du einen Tipp für mich, welches Lernmaterial gut und leicht
> verständlich geschrieben ist?
Nö. Ich drück immer F1. ;)
--
Armin
Armin Zingler
> DayAndMonthAreEqual
>
> wurde nicht deklariert :-(!
doch. weiter unten.
Du musst das auch nicht 1:1 verwenden. Sollte nur als Anregung
dienen, wie man das jetzt machen könnte.
--
Armin
H.Blaese
> Du musst das auch nicht 1:1 verwenden. Sollte nur als Anregung
> dienen, wie man das jetzt machen könnte.
Alles klar, habs übersehen :-(
Danke nochmals
Elmar Boye
"H.Blaese" <martina...@gmx.de> schrieb ...
> Hast du einen Tipp für mich, welches Lernmaterial gut und leicht verständlich geschrieben ist?
Schau Dir mal an:
http://www.microsoft.com/germany/msdn/aktuell/news/MicrosoftVisualBasic2008DasEntwicklerbuch.mspx
http://openbook.galileocomputing.de/einstieg_vb_2008/
Gruß Elmar
Peter Götz
> Kannst du mir Literaturmaterial nennen, was mir den Lernstoff leicht
> verständlich näher bringt?
Die Bücher von Klaus Löffelmann sind recht verständlich
geschrieben und bieten auch einen umfassenden Einstieg
in VB.net die Version seines Entwicklerbuches für VB.net 2008
gibt es als kostenlosen Download unter
http://www.microsoft.com/germany/msdn/aktuell/news/MicrosoftVisualBasic2008DasEntwicklerbuch.mspx
Ein breites Spektrum an Datenbankthemen wird in dem Buch
Datenbank-
Programmierung mit
Visual Basic 2008
ISBN 978-3-86645-422-4
von Walter Doberenz, Thomas Gewinnus
vermittelt. Gefestigte Grundlagen der Programmierung
mit VB.net sollten hierfür aber schon vorhanden sein.
Ansonsten ist immer die Online-Hilfe zu VisualStudio / VB.net
die erste Wahl. Neben reiner Dokumentation bietet sie auch
jede Menge an praktischen Beispielen.
H.Blaese
Hallo Elmar!
> Schau Dir mal an:
> http://www.microsoft.com/germany/msdn/aktuell/news/MicrosoftVisualBasic2008DasEntwicklerbuch.mspx
>
> http://openbook.galileocomputing.de/einstieg_vb_2008/
>
> Gruß Elmar
Hab ich gemacht, danke ist wirklich gutes Material.
Gruß Hans
H.Blaese
>
> Do While dr.Read
> Dim Geburtstag = CDate(dr("Geburtsdatum"))
>
> For i = 0 To 2
> If DayAndMonthAreEqual(Days(i), Geburtstag) Then
> Dim Alter = Days(i).Year - Geburtstag.Year
Bekomme beim starten einen Konvertierungsfehler :-( in der Zeile:
Dim Geburtstag = CDate(dr("Geburtsdatum"))
Ungültige Konvertierung von Typ DBNull in Typ Date.
Kommen auch Hilfehinweise, aber ich komme nicht weiter,
Gruß Hans
Armin Zingler
> Bekomme beim starten einen Konvertierungsfehler :-( in der Zeile:
>
> Dim Geburtstag = CDate(dr("Geburtsdatum"))
>
Geburtsdatum fehlt in der Datenbank. Entweder du lï¿œsst
in der Datenbank keine NULL-Werte zu oder du selektierst
nur die Sï¿œtze mit Geburtsdatum.
--
Armin
H.Blaese
> Geburtsdatum fehlt in der Datenbank. Entweder du lässt
> in der Datenbank keine NULL-Werte zu oder du selektierst
> nur die Sätze mit Geburtsdatum.
Du hattest recht, das brachte die Lösung :-)
Dim cmd As New OleDb.OleDbCommand("select * from qry_Adressen where
Geburtsdatum <> 0", con)
Nun wird die Abfrage und Ausgabe in MsgBoxen ausgeführt!
LG
Armin Zingler
> Dim cmd As New OleDb.OleDbCommand("select * from qry_Adressen where
> Geburtsdatum <> 0", con)
Mit einer anderen Datenbank hï¿œtte das nicht funktioniert.
Normalerweise mï¿œsste es lauten:
...where Geburtsdatum Is Not Null
--
Armin
Peter Götz
> Bekomme beim starten einen Konvertierungsfehler :-( in der Zeile:
>
> Dim Geburtstag = CDate(dr("Geburtsdatum"))
Diese Zeile würde schon als fehlerhaft gekennzeichnet,
wenn Du, was Du unbedingt immer tun solltest, bei Deinen
Projekteigenschaften Option Explicit = On eingestellt
hättest.
Die richtige Deklaration wäre dann
Dim Geburtstag as Date
"Option Explicit" sollte grundsätzlich immer eingeschaltet
sein und im Normall ebenso auch "Option Strict". Ich
meine, ich hatte Dir schon mehrfach empfohlen die
Online-Hilfe zu "Option Explicit" und "Option Strict" zu
lesen.
> Ungültige Konvertierung von Typ DBNull in Typ Date.
Die Fehlermeldung besagt, dass Dein akt. dr("Geburtstag")
leer ist, also den Wert DBNull.Value hat. Eine Typumwandlung
von DBNull.Value nach Date ist aber natürlich nicht möglich.
Mit
if dr("Geburtsdatum") is DBNull.Value then
' Geburtsdatum ist leer
else
Dim GTag as Date
GTag = cType(dr("Geburtsdatum"), Date)
End if
Dein dr("Geburtsdatum") liefert ein Object und
Object kann jeden beliebigen Datentyp darstellen,
u.a. eben auch DBNull.Value oder Date.
Hier ein weiteres Beispiel, bei dem erst mal geprüft
wird, was eine Variable vom Typ Objekt tatsächlich
enthält und dann auf das Prüfungsergebnis
entsprechend reagiert wird:
Private Sub Form1_Click _
(ByVal sender As Object, _
ByVal e As System.EventArgs) Handles Me.Click
Dim GTag As Object = Nothing
Dim Rnd As New Random(Now.Millisecond)
Dim Switch As Integer = Rnd.Next(1, 3)
Select Case Switch
Case 1
GTag = Now
Me.Text = "1 Now"
Case 2
GTag = DBNull.Value
Me.Text = "2 DBNull.Value"
Case 3
GTag = Now.ToString
Me.Text = "3 Now.ToString"
End Select
Dim datGTag As Date
Dim Msg As String
Select Case True
Case GTag Is DBNull.Value
Msg = "GTag: DBNull.Value"
Case TypeOf GTag Is Date
datGTag = CDate(GTag)
Msg = _
"GTag: " & _
ControlChars.CrLf
Msg &= datGTag.ToString
Case Else
Msg = _
"GTag.GetType: " & _
GTag.GetType.ToString
End Select
MessageBox.Show _
(Me, Msg, Me.Text, _
MessageBoxButtons.OK, _
MessageBoxIcon.Information)
End Sub
Karsten Sosna
>>
>> Dim Geburtstag = CDate(dr("Geburtsdatum"))
>
> Diese Zeile würde schon als fehlerhaft gekennzeichnet,
> wenn Du, was Du unbedingt immer tun solltest, bei Deinen
> Projekteigenschaften Option Explicit = On eingestellt
> hättest.
> Die richtige Deklaration wäre dann
>
> Dim Geburtstag as Date
Hallo Peter,
hatte Er irgendwo erwähnt das Er das VB <2008 benutzt? Wenn mich nicht alles
täuscht wurde ab 2008 "Option Infer" eingeführt, damit würde Seine
Deklaration bei "Option Infer On" keinen Fehler produzieren.
--
Gruß Scotty
Peter Götz
> Wenn mich nicht alles täuscht wurde ab 2008 "Option Infer" eingeführt,
Ja, leider.
> damit würde Seine Deklaration bei "Option Infer On" keinen Fehler
> produzieren.
Ja, nur hätte dann z.B. bei
Dim Obj As Object
If Now.Second Mod 2 = 0 Then
Obj = Now
Else
Obj = DBNull.Value
End If
Dim GTag = Obj
die Variable Geburtstag dann nicht unbedingt immer
den Datentyp Date.
Deshalb lieber "Option Infer = Off" und sauber
typgerecht arbeiten.
Armin Zingler
> Hallo Karsten,
>> Wenn mich nicht alles täuscht wurde ab 2008 "Option Infer" eingeführt,
>
> Ja, leider.
Ich empfinde es als eine Erleichterung. Vor allem bei Schleifen wie
for each row in mydataset.mytable.rows 'Typisiertes Dataset
next
'row' hat _per_ _Definition_ den Typ der Items in 'rows'
>> damit würde Seine Deklaration bei "Option Infer On" keinen Fehler
>> produzieren.
>
> Ja, nur hätte dann z.B. bei
>
> Dim Obj As Object
> If Now.Second Mod 2 = 0 Then
> Obj = Now
> Else
> Obj = DBNull.Value
> End If
>
> Dim GTag = Obj
>
> die Variable Geburtstag dann nicht unbedingt immer
> den Datentyp Date.
Die Variable GTag hat sogar immer den Typ Object. Ist auch
richtig so, denn sie muss Date- und DBNull-Werte aufnehmen können.
Mit Option Infer Off hätte ich sie ebenso As Object deklarieren
müssen.
> Deshalb lieber "Option Infer = Off" und sauber
> typgerecht arbeiten.
Option Infer On ist sauber und typgerecht, da der Typ eindeutig
zur Entwufszeit festgelegt wird. Es erspart lediglich Tipparbeit.
--
Armin
Peter Götz
>> Ja, nur hätte dann z.B. bei
>>
>> Dim Obj As Object
>> If Now.Second Mod 2 = 0 Then
>> Obj = Now
>> Else
>> Obj = DBNull.Value
>> End If
>>
>> Dim GTag = Obj
>>
>> die Variable Geburtstag dann nicht unbedingt immer
>> den Datentyp Date.
>
> Die Variable GTag hat sogar immer den Typ Object.
GTag hat bei
"Option Infer On"
"Option Exlicit On"
"Option Strict On"
eben nicht immmer den gleichen Datentyp, wie das
nachfolgende Beispiel nochmal deutlich zeigt:
Public Class Form1
Private mSwitch As Integer
Private Sub Form1_Click _
(ByVal sender As Object, _
ByVal e As System.EventArgs) Handles Me.Click
Dim Obj As Object = Nothing
mSwitch += 1
Select Case mSwitch
Case 1
Obj = Now
Case 2
Obj = DBNull.Value
Case 3
Obj = Now.TimeOfDay
Case 4
Obj = Now.ToString
Case 5
Obj = Now.Millisecond
mSwitch = 0
End Select
Console.WriteLine(Obj.GetType.ToString)
Dim GTag = Obj
Me.Text = mSwitch.ToString & ": " & GTag.GetType.ToString
End Sub
End Class
Wogegen bei
"Option Infer On"
"Option Exlicit On"
"Option Strict On"
die Deklaration
Dim GTag
bereits zur Entwurfszeit als fehlerhaft markiert wird und
genau das meine ich mit "sauber typgerecht" arbeiten.
Bei diesem Beispiel ist es natürlich klar ersichtlich, dass
den Variablen Obj und GTag verschiedene Datentypen
zugewiesen werden. Der an GTag zuzuweisende Wert
könnte in einem anderem Programm aber auch ganz
woanders herkommen, wo im Code nicht so deutlich
sichtbar ist um welchen Datentyp es sich handelt. Die
autom. Typübernahme von "Option Infer On" gefällt mir
dann ebenso wenig wie mir schon früher "Option Explicit Off"
und "Option Strict Off" nicht gefiel.
Ich meine ganz einfach, dass "Option Infer" wieder
dazu verführen könnte, eben nicht "sauber typgerecht"
zu arbeiten.
> Ist auch
> richtig so, denn sie muss Date- und DBNull-Werte aufnehmen
> können.
Ja, bei dem Beispiel ging es mir ja auch nur darum, zu
zeigen, dass trotz des fehlenden "as Typ" bei der
Deklaration eben nicht nur der Typ Date akzeptiert
wird.
> Mit Option Infer Off hätte ich sie ebenso As Object deklarieren
> müssen.
Ja, eben.
Genau das meine ich mit "sauber typgerecht" arbeiten
und genau so will ich es in der Regel haben. Wenn ich
für eine Variable ohnehin nur einen einzigen Datentyp
erwarte, dann deklariere ich die Variable auch entsprechend
dem zu erwartenden Typ, also "as Typ". Wenn ich dagegen
unterschiedliche Datentypen zu erwarten haben, dann
deklariere ich "as Object" und in meinem Code wird
sofort sichtbar was gespielt wird.
>> Deshalb lieber "Option Infer = Off" und sauber
>> typgerecht arbeiten.
>
> Option Infer On ist sauber und typgerecht, da der Typ eindeutig
> zur Entwufszeit festgelegt wird.
Das er eben nicht eindeutig festgelegt wird, zeigt
obiges Beispiel doch eindeutig.
> Es erspart lediglich Tipparbeit.
Ja, das tut es.
Aber ein fehlendes "as Typ" bei der Variablendeklaration
macht nun mal den Code schlechter wartbar und das möchte
ich lieber nicht in Kauf nehmen, nur um beim Tippen ein
"as Typ" einzusparen.
Ich sehe keine Notwendigkeit für "Option Infer On", da
ich bei "Option Infer Off" eben Variablen immer typgerecht
deklarieren kann und muss und im Falle zu erwartender
unterschiedlicher Typen eben deutlich sichtbar "as Object"
deklarieren kann und muss.
Jahrelang wurde zu Recht gegen Option Strict = Off und
Option Explicit = Off gewettert, weil es zu schlampiger
Codeschreibweise und unerwarteten Fehler führt. Ich
verstehe nicht so recht, warum man diesen Zustand
jetzt durch die Hintertüre via Option Infer wieder
einführen will.
H.Blaese
Habe Option Explicit on, Option strict on und die Option Infer auf off
gestellt, was mir im nu 17 Fehlermeldungen eingebracht hat.
Habe alles nun abgeändert, entsprechend der Fehlermeldungen, bis auf
einen Fehler, den ich nicht weg bekomme:
Fehler 1 "Person" ist ein Typ und kann nicht als Ausdruck verwendet
werden. C:\Users\Hans\Documents\Visual Studio
2008\Projects\Hans_Erste\Hans_Erste\Form1.vb 193 30 Hans_Erste
> Deshalb lieber "Option Infer = Off" und sauber
> typgerecht arbeiten.
Ich frage mich dann wirklich, warum Microsoft solche Optionen einbaut um
sauberes Programmieren zu umgehen? Soll das Tipparbeit sparen durch
direkte Zuweisungen von Dimensionierungen?
Hier nun der Komplette Code mit dem einen Fehler "Person", den ich bis
jetzt nicht eliminieren konnte:
Private Sub cmdGeburtstage_Click(ByVal sender As System.Object, ByVal
e As System.EventArgs) Handles cmdGeburtstage.Click
Dim strAdr As String
strAdr = "C:\Users\Hans\Documents\Datenbanken\" &
txtSpeicherort.Text & ".mdb"
Dim con As New
OleDb.OleDbConnection("Provider=Microsoft.Jet.OLEDB.4.0;Data Source=" &
" " & strAdr)
' Vorbereiten der Abfrage mit Ausschluss von 0 Werten im Datensatz
Dim cmd As New OleDb.OleDbCommand("select * from qry_Adressen
where Geburtsdatum is not null", con)
Dim dr As OleDb.OleDbDataReader
Dim Personen(2) As List(Of Person)
Dim Days(2) As Date
Dim Tagbezeichnungen As String() = {"heute", "morgen",
"übermorgen"}
Dim i As Integer
Dim TagOffset As Integer
Dim Geburtstag As Date
Dim AnzahlPersonen As Integer
Dim Alter As Integer
For i = 0 To 2
Personen(i) = New List(Of Person)
Days(i) = DateTime.Today.AddDays(i)
Next
con.Open()
dr = cmd.ExecuteReader
Do While dr.Read
Geburtstag = CDate(dr("Geburtsdatum"))
For i = 0 To 2
If DayAndMonthAreEqual(Days(i), Geburtstag) Then
Alter = Days(i).Year - Geburtstag.Year
Personen(i).Add( _
New Person With { _
.Alter = Alter, _
.Nachname = dr("Nachname").ToString, _
.Vorname = dr("Vorname").ToString _
} _
)
End If
Next
Loop
dr.Close()
con.Close()
For TagOffset = 0 To 2
AnzahlPersonen = Personen(TagOffset).Count
.AppendLine()
.Append(Tagbezeichnungen(TagOffset))
.Append(" Geburtstag")
End Sub
End Class
Gruß Hans
Peter Götz
> Habe Option Explicit on, Option strict on und die Option Infer auf off
> gestellt, was mir im nu 17 Fehlermeldungen eingebracht hat.
Also genügend Anlass, Deinen Programmcode einer
näheren Prüfung zu unterziehen. Genau dieses
Ergebnis ist auch der Grund, warum ich gerade
Einsteigern empfehle mit
Option Explicit = On
Option Strict = On
Option Infer = Off
zu arbeiten.
> Habe alles nun abgeändert, entsprechend der Fehlermeldungen, bis auf einen
> Fehler, den ich nicht weg bekomme:
>
> Fehler 1 "Person" ist ein Typ und kann nicht als Ausdruck verwendet
> werden.
Und wie sieht die davon betroffene Codezeile aus?
... schnipp ...
> Hier nun der Komplette Code mit dem einen Fehler "Person", den ich bis
> jetzt nicht eliminieren konnte:
Durch die vom Browser eingefügten Zeilenumbrüche wird
Dein Code leider sehr schwer lesbar.
Ich durchschaue nicht so recht welche Logik hinter Deinen
mehrfachen Schleifen "For i = 0 to 2" steckt.
Und wo in Deinem Code gibt es nun den Fehler?
Ich versuche das ganze mal etwas vereinfacht
nachzubauen:
' /// Beginn Code
Public Class Form1
Private Sub Form1_Click _
(ByVal sender As Object, _
ByVal e As System.EventArgs _
) Handles Me.Click
Dim Personen(2) As List(Of Person)
Dim i As Integer
For i = 0 To 2
Personen(i) = New List(Of Person)
Personen(i).Add _
(New Person _
("Fritz_" & i.ToString, _
"Müller_" & i.ToString, _
New Date(1950, 1, 1).AddDays(i)))
Personen(i).Add _
(New Person _
("Hans_" & i.ToString, _
"Maier_" & i.ToString, _
New Date(1980, 2, 1).AddDays(i)))
Next
Dim Msg As String = ""
For i = 0 To 2
Msg &= "Personen(" & i.ToString & ")" & ControlChars.CrLf
For Each p As Person In Personen(i)
Msg &= p.GetPersonString & ControlChars.CrLf
Next
Msg &= ControlChars.CrLf
Next
MsgBox(Msg, MsgBoxStyle.Information)
End Sub
Public Class Person
Private mVorName As String
Private mNachname As String
Private mGeburtstag As Date
Public Sub New _
(ByVal VorName As String, _
ByVal NachName As String, _
ByVal Geburtstag As Date)
mVorName = VorName
mNachname = NachName
mGeburtstag = Geburtstag
End Sub
Public ReadOnly Property VorName() As String
Get
Return mVorName
End Get
End Property
Public ReadOnly Property NachName() As String
Get
Return mNachname
End Get
End Property
Public ReadOnly Property Geburtstag() As Date
Get
Return mGeburtstag
End Get
End Property
Public Function GetPersonString() As String
Return _
mVorName & "; " & _
mNachname & "; geb: " & _
mGeburtstag.ToString("dd. MMMM yyyy")
End Function
End Class
End Class
' \\\ E N T E
... und wo gibt es nun ein Problem?
H.Blaese
> Und wie sieht die davon betroffene Codezeile aus?
>
> ... schnipp ...
For Each Person In Personen(TagOffset)
Hier kommt die Fehermeldung :
Fehler 1 "Person" ist ein Typ und kann nicht als Ausdruck verwendet
werden. C:\Users\Hans\Documents\Visual Studio
2008\Projects\Hans_Erste\Hans_Erste\Form1.vb 200 30 Hans_Erste
und Person ist markiert!
Gruß Hans
Elmar Boye
"Peter Götz" <gssg_...@gssg.de> schrieb ...
Das in dem Falle nichts anderes als ein "inferiertes" GTag As Object
rauskommt, liegt daran das keinen kleineren Nenner gibt als System.Object.
Nur das ganze Select spielt dabei keine Rolle, der Compiler wertet
dafür nur das initiale Dim Obj As Object aus.
Ich will auch nicht auf OO rumreiten, denn gibt sicherlich immer die eine
oder andere Stelle, wo man solche Konstrukte benötigt.
Nur dafür ist ein "Option Infer" weder die Lösung noch das Problem.
Ein "Beweis" ist GetType() keinesfalls. Denn Object.GetType()
URL:http://msdn.microsoft.com/de-de/library/system.object.gettype.aspx
liefert seit eh und je den aktuellen Typ, den eine Instanz enthält.
Sinnvoll ist es dort, wo was damit angefangen werden kann:
Private Sub InferIstTypGerecht()
Dim obj = (Date.Now.AddYears(1) - Date.Now).TotalMilliseconds
' Via For ... um sich nicht tot zu klicken
Select Case mswitch
Case 1 : obj = Date.Now.Ticks
Case 2 : obj = Date.Now.Minute
Case 3 : obj = Date.Now.Year
Case Else : obj = Nothing
End Select
Console.WriteLine("{0}", obj.GetType())
End Sub
Erst raten, dann laufen lassen ;-)
Auch wenn ich die Lösung oben eigentlich schon verraten habe.
oder auch:
Private Sub InferIList()
Dim obj As Object
Dim list As IList(Of String)
Dim var = GetIList()
obj = var
list = var
' alle: List(Of String)
Console.WriteLine("{0} => {1} => {2}", var.GetType(), list.GetType(), obj.GetType())
var = GetList()
obj = var
list = var
Console.WriteLine("{0} => {1} => {2}", var.GetType(), list.GetType(), obj.GetType())
End Sub
Private Function GetList() As List(Of String)
Return New List(Of String)()
End Function
Private Function GetIList() As IList(Of String)
Return New List(Of String)()
End Function
Wer versucht die Zuweisungen umzudrehen (erst GetList, dann GetIList),
merkt, dass der Compiler nichts durchgehen lässt.
> Jahrelang wurde zu Recht gegen Option Strict = Off und
> Option Explicit = Off gewettert, weil es zu schlampiger
> Codeschreibweise und unerwarteten Fehler führt.
Das ist und bleibt so - und einer der (weniger wichtigen) Gründe,
warum ich vor Jahren C# den Vorzug gab ...
> Ich verstehe nicht so recht, warum man diesen Zustand
> jetzt durch die Hintertüre via Option Infer wieder
> einführen will.
... nur der Umkehrschluß gilt nicht.
Option Explicit On + Option Infer On bleibt typgerecht <Punkt>.
Und wie bei allen Sprachmitteln ist IMO der Einsatz dort,
wo es angebracht ist, durchaus zulässig und sinnvoll.
Ich pflastere meinen C# Code nicht gedankenlos mit dortigen "var".
Ich setze es dort ein, wo ich den Kontext beim Lesen ohne Umstände
ermitteln kann, nicht aber dort, wo der Compiler mir zu "schlau" ist
und es meinen Lesefluß aufhalten würde.
(InferIstTypGerecht würdest Du im wahren Leben bei mir nicht finden,
InferIList schon eher)
Gruß Elmar
Elmar Boye
"H.Blaese" <martina...@gmx.de> schrieb ...
> Fehler 1 "Person" ist ein Typ und kann nicht als Ausdruck verwendet werden. C:\Users\Hans\Documents\Visual Studio
> 2008\Projects\Hans_Erste\Hans_Erste\Form1.vb 193 30 Hans_Erste
>
Die "böse" Stelle ist:
> For Each Person In Personen(TagOffset)
> .AppendLine(Person.ToString)
> Next
ändere dies bitte ab (Peter Götz zuliebe in Langform ;-):
For Each item As Person In Personen(TagOffset)
.AppendLine(item.ToString)
Next
>> Deshalb lieber "Option Infer = Off" und sauber
>> typgerecht arbeiten.
Damit steht Peter ein wenig alleine auf der Flur.
Auch eine Sprache wie C# erlaubt mit dem "var" Schlüsselwort.
dass der Compiler einen Typ-Rückschluss vornimmt.
Und die Sprachdefinition von C# setzt(e) Programmierer nie
dem Risiko aus, nicht typgerecht zu arbeiten.
Zugelassen sind im dem Zusammenhang nur "sichere" Umwandlungen.
> Ich frage mich dann wirklich, warum Microsoft solche Optionen einbaut um sauberes Programmieren zu umgehen?
Problematisch ist allenfalls die "Option Explicit" Angabe, die leider
in Tradition zu einem mehr als 10 Jahre altem Visual Basic 6 (Classic)
auch heute noch (bis VS 2010) als Standard auf "Off" steht und jeden
Programmieranfänger erstmal in "falscher Sicherheit" wiegt.
Anscheinend fehlt da der Mut, alte Zöpfe abzuschneiden ;-(
> Soll das Tipparbeit sparen durch direkte Zuweisungen von Dimensionierungen?
Option Infer kann schon einiges an Tipparbeit sparen,
wenn es sinnvoll eingesetzt wird.
Gruß Elmar
Armin Zingler
Das Beispiel ist nicht anders als das vorherige. GTag ist As Object
deklariert. Das muss sie auch, da ihr ein Ausdruck vom Typ Object
zugewiesen wird. Es ist unerheblich, ob es praktisch zwei Objekttypen
wie in deinem ersten Beispiel oder 5 wie in diesem sein können.
Deswegen gilt auch hier, dass ich sie mit Infer=Off ebenso As Object
deklarieren muss. Es gibt also keinen Unterschied zwischen On und Off:
Die Variable ist vom Typ Object.
> Wogegen bei
>
> "Option Infer On"
> "Option Exlicit On"
> "Option Strict On"
>
> die Deklaration
>
> Dim GTag
>
> bereits zur Entwurfszeit als fehlerhaft markiert wird und
> genau das meine ich mit "sauber typgerecht" arbeiten.
Mir fehlt hier das Argument. Dass es mit Option Infer Off als Fehler
markiert wird, ist klar. Das begründet jedoch nicht, dass
es mit Infer=On nicht sauber und typgerecht ist. Dass "Dim GTag" allein
mit und ohne Infer nicht sein darf, steht gar nicht zur Diskussion.
Sollte dein Argument sein, dass man sich nicht überall Infer zu nutze
machen kann, dann widerspreche ich auch gar nicht. Aber ein Mittel
wird ja nicht dadurch weniger wert, dass es nicht in allen Fällen
einsetzbar ist.
> Bei diesem Beispiel ist es natürlich klar ersichtlich, dass
> den Variablen Obj und GTag verschiedene Datentypen
> zugewiesen werden. Der an GTag zuzuweisende Wert
> könnte in einem anderem Programm aber auch ganz
> woanders herkommen, wo im Code nicht so deutlich
> sichtbar ist um welchen Datentyp es sich handelt.
Der Laufzeittyp ist unerheblich. Es geht um den Deklarationstyp,
und den siehst du, wenn es dir wirklich nicht klar sein sollte,
per Intellisense.
> Die
> autom. Typübernahme von "Option Infer On" gefällt mir
> dann ebenso wenig wie mir schon früher "Option Explicit Off"
> und "Option Strict Off" nicht gefiel.
Das mag schon sein, nur kann dein Missfallen nicht mit
einem Mangel an typgerechtem Arbeiten begründet werden.
Option Explicit Off ist außerdem ein himmelweiter Unterschied:
Bei Infer=On kommt _immer_ derselbe Code heraus wie bei Infer=Off.
Das trifft auf Option Explicit nicht zu.
> Ich meine ganz einfach, dass "Option Infer" wieder
> dazu verführen könnte, eben nicht "sauber typgerecht"
> zu arbeiten.
Kannst du mir ein brauchbares Beispiel nennen? Deine beiden bisherigen
machen auch für den weiteren Verlauf keinen Unterschied: Wenn
die Variable vom Deklarationstyp Object ist, dann muss mit ihr
im nachfolgenden Code als eine solche umgegangen werden, egal,
ob der Deklarationstyp explizit im Code steht oder nicht.
Wenn du also einen "unbekannten" Laufzeittyp zuweist, dann
ist das unabhängig von Option Infer.
>> Ist auch
>> richtig so, denn sie muss Date- und DBNull-Werte aufnehmen
>> können.
>
> Ja, bei dem Beispiel ging es mir ja auch nur darum, zu
> zeigen, dass trotz des fehlenden "as Typ" bei der
> Deklaration eben nicht nur der Typ Date akzeptiert
> wird.
>
>> Mit Option Infer Off hätte ich sie ebenso As Object deklarieren
>> müssen.
>
> Ja, eben.
> Genau das meine ich mit "sauber typgerecht" arbeiten
> und genau so will ich es in der Regel haben. Wenn ich
> für eine Variable ohnehin nur einen einzigen Datentyp
> erwarte, dann deklariere ich die Variable auch entsprechend
> dem zu erwartenden Typ, also "as Typ".
Davon will ich dich nicht abhalten. ;-)
Wenn dieser Typ identisch mit dem per "Inference" ermittelten Typ
ist, wo ist der Unterschied bzgl des typgerechten Arbeitens?
> Wenn ich dagegen
> unterschiedliche Datentypen zu erwarten haben, dann
> deklariere ich "as Object" und in meinem Code wird
> sofort sichtbar was gespielt wird.
Dir geht es um Klarheit und nicht um typgerechtes Arbeiten, welches
ich auch immer predige. Ich habe das noch nie als Einschränkung empfunden,
kann andererseits aber flüssiger arbeiten.
>>> Deshalb lieber "Option Infer = Off" und sauber
>>> typgerecht arbeiten.
>>
>> Option Infer On ist sauber und typgerecht, da der Typ eindeutig
>> zur Entwufszeit festgelegt wird.
>
> Das er eben nicht eindeutig festgelegt wird, zeigt
> obiges Beispiel doch eindeutig.
Doch, die Variable ist eindeutig vom Typ Object. Das ist sie mit und ohne Infer.
>> Es erspart lediglich Tipparbeit.
>
> Ja, das tut es.
> Aber ein fehlendes "as Typ" bei der Variablendeklaration
> macht nun mal den Code schlechter wartbar und das möchte
> ich lieber nicht in Kauf nehmen, nur um beim Tippen ein
> "as Typ" einzusparen.
>
> Ich sehe keine Notwendigkeit für "Option Infer On", da
> ich bei "Option Infer Off" eben Variablen immer typgerecht
> deklarieren kann und muss und im Falle zu erwartender
> unterschiedlicher Typen eben deutlich sichtbar "as Object"
> deklarieren kann und muss.
>
> Jahrelang wurde zu Recht gegen Option Strict = Off und
> Option Explicit = Off gewettert, weil es zu schlampiger
> Codeschreibweise und unerwarteten Fehler führt. Ich
> verstehe nicht so recht, warum man diesen Zustand
> jetzt durch die Hintertüre via Option Infer wieder
> einführen will.
s.o. Das kann man überhaupt nicht vergleichen. Nenne mir mal
ein Beispiel, bei dem Infer=On zu denselben oder auch nur
ähnlichen, z.T. "fatalen" Auswirkungen führt, wie Strict=Off!
Du wirst keines finden, weil mit Infer=On oder Off derselbe
Code produziert wird. Der Unterschied besteht ausschließlich
im Source-Code. Da ich keine Beeinträchtigung der Lesbarkeit
empfinde, sehe ich nur den Vorteil des flüssigeren Arbeitens.
Hinzufügen muss ich noch, dass ich lokale Variablen, wenn sie nicht
nur block-scope haben, (fast) ausnahmslos zentral zu Prozedurbeginn
deklariere. Insofern kann dein obiges Beispiel bei mir ohnehin
nicht zutreffen. Wenn ich es doch mache, dann nur, um hier mal
schnell ein Beispiel zusammenzustricken.
Außerdem: dass in folgendem Fall Infer=On nicht hilft, dürfte
uns klar sein: (wäre aber weder kompilierbar noch von irgendjemandem
erwünscht)
dim f as form
'...
dim o = f
o = new Control
Übrigens war ich zuerst auch genau deiner Meinung zu diesem Thema.
Ungefähr 5 Minuten lang (nachdem ich von Option Infer erfahren hatte)
bis ich gemerkt habe, dass meine Bedenken grundlos sind.
Analysiere mal den Gedankengang während der Programmierung:
Wenn ich eine Variable deklariere, muss ich mir überlegen,
welchen Datentyp sie aufnehmen können soll. Das hängt natürlich davon ab,
was ich ihr zuweisen möchte. Nichts anderes macht Option Infer On:
Es leitet den Deklarationstyp vom Typ des zugewiesenen Objekts ab.
Das ist genau das, was ich möchte, nur mit dem Unterschied, dass
ich es nicht selbst Tippen muss, sondern der Compiler diesen Zusammenhang
_eindeutig_ selbst erkennen kann.
Aufgrund dieser Defintion des Deklarationstyps ist es sogar möglich,
den Code so zu ändern, dass der beim kompilieren erkannte Typ des
zugwiesenen Objekts ein anderer ist als vor der Codeänderung und
trotzdem der Deklarationstyp der Variablen richtig ist. Warum?
Weil er sich automatisch aufgrund der Definition mitändert. Beispiel:
(vorausgesetzt, i ist noch nicht vorher deklariert)
for i = 0 to 17 'i = Integer
Ändere ich ab in in
for i = 0UI to 17UI 'i = UInteger
Es gilt die Definition, dass der Typ der Schleifenvariablen vom
Typ der Anfangs-/Endwerte abhängt. Erst durch Option Infer ist es möglich,
diese Abhängigkeit im Code umzusetzen. Schreibst du hingegen
for i as integer = 0 to 17
dann hast du in logischer Hinsicht eine redundante Festlegung des Typs
von i, nämlich einmal durch den Typ der Anfangs-/Endwerte und einmal
durch explizites Hinschreiben von "As Integer". Wenn du den Typ in UInteger
änderst, musst daraus du sowohl 0UI/17UI als auch "As UInteger" machen,
und da frage ich mich: Könnte das der Compiler nicht selbst erkennen?
Doch, kann er - mit Option Infer On.
--
Armin
Armin Zingler
Mit Option Infer Off nimmst du dem Compiler die Möglichkeit,
zu erkennen, dass die Variable 'Person' denselben Typ hat
wie die Elemente in der Auflistung 'Personen'. Deswegen
musst du den Typ selbst hinschreiben:
For Each Person As Person In Personen(TagOffset)
--
Armin
Armin Zingler
Stimmt so aber auch nicht. Es liegt ausschließlich daran, dass 'Obj' As Object
deklariert ist. Da kann man 0 oder 500 Zuweisungen vorher haben. Der Compiler
schaut sich ja nicht alle möglichen Zuweisungen an die Variable 'Obj' an
und ermittelt dann den kleinsten gemeinsmane Nenner für die Deklaration von 'GTag'.
So hört sich das deinem Satz nach aber an.
--
Armin
Armin Zingler
Public Class Main
Shared Sub Main()
Dim i As Integer
i = 1
For i = 10 To 15
Next
i += 1
MsgBox(i)
End Sub
End Class
Der Code liefert mit Infer=On und Off zwar das gleiche Ergebnis,
aber wenn es gewollt ist, dass die Schleifenvariable i nichts mit
der vorher deklarierten Variable i zu tun hat, dann wird der
Fehler, dass die Variable für die Schleife "missbraucht" wird,
nur dann erkannt werden, wenn die Schleifenvariable explizit mit
"For i As Integer" deklariert wird.
Ist mir in der Praxis jedoch noch nicht passiert. Trotzdem sei das
der Vollständigkeit halber fairerweise erwähnt. Ändert(e) aber
nichts an meiner Entscheidung pro Infer On.
--
Armin
Elmar Boye
"Armin Zingler" <az.n...@freenet.de> schrieb ...
> Am 20.04.2010 12:24, schrieb Elmar Boye:
>>> Public Class Form1
>>> Private mSwitch As Integer
>>>
>>> Private Sub Form1_Click _
>>> (ByVal sender As Object, _
>>> ByVal e As System.EventArgs) Handles Me.Click
>>>
>>> Dim Obj As Object = Nothing
>>>
>>> mSwitch += 1
>>> Select Case mSwitch
>>> ...
>>> End Select
>>>
>>> Dim GTag = Obj
>>> End Sub
>>> End Class
>>
>> Das in dem Falle nichts anderes als ein "inferiertes" GTag As Object
>> rauskommt, liegt daran das keinen kleineren Nenner gibt als System.Object.
>
> Stimmt so aber auch nicht. Es liegt ausschließlich daran, dass 'Obj' As Object
> deklariert ist. Da kann man 0 oder 500 Zuweisungen vorher haben. Der Compiler
> schaut sich ja nicht alle möglichen Zuweisungen an die Variable 'Obj' an
> und ermittelt dann den kleinsten gemeinsmane Nenner für die Deklaration von 'GTag'.
> So hört sich das deinem Satz nach aber an.
Ja, ich hätte den schon geschriebenen Rest stehen lassen sollen...
was mir aber zu offensiv formuliert erschien ;-)
Abgeleitet wird logischerweise von Dim Obj As Object;
das Select ist für den Typrückschluß irrelevant.
Was aber aus meinen Beispielen ebenfalls klar werden sollte.
Gruß Elmar
Peter Götz
> Das Beispiel ist nicht anders als das vorherige. GTag ist
> As Object deklariert. Das muss sie auch, da ihr ein Ausdruck
> vom Typ Object zugewiesen wird. Es ist unerheblich, ob es
> praktisch zwei Objekttypen wie in deinem ersten Beispiel
> oder 5 wie in diesem sein können.
Ja, das ist doch auch nur ein Codebeispiel um die
Zuweisung verschiedener Datentypen an eine Variable
zu zeigen.
Es ist mir auch klar, dass es wenig Sinn macht, innerhalb
der selben Prozedur Werte verschiedener Datentypen
zu erzeugen, diese dann einer Variablen zuzuweisen und
anschliessend den von dieser Variablen gehaltenen
Datentyp wieder zu ermitteln.
> Deswegen gilt auch hier, dass ich sie mit Infer=Off ebenso
> As Object deklarieren muss.
Ja genau das sage ich doch dauernd und
genau das will ich erreichen. Bei einer Deklaration
mit "as Objekt" oder mit "as IrgendeinandererTyp"
sehe ich eben im Code sofort worum es geht.
> Es gibt also keinen Unterschied zwischen On und Off:
> Die Variable ist vom Typ Object.
Aber ich bekomme nicht mit, wenn dieser Variablen
unbeabsichtigt ein unerwünschter Datentyp
zugewiesen wird.
>
>
>> Wogegen bei
>>
>> "Option Infer On"
>> "Option Exlicit On"
>> "Option Strict On"
>>
>> die Deklaration
>>
>> Dim GTag
>>
>> bereits zur Entwurfszeit als fehlerhaft markiert wird und
>> genau das meine ich mit "sauber typgerecht" arbeiten.
>
> Mir fehlt hier das Argument. Dass es mit Option Infer Off als Fehler
> markiert wird, ist klar.
Ja eben und genau das will ich haben.
> Das begründet jedoch nicht, dass
> es mit Infer=On nicht sauber und typgerecht ist.
Option Infer = On ermöglicht Deklarationen ohne
"as" Klausel und genau das will ich in meinem
Code nicht haben.
> Dass "Dim GTag" allein
> mit und ohne Infer nicht sein darf, steht gar nicht zur Diskussion.
Dim GTag
ist aber bei Option Infer = on möglich und genau das
will ich vermeiden.
>
> Sollte dein Argument sein, dass man sich nicht überall
> Infer zu nutze machen kann,
Nicht nur nicht kann, sondern auch nicht soll.
Statt mit Infer = On zu arbeiten, deklariere ich
im Bedarfsfall eben Variablen "as Object", wenn
diesen wirklich unterschiedliche Datentypen zugewiesen
werden müssen. Ich weiss dann wann und warum
ich das mache und verlasse mich eben nicht auf
einen Automatismus.
> dann widerspreche ich auch gar nicht.
Na, dann wären wir ja am Ziel. ;-)
> Aber ein Mittel wird ja nicht dadurch weniger wert,
> dass es nicht in allen Fällen einsetzbar ist.
Da es auch in jedem Fall auch mit Option Infer = off
geht, wenn man seine Variablen richtig und passend
deklariert, macht diese Option in meinem Augen
überflüssig.
....
> Dir geht es um Klarheit und nicht um typgerechtes Arbeiten,
> welches ich auch immer predige.
Wenn Dir mit dem Ausdruck "Klarheit" wohler ist als mit
dem Ausdruck "typgerechtes Arbeiten", dann stimme
ich Dir gerne zu.
Genau diese Klarheit im Code ist mir wichtig und
die erzwingt eben Infer = off.
Peter Götz
>> Und wie sieht die davon betroffene Codezeile aus?
>>
>> ... schnipp ...
Du hast die Variable Personen in Deinem Code
so deklariert:
Dim Personen(2) As List(Of Person)
>
> For Each Person In Personen(TagOffset)
also kann dieses For Each so nicht funktionieren,
denn Personen(x) liefert kein Objekt vom Typ
Person sondern eine ListOf(Person).
Peter Götz
vergiss mein voriges Posting.
> Du hast die Variable Personen in Deinem Code
> so deklariert:
>
> Dim Personen(2) As List(Of Person)
>
>>
>> For Each Person In Personen(TagOffset)
>
> also kann dieses For Each so nicht funktionieren,
> denn Personen(x) liefert kein Objekt vom Typ
> Person sondern eine ListOf(Person).
Die Diskussion um Infer On und Infer Off hat mich
ganz kirre gemacht.
Deine For Each Schleife muss ganz einfach so
aussehen:
Dim P as Person
For Each P in Personen (TagOffset)
....
Next
Peter Götz
> Ja, ich hätte den schon geschriebenen Rest stehen lassen sollen...
> was mir aber zu offensiv formuliert erschien ;-)
> Abgeleitet wird logischerweise von Dim Obj As Object;
> das Select ist für den Typrückschluß irrelevant.
Natürlich ist mein Beispiel wenig sinnvoll, aber eben
die einfachste Methode zu zeigen was Option Infer
bewirkt oder eben nicht bewirkt.
> Was aber aus meinen Beispielen ebenfalls klar werden sollte.
Diesen Beispielen ist auch gar nicht zu widersprechen,
aber sie widerlegen auch nicht meine These, dass
Option Infer letztlich überflüssig ist wenn man statt
dessen eben passende Deklarationen schreibt.
Elmar Boye
"Peter Götz" <gssg_...@gssg.de> schrieb ...
>> Was aber aus meinen Beispielen ebenfalls klar werden sollte.
>
> Diesen Beispielen ist auch gar nicht zu widersprechen,
> aber sie widerlegen auch nicht meine These, dass
> Option Infer letztlich überflüssig ist wenn man statt
> dessen eben passende Deklarationen schreibt.
Womit man schon mal viel mehr tippen kann,
nimm richtig hübsche viele Generics
Dim dictOfKeyWert As Dictionary(Of KeyKlasse, WertKlasse) = GetKeyWertDictionary()
vs.
Dim dictOfKeyWert = GetKeyWertDictionary()
und bei Einsatz von LINQ und Konsorten wirds schnell noch länger.
Ich verbrate die Zeichen lieber bei den Variablennamen als bei As Klauseln,
denn die begegnen mir einige Zeilen weiter wieder ;-)
Aber letztendlich sei der Einsatz jedem freigestellt -
nur "verteufeln" sollte man es nicht, da dafür kein Grund vorhanden ist.
Gruß Elmar
Karsten Sosna
> ganz kirre gemacht.
Hallo Peter,
ob Du es magst oder nicht, ist doch Dein Problem. Du siehst in dieser
Diskussion doch selber, dass Du gar nicht mehr wei�t was Du eigentlich
machst. Du suchst Beispiele die einfach nicht standhalten. "Option Infer"
ist f�r mich eine sch�ne Sache. Ich behaupte aber nicht, dass man mit
"Option Infer Off" typgerechter programmiert, geschweige denn das
typgerechte Programmieren besser erlernt. Bei typisierten Klassen ist
"Option Infer On" einfach genial. Also warum nicht? Armin hatte es schon
geschrieben "Intellisense" hilft doch. Viel schlimmer finde ich "impilizite
Properties". Klar auch eine tolle Sache nur frage ich michwirklich wo der
Nutzen liegt? Hier wird es sicher f�r den "Laien" kompliziert.
OOP hin und her, in VB-Classic war uns das "sch... egal", Net fordert es.
M�ssen wir deswegen alles �ber Bord werfen und nur "knallhart" OOP
programmieren? Das findest Du selbst im C#-Code nicht immer. Eines Tages
werden sie sicherlich diese Konstrukts in VB einbauen:
\\\
n = --m
///
Man w�re ich gl�cklich, damit kann ich fast C#-Code 1:1 �bernehmen. Hatte ja
gehofft das es mit der 2010-Version kommt, war aber leider nicht so. Bin
wirklich kein C-Fan(Das Semikolon w�re nicht das Problem, aber all diese
"geschweiften Klammern", brichst Du Dir auf einer deutschen Tastatur fast
jedes mal die Finger).
--
Gru� Scotty
Elmar Boye
"Karsten Sosna" <kDOTsosna_no_AT_spam_x.reflexDOTde> schrieb ...
>> Die Diskussion um Infer On und Infer Off hat mich
>> ganz kirre gemacht.
> "Option Infer" ist f�r mich eine sch�ne Sache
> Viel schlimmer finde ich "impilizite Properties". Klar auch eine tolle Sache nur frage ich michwirklich wo der Nutzen liegt? Hier
> wird es sicher f�r den "Laien" kompliziert.
Auch daf�r gibt es eine sinnvolle Verwendung:
N�mlich die sp�tere Erweiterbarkeit (und der Sinn f�r jede Kapselung).
Reicht Dir heute eine "automatisch implementierte Eigenschaft",
http://msdn.microsoft.com/de-de/library/dd293589.aspx
so kannst Du sie morgen um weitere Funktionalit�t erweitern,
ohne (in Grenzen) bereits bestehenden Code anfassen (oder
auch nur neu kompilieren) zu m�ssen.
Denn aus dem Feld aka Variablen (mit einer nicht greifbaren Adresse)
wird ein Methodenpaar mit einer definierten Einsprungadresse.
was das Schreiben von Klassen, wie man sie f�r den Datenzugriff
h�ufig braucht, deutlich erleichtert (man nehme 10, 20 Eigenschaften
und mehr).
Und sparst dabei bei der eher l�nglichen Syntax in VB (verglichen zu C#)
sogar einiges mehr an Tipparbeit, die - so wage ich zu behaupten -
viele davon abgehalten hat, f�r ihren Code Eigenschaften in Erw�gung
zu ziehen.
Leider ist man in VB 2010 zu kurz gesprungen, da man schon beim �ndern
des Zugriffsmodifiziers auf die lange Syntax ausgewechen mu� (s. o.),
etwas wie in C#
public class EineKlasse
{
// Konstruktor -> VB Sub New()
public EineKlasse(string eineEigenschaft)
{
this.EineEigenschaft = eineEigenschaft;
}
public string EineEigenschaft { get; private set; }
}
Leider geht dies in VB.NET 10 weiterhin nur �ber die altbekannte
langatmige Fassung. Und da die Vorlage in C# 3.0 vorher existierte,
h�tte man das erwarten k�nnen und nicht nur ein halbherzige Me-too...
> OOP hin und her, in VB-Classic war uns das "sch... egal", Net fordert es.
Naja, auch da war es Ansichtssache.
Auch JavaScript kann man OO programmieren, usw. usw.
Aber vermutlich findet sich auch jemand der Einw�nde gegen das
(weitgehende) Weglassen von Zeilenfortsetzungen hat ;-)
Und wer sich f�r Neuerungen erw�hmen kann, siehe
http://msdn.microsoft.com/de-de/library/we86c8x2.aspx
Gru� Elmar
Armin Zingler
Hatte erst zu jedem einzelnen nochmal Stellung genommen aber
beschrï¿œnke mich jetzt doch auf' Wesentliche.
>> Es gibt also keinen Unterschied zwischen On und Off:
>> Die Variable ist vom Typ Object.
>
> Aber ich bekomme nicht mit, wenn dieser Variablen
> unbeabsichtigt ein unerwï¿œnschter Datentyp
> zugewiesen wird.
Das ist schon ein Argument. Dadurch, dass du durch das Tippen von "As bla"
eine weitere Fehlerquelle hast, die ich mit Infer=On nicht habe, gleicht
sich das aber wieder aus.
>> Dass "Dim GTag" allein
>> mit und ohne Infer nicht sein darf, steht gar nicht zur Diskussion.
>
> Dim GTag
> ist aber bei Option Infer = on mï¿œglich und genau das
> will ich vermeiden.
Nein, das ist nicht mï¿œglich. Wï¿œre ja noch schï¿œner!
>> Aber ein Mittel wird ja nicht dadurch weniger wert,
>> dass es nicht in allen Fï¿œllen einsetzbar ist.
>
> Da es auch in jedem Fall auch mit Option Infer = off
> geht, wenn man seine Variablen richtig und passend
> deklariert, macht diese Option in meinem Augen
> ï¿œberflï¿œssig.
ï¿œberflï¿œssig wï¿œre es dann, wenn es keinen Vorteil hï¿œtte.
Als ich vorhin dem von mir geposteten Code Option Infer Off
vorangestellt habe, um Hans' Compilierproblem nachzuvollziehen,
ist mir erst wieder aufgefallen, wieviel Vorteile es bringt -
in dem Fall ~25 Stï¿œck. ;)
> Wenn Dir mit dem Ausdruck "Klarheit" wohler ist als mit
> dem Ausdruck "typgerechtes Arbeiten", dann stimme
> ich Dir gerne zu.
Gut, _jetzt_ sind wir am Ziel. :-)
> Genau diese Klarheit im Code ist mir wichtig und
> die erzwingt eben Infer = off.
Wenn du Code noch auf Endlospapier ausdruckst, dann verstehe
ich dich ja. Dann bekommst du freilich kein Intellisense,
wenn du die Maus drï¿œberhï¿œltst. ;-)
--
Armin
Karsten Sosna
>> Sache nur frage ich michwirklich wo der Nutzen liegt? Hier
>
> Auch dafür gibt es eine sinnvolle Verwendung:
> Nämlich die spätere Erweiterbarkeit (und der Sinn für jede Kapselung).
> Reicht Dir heute eine "automatisch implementierte Eigenschaft",
> http://msdn.microsoft.com/de-de/library/dd293589.aspx
> ohne (in Grenzen) bereits bestehenden Code anfassen (oder
Hallo Elmar,
ich werde das bei Gelegenheit mal ausprobieren, unter diesem Aspekt hatte
ich es noch nicht betrachtet. Ok, ich nutze sehr wenige Klassen die für die
Wiederwendung gedacht sind. Klar habe ich auch einige die dazu gedacht sind,
aber im Moment fällt mir keine ein die unter dieser Prämisse erstellt wurde.
Wenn ich Eigenschaftsprozeduren benutze hat das auch einen Grund, ansonsten
kann ich genauso ein öffentliches Feld benutzen.
> Leider ist man in VB 2010 zu kurz gesprungen, da man schon beim Ändern
> des Zugriffsmodifiziers auf die lange Syntax ausgewechen muß (s. o.),
> etwas wie in C#
>
> Leider geht dies in VB.NET 10 weiterhin nur über die altbekannte
> langatmige Fassung. Und da die Vorlage in C# 3.0 vorher existierte,
> hätte man das erwarten können und nicht nur ein halbherzige Me-too...
Wenn ich alles haben wollte was in C# geht könnte ich auch gleich in C#
programmieren. Es gibt halt einige Dinge, die wären wirklich wünschenswert.
>> OOP hin und her, in VB-Classic war uns das "sch... egal", Net fordert es.
>
> Naja, auch da war es Ansichtssache.
> Auch JavaScript kann man OO programmieren, usw. usw.
>
> Aber vermutlich findet sich auch jemand der Einwände gegen das
> (weitgehende) Weglassen von Zeilenfortsetzungen hat ;-)
Habe ich schon - mich. ;=) Ich empfinde dieses Feature genauso schlimm wie
die Fortsetzung mit einem Tiefstrich. _Ich_ empfinde es als unlesbar. Zu dem
gibt es immer noch den Widerspruch zum Doppelpunkt oder der Möglichkeit ein
If ohne End If zu konstruieren. Gut an einer Stelle ist Zeilenfortsetzung
wirklich gut und zwar wenn bspw. APIs deklariert, die 27.000 Parameter
haben. Doch an dieser Stelle wäre mir lieber gewesen man hätte endlich
Kommentierungen einbauen können, so wie in dieser Form:
\\\
Public Function Step _ 'Steps in the Direction
(X As Integer, _ 'The X-Coordinate
Y As Integer _ 'The X-Coordinate
) As Boolean 'Return value
///
Das wäre eine feine Sache gewesen.
> Und wer sich für Neuerungen erwähmen kann, siehe
> http://msdn.microsoft.com/de-de/library/we86c8x2.aspx
Hier ein Webcast(Anmeldung erforderlich):
http://www.microsoft.com/germany/msdn/webcasts/library.aspx?id=1032412499
--
Gruß Scotty
Peter Fleischer
news:OshqmOH4...@TK2MSFTNGP04.phx.gbl...
> ...
>>> Deshalb lieber "Option Infer = Off" und sauber
>>> typgerecht arbeiten.
>
> Damit steht Peter ein wenig alleine auf der Flur.
Zum Glück hat Peter auch in der Vergangenheit mit steigender Erkenntnis
seine Ansichten fortschrittlich revidiert. Ich glaube, auch hier wird er
seine Meinung ändern, wenn er mehr mit anonymen Typen, LinQ usw. arbeiten
wird:-)
--
Viele Gruesse
Peter
Peter Götz
>> Diesen Beispielen ist auch gar nicht zu widersprechen,
>> aber sie widerlegen auch nicht meine These, dass
>> Option Infer letztlich überflüssig ist wenn man statt
>> dessen eben passende Deklarationen schreibt.
>
> Womit man schon mal viel mehr tippen kann,
> nimm richtig hübsche viele Generics
> Dim dictOfKeyWert As Dictionary(Of KeyKlasse, WertKlasse) =
> GetKeyWertDictionary()
> vs.
> Dim dictOfKeyWert = GetKeyWertDictionary()
Für jemanden, der nicht schnell genug blind auf
seiner Tastatur schreiben kann, mag das ein
Problem sein, für mich ist es keines. Auch
sollte man dabei Intellisense nicht verschweigen,
das ja schon einiges an Tipparbeit abnimmt.
> und bei Einsatz von LINQ und Konsorten wirds schnell noch länger.
> Ich verbrate die Zeichen lieber bei den Variablennamen als bei As
> Klauseln, denn die begegnen mir einige Zeilen weiter wieder ;-)
Vergessen wir nicht die ursprüngliche Fragestellung.
Die lies klar erkennen, dass ein bisher noch weitgehend
unbedarfter Einsteiger nach Hilfestellungen für einen
Einstieg in VB.net nachgesucht hat.
> Aber letztendlich sei der Einsatz jedem freigestellt -
> nur "verteufeln" sollte man es nicht, da dafür kein Grund vorhanden ist.
Ich verteufele Infer nicht, bin aber der Meinung, dass
Infer = Off gerade für unbedarfte Einsteiger, die noch
äusserst unsicher im Umgang mit Datentypen sind,
sehr wohl Sinn macht.
Peter Götz
>> Aber ich bekomme nicht mit, wenn dieser Variablen
>> unbeabsichtigt ein unerwünschter Datentyp
>> zugewiesen wird.
>
> Das ist schon ein Argument. Dadurch, dass du durch das
> Tippen von "As bla" eine weitere Fehlerquelle hast,
Welche Fehlerquelle?
Natürlich wäre es denkbar, einen grundsätzlich
falschen Datentyp anzugeben, aber das würde
ich nun nicht mit dem versehentlichen Zuweisen
eines Wertes mit unpassendem Datentyp vergleichen.
Dass ein Programmierer weiss, welchen Datentyp
er an welcher Stelle zu erwarten und zu deklarieren
hat, erwarte ich dann schon.
> die ich mit Infer=On nicht habe, gleicht
> sich das aber wieder aus.
Na ja, das würde ich so nicht unterschreiben.
>
>
>>> Dass "Dim GTag" allein
>>> mit und ohne Infer nicht sein darf, steht gar nicht zur Diskussion.
>>
>> Dim GTag
>> ist aber bei Option Infer = on möglich und genau das
>> will ich vermeiden.
>
> Nein, das ist nicht möglich. Wäre ja noch schöner!
Wir reden schon von VB.net (min. 2008)?
Natürlich kann ich bei
Option Explicit = On
Option Strict = On
Option Infer = On
schreiben:
Dim X = Now
MsgBox (X.ToString)
Mit
Option Explicit = On
Option Strict= On
Option Infer = Off
dagegen wird das X in der Zeile
Dim X = Now
als fehlerhaft markiert und muss zu
Dim X as Date = now
oder
Dim X as Object = ...
geändert werden. Ich gehe mal schon
davon aus, dass das bei Deinem VS2008
genauso ist.
...
> Überflüssig wäre es dann, wenn es keinen Vorteil hätte.
Vergessen wir nicht, dass es ursprünglich um eine
Fragestellung ging, bei der unschwer zu erkennen war,
dass sie von einem noch weitgehend unbedarften
Einsteiger kam, der vor allem Probleme im Umgang
und mit der Zuordnung von Datentypen hat. Ich halte
es besonders in so einem Fall nicht für hilfreich, mit
Option Infer = on zu arbeiten.
> Als ich vorhin dem von mir geposteten Code Option Infer Off
> vorangestellt habe, um Hans' Compilierproblem nachzuvollziehen,
> ist mir erst wieder aufgefallen, wieviel Vorteile es bringt -
> in dem Fall ~25 Stück. ;)
Ich interpretiere das allerdings ganz anders.
Eben diese "25 Stück" machen deutlich, dass er
bis dahin noch recht wenig und zumindest unzutreffend
über die richtige Zuordnung von Datentypen nachgedacht
hat.
>> Wenn Dir mit dem Ausdruck "Klarheit" wohler ist als mit
>> dem Ausdruck "typgerechtes Arbeiten", dann stimme
>> ich Dir gerne zu.
>
> Gut, _jetzt_ sind wir am Ziel. :-)
... und damit sollte es doch nun auch gut sein.
Ich bin einfach der Meinung, dass man beim Beantworten
von Fragen schon auch immer mit einbeziehen sollte,
von wem (mit welchen Grundkenntnissen) die Frage
gestellt worden ist. Meine Erfahrung sagt mir, dass
das Thema Datentypen bei Einsteigern ein sehr wichtiges
und oft nicht auf Anhieb verstandenes ist. Eben nur die
Einstellungen
Option Explicit = On
Option Strict = On
Option Infer = On
erzwingen absolut vollständige (klare) Deklarationen
und genau das halte ich gerade beim Einstieg in
VB.net für sehr wichtig.
Peter Götz
ich will die beiden vorangegangenen Postings nicht
weiter kommentieren, möchte aber einfach nochmal
daran erinnern, dass aus der ursprünglichen
Fragestellung klar erkennbar war, dass hier ein
noch weitgehend unbedarfter Einsteiger, der vor
allem beim Umgang und der richtigen Zuordnung von
Datentypen noch sehr unsicher ist, um Hilfe nachsucht.
Ich denke es wird niemand ernsthaft widersprechen
wollen, dass ein Hinweis auf "impilizite Properties"
und ähnlich komplexe Dinge einem weitgehend noch
unbedarften Einsteiger nicht wirklich weiterhilft.
Peter Götz
> Zum Glück hat Peter auch in der Vergangenheit mit steigender Erkenntnis
> seine Ansichten fortschrittlich
> revidiert. Ich glaube, auch hier wird er seine Meinung ändern, wenn er
> mehr mit anonymen Typen, LinQ usw. arbeiten wird:-)
Wie schon in anderen Antworten erwähnt geht es mir
nicht um ein Dogma für oder wider Infer On, sondern
darum, wie man einem unbedarften Einsteiger, der
klar erkennen lässt, dass Datentypen für ihn erst
mal noch weitgehend spanische Dörfer sind, am
besten zum notwendigen Lernerfolg verhilft. LinQ,
implizite Properties u.ä. sind gewiss keine
Einsteigerthemen.
Elmar Boye
"Karsten Sosna" <kDOTsosna_no_AT_spam_x.reflexDOTde> schrieb ...
>
> Wenn ich alles haben wollte was in C# geht könnte ich auch gleich in C# programmieren. Es gibt halt einige Dinge, die wären
> wirklich wünschenswert.
IMO sollte jede der (von Microsoft) angebotenen Sprachen
ein gleiches Feature Set anbieten - abseits der Syntax,
wo ein Entwickler seinen Vorlieben fröhnen mag.
>>> OOP hin und her, in VB-Classic war uns das "sch... egal", Net fordert es.
>>
>> Naja, auch da war es Ansichtssache.
>> Auch JavaScript kann man OO programmieren, usw. usw.
>>
>> Aber vermutlich findet sich auch jemand der Einwände gegen das
>> (weitgehende) Weglassen von Zeilenfortsetzungen hat ;-)
>
> Doch an dieser Stelle wäre mir lieber gewesen man hätte endlich Kommentierungen einbauen können, so wie in dieser Form:
> \\\
> Public Function Step _ 'Steps in the Direction
> (X As Integer, _ 'The X-Coordinate
> Y As Integer _ 'The X-Coordinate
> ) As Boolean 'Return value
> ///
> Das wäre eine feine Sache gewesen.
Da sollte man das nehmen, was an mehr als einer Stelle nützlich ist,
die Xml-Dokumentation:
http://msdn.microsoft.com/de-de/library/ms172652%28VS.90%29.aspx
''' <summary>Steps in the Direction</summary>
''' <param name="X">The X-Coordinate</param>
''' <param name="Y">The Y-Coordinate</param>
''' <returns>Return value</returns>
Public Function [Step](
ByVal X As Integer,
ByVal Y As Integer) As Boolean
Return False
End Function
und Du profitierst auch ausserhalb vom Quelltext davon.
Gruß Elmar
Elmar Boye
"Peter Götz" <gssg_...@gssg.de> schrieb ...
> Ich denke es wird niemand ernsthaft widersprechen
> wollen, dass ein Hinweis auf "impilizite Properties"
> und ähnlich komplexe Dinge einem weitgehend noch
> unbedarften Einsteiger nicht wirklich weiterhilft.
Da sind wir vermutlich sowhl gleicher wie auch
entgegengesetzter Meinung, je nachdem aus welchem
Blickwinkel ma es betrachtet.
Gleiche Meinung bei:
Ein Anfänger hat die Entwicklungshistorie von .NET,
Visual Basic/C# nicht mitbekommen.
Und er sollte nicht von uns alten Hasen damit konfrontiert
werden, nur weil wir meinen, dass es ja auch anders geht.
Entgegengesetzt bei:
Automatisch erzeugte Eigenschaften (Auto Properties) sollte
man IMO nicht als "komplex" einzustufen und davon abraten.
Fakt ist, dass die Compiler dahin weiter entwickelt werden,
dem Entwickler die Arbeit zu erleichtern (zugegeben mal
mehr mal weniger gelungen - aber auch das ist Ansichtssache).
Und dazu gehören Dinge wie Codegenerierung im Hintergrund
- Visual Basic war da mal führend!
Automatische Eigenschaften, anonyme Klassen, LINQ uam.
können gerade dem Einsteiger erleichtern, sich einer Sprache
und komplexen Umgebungen wie dem .NET Framework zu nähern.
Später als Fortgeschrittener hat er immer die Wahl,
sich von den vorgebenden Pfaden zu entfernen.
Als Beleg für meine These siehe den Custom Event Thread
von Stefan Reimers.
Da zeigt sich, wie man man mit einem (Uralt) Feature
von Visual Basic kämpfen muß.
Nur würde wohl niemand von uns den Schluß daraus ziehen,
dass man das Event Schlüsselwort (und Handles) nicht
nutzen soll.
Da wir uns weit vom Ausgang entfernt haben,
können wir das Thema hiermit gerne beenden.
Gruß Elmar
Armin Zingler
> Wie schon in anderen Antworten erwähnt geht es mir
> nicht um ein Dogma für oder wider Infer On,
Also gestern um 14:12 hat sich das noch als _grundsätzliche_
Ablehnung gelesen. ;) Aber egal, die Argumente wurden ja
jetzt hinreichend ausgetauscht, und dein Argument bzgl Anfänger
ist ja auch nicht ganz von der Hand zu weisen. Also, alles easy.
--
Armin
Armin Zingler
> Hallo Armin,
>
>>> Aber ich bekomme nicht mit, wenn dieser Variablen
>>> unbeabsichtigt ein unerwünschter Datentyp
>>> zugewiesen wird.
>>
>> Das ist schon ein Argument. Dadurch, dass du durch das
>> Tippen von "As bla" eine weitere Fehlerquelle hast,
>
> Welche Fehlerquelle?
> Natürlich wäre es denkbar, einen grundsätzlich
> falschen Datentyp anzugeben, aber das würde
> ich nun nicht mit dem versehentlichen Zuweisen
> eines Wertes mit unpassendem Datentyp vergleichen.
> Dass ein Programmierer weiss, welchen Datentyp
> er an welcher Stelle zu erwarten und zu deklarieren
> hat, erwarte ich dann schon.
Genauso erwarte ich, dass der Programmierer das Richtige zuweist.
Somit ist automatisch der Datentyp der Variable richtig und
dein Argument entkräftet.
>> die ich mit Infer=On nicht habe, gleicht
>> sich das aber wieder aus.
>
> Na ja, das würde ich so nicht unterschreiben.
Gilt auch ohne deine Unterschrift. ;)
Irgendwie kommst du etwas durcheinander. Es ging um "Dim GTag" alleine ohne Zuweisung.
Hast du selbst in dem Beispiel geschrieben und auch oben nochmal zitiert.
Das ist auch mit Option Infer On nicht möglich. Nochmal komplett zitiert:
---->
Wogegen bei
"Option Infer On"
"Option Exlicit On"
"Option Strict On"
die Deklaration
Dim GTag
bereits zur Entwurfszeit als fehlerhaft markiert wird [...]
<----
> ....
>
>> Überflüssig wäre es dann, wenn es keinen Vorteil hätte.
>
> Vergessen wir nicht, dass es ursprünglich um eine
> Fragestellung ging, bei der unschwer zu erkennen war,
> dass sie von einem noch weitgehend unbedarften
> Einsteiger kam, der vor allem Probleme im Umgang
> und mit der Zuordnung von Datentypen hat. Ich halte
> es besonders in so einem Fall nicht für hilfreich, mit
> Option Infer = on zu arbeiten.
Mir ging es bei dem Beispiel darum, ihm zu zeigen, wie man
die "Geburstagslogik" in VB.Net lösen könnte.
Primär ging es dabei nicht um typgerechtes Programmieren
(was ich auch mit Infer=On als gegeben sehe). Da ich
Option Infer per Standardeinstellung On habe, hatte ich
keinen Anlass, es im Beispiel auszuschalten.
Aber ich werde in Betracht ziehen, wenn das Thema wirklich
"typgerechtes Arbeiten" ist, Infer in Beispielen auszuschalten.
Allerdings nur, um etwas zu verdeutlichen. (aber solange es
My.Crap gibt, ist VB eh keine Sprache für Anfänger......*duck*)
>> Als ich vorhin dem von mir geposteten Code Option Infer Off
>> vorangestellt habe, um Hans' Compilierproblem nachzuvollziehen,
>> ist mir erst wieder aufgefallen, wieviel Vorteile es bringt -
>> in dem Fall ~25 Stück. ;)
>
> Ich interpretiere das allerdings ganz anders.
> Eben diese "25 Stück" machen deutlich, dass er
> bis dahin noch recht wenig und zumindest unzutreffend
> über die richtige Zuordnung von Datentypen nachgedacht
> hat.
Wer "er"? Hans? Der Compiler? Der Zingler?
Nachdenken muss ich in dem Fall auch nicht, da der Compiler mir
diese Arbeit abnimmt. Und das zu 100% zuverlässig, sonst liesse
ich es nicht zu.
> Ich bin einfach der Meinung, dass man beim Beantworten
> von Fragen schon auch immer mit einbeziehen sollte,
> von wem (mit welchen Grundkenntnissen) die Frage
> gestellt worden ist. ...
s.o. Option Infer ist eine Grundsatzfrage, die man sonst
bei jedem Beispiel diskutieren müsste.
--
Armin
Karsten Sosna
> weiter kommentieren, möchte aber einfach nochmal
> daran erinnern, dass aus der ursprünglichen
> Fragestellung klar erkennbar war, dass hier ein
> noch weitgehend unbedarfter Einsteiger, der vor
> allem beim Umgang und der richtigen Zuordnung von
> Datentypen noch sehr unsicher ist, um Hilfe nachsucht.
Hallo Peter,
es ging mir nicht um irgendwelche Features die mittlerweile geliefert
werden, sondern und die Feststellung:
<Zitat>
> Dim Geburtstag = CDate(dr("Geburtsdatum"))
Diese Zeile würde schon als fehlerhaft gekennzeichnet,
</Zitat>
Dem ist nun mal nicht so.
> Ich denke es wird niemand ernsthaft widersprechen
> wollen, dass ein Hinweis auf "impilizite Properties"
> und ähnlich komplexe Dinge einem weitgehend noch
> unbedarften Einsteiger nicht wirklich weiterhilft.
Ein Einsteiger wird es ohnehin schwer haben, egal mit welchen Features.
Jemand der aus der VB6/ VBA-Welt kommt und dann nach VB.Net(10) migriert
wird die Welt sowieso nicht mehr verstehen. An dieser Stelle, man bin ich
froh das ich die Entwicklung seit der Beta1 1999 mitmache.
Ob _Du_ nun "Option Infer On" magst oder ist Dein Problem, aber wie Du
festgestellt hast gibt es hier eigentlich nur positive Meinungen dazu. Wie
reagierst Du eigentlich auf Nullables? Nein sollte keine
Diskussionsaufforderung sein.
Nur wenn ich meine Scheuklappen absetze kann ich sehen was noch so gibt.
Einige tun das aber nicht und programmieren fleißig in VB5/ VB6 weiter, eine
Umstellung kommt dort gar nicht in Frage, weil sie Ihr "warmes Nest" nicht
verlassen wollen.
--
Gruß Scotty