Re: VS 2005 prof. Mathe - Problem
- From: Peter Götz <gssg_nospam@xxxxxxxxxxx>
- Date: Thu, 19 Jan 2006 11:27:48 +0100
Hallo Arno,
> > Warum deklarierst Du z as Object?
> > Weiter unten weist Du der Variablen z das Ergebnis von DateDiff(), also
> > einen Wert vom Typ Long zu. Deklariere also Deine Variable z as Long.
>
> Peter hab ich schon geändert, wie schon erwähnt der Code wurde so von VB
6.0
> nach 2005 migriert. Da ich leider noch nicht alle Schlüsselwörter kenne,
war
> ich froh das überhaupt mal was ginge. :-)).
>
> Unter VB 6.0 hat auch alles einwandfrei ohne Probleme funktioniert.
Wie ich schon im vorigen Posting geschrieben habe, dürfte das reiner Zufall
sein.
Schau Dir z.B. in VB6 mal Folgendes an:
Debug.Print "15,3" + 17.5
Debug.Print "15,3" + "17.5"
Debug.Print "15,3" + "17,5"
Das sind nur ein paar ganz simple Beispiele, die nebenbei auch
verdeutlichen, dass man zur Verknüpfung von Strings nicht den "+"-Operator
verwenden sollte.
> > txtVerzugstage.Text erwartet einen String.
> > Du hast z as Object deklariert und ihm einen Wert vom Typ Long
zugewiesen.
> > Bei einem solchen Durcheinander von Datentypen ist es kein Wunder, wenn
Du
> > irgendwann mal einen Fehler bekommst.
> >
> > Richtig wäre:
> >
> > Dim z as Long
> > z = DateDiff(.......
> > z = z+1
> > txtVerzugstage.Text = z.ToString
> >
>
> Laut MSDN sollte man doch DateDiff auch nicht mehr einsetzen????
In vielen Fällen kann man DateDiff durch TimeSpan ersetzen, man muss es aber
nicht.
Es gibt schon auch Anwendungsfälle in denen DateDiff() sinnvoll ist.
> Hier gibt
> es wohl auch andere möglichkeiten die Armin und Joachim schon erzählt
haben.
> Ich weis es gibt viele Wege die nach Rom führen. Allerdings kenne ich mich
> mit den anderen Schlüsselwörtern noch nicht so richtig aus..
Dagegen hilft ein gründliches Studium der Online-Hilfe.
> >> Zins = CDbl(txtGesamtforderungsbetrag.Text) * CDbl(txtVerzugstage.Text)
*
> >> CDbl(txtAktuellerzinssatz.Text) / 36000
> >
> > Hier wieder ein völlig unnötiges Durcheinander von Datentypen.
> > Oben hast Du Zins as Object deklariert und nun weist Du diesem Objekt
> > einen
> > Wert vom Typ Double zu. Warum deklarierst Du Zins nicht gleich als
Double?
>
> habe ich nachträglich gemacht, und dank eurer Hilfe erkannt.
Da Du offenbar mit Geldbeträgen rechnest, solltest Du evtl. überlegen, statt
des Datentyps Double, den genaueren Datentyp Decimal zu verwenden. Bei
Single und Double kann es wg. der rechnerinternen Darstellung zu
Rundungsfehlern kommen die sich möglicherweise unangenehm aufaddieren
können.
> >> txtVerzugszins.Text = Format(Zins, "#0.00 Euro / Cent")
> >
> > Das Ergebnis dieser Formatierung wäre z.b.
> >
> > "123,25 Euro / Cent"
> >
> > Ist das wirklich so gewollt?
>
> Ja klar wollte ich so.
Merkwürdige Formatierung.
Warum nicht 123,25 €?
> Ich hätte auch ein Label hinter der Textbox anbringen
> können, vielleicht mach ich das auch noch bin mir da noch nicht so
> Schlüssig.
Das würde Dir zumindest ersparen, vor dem Umwandeln des Textboxinhaltes zu
numerischen Datentypen das "Euro / Cent" abschneiden zu müssen.
> Ich hab noch kein Programm gesehen die sowas ausgeben.
Weil es wohl auch nicht sonderlich geschickt ist (wg. Typumwandlung) und
auch keine allgemeingültige Währungsbezeichnung ist.
> Wenn ich Lexware als
> Beispiel nehme schreiben die dieses immer als Label hinter der Textbox
wieso
> wenn es auch in der Textbox selbst geht. So hab ich mehr Platz für das
> Formular - Design.
Das Währungszeichen € würde von den Umwandlungsfunktionen erkannt.
> >> i = Format(txtGesamtforderungsbetrag.Text + Zins, "###.00 Euro")
> >
> > Auch hier geht es wieder kunterbunt durch alle möglichen und unmöglichen
> > Datentypen.
> > txtGesamtforderungsbetrag.Text liefert einen String.
> > Zins dagegen hast Du einen Wert vom Typ Double zugewiesen.
> > Du multiplizierst also einen String mit dem Wert von z. Das wäre so, als
> > würdest Du schreiben
> >
> > Objekt = "Käsekuchen" * 25.3
> >
> > Keine wirklich gute Idee.
> > Die Rückgabe von Format ist ein String und diesen weist Du nun der mit i
> > as
> > Object deklarierten Variablen zu. Warum deklarierst Du i nicht als das
was
> > es aufnehmen soll, nämlich als String?
>
>
> wie oben erwähnt unter 6.0 hat es so wie hier beschrieben getan...
Und wie ich oben ebenfalls erwähnt habe, dürfte das reiner Zufall gewesen
sein. Ein solches Durcheinander von Datentypen und die unnötige Verwendung
von Variants (VB5/6) bzw. Object (VB.net) fordert Fehler geradezu heraus.
> Ich hab
> es aber mittlerweile richtig gestellt.... Weil dann die Gesamtsumme nicht
> errechenbar gewesen wäre.
>
> >> txtGesamtbetragInklVerzugszins.Text = i
> >
> > Nachdem Du das Objekt i vorher mit einem String vergewaltigt hast,
zwingst
> > Du VB aus diesem Objekt wieder einen String zu machen, der von
> > txtGesamtbetragInklVerzugszins.Text erwartet wird.
> > Bei Deinem Durcheinander von Datentypen, insbesondere math. Operationen
> > mit
> > Strings, ist es eher reiner Zufall, wenn Du ein richtiges Ergebnis
> > bekommst.
>
>
> kann ich dir auch Wiederlegen das die Ergebnisse immer richtig waren da
ich
> alles mit Taschenrechner nachgerechnet habe.
Na ja, hoffentlich hast Du dabei auch wirklich alle bei späteren Anwendern
denkbaren Datenkombinationen und sontigen Unvorhersehbarkeiten
durchgerechnet. Ich melde da mal erhebliche Zweifel an. Die Teschenrechnerei
kann man sich sparen, wenn man für den richtigen Zweck die richtigen
Datentypen verwendet, zumal es mit dem Taschenrechner in einem erträglichen
Zeitraum kaum möglich sein wird, alle bei einer Anwendungen denkbaren und
manchmal auch vermeintlich undenkbaren Datenkombinationen durchzuspielen.
> Ich überlasse eigentlich nichts
> dem Zufall.
Doch genau das tust Du mit Deklarationen als Variant oder Objekt bzw.
sonstigen nicht zum Verwendungszweck passenden Typen bei der Deklaration von
Variablen. Wenn Du VB zwingst, automatische Typumwandlungen durchzuführen,
ist das immer ein reines Lotteriespiel, bei dem unerwartete Ergebnisse
auftreten können. Wobei man zum "können" getrost sagen kann: Sie werden
irgendwann mal auftreten.
> Das einzige was Falsch war ist wenn man einen Punkt anstatt
> eines Kommas eingegeben hat dann kamen falsche Werte raus. Aber das liegt
> wohl ehr an was ganz anderem....
Sowohl die Umwandlungsfunktionen von VB5/6 als auch die von VB.net erkennen
je nach akt. Ländereinstellung bzw. bei VB.net CultureInfo mal den Punkt
oder das Komma (oder auch evtl. andere Zeichen) als Dezimaltrenner oder als
Gruppierungszeichen. Die Online-Hilfe sowohl in VB5/6 als auch in VB.net
gibt darüber schon sehr bereitwillig und ausführlich Auskunft. Programmcode
kann sowohl in VB5/6 als auch in VB.net so gestaltet werden, dass er ohne
Codeänderung auf z.B. einem deutschen System das Komma als Dezimaltrenner
erkennt und auf z.B. einem US-amerikanischen System den dort üblichen Punkt
als Dezimaltrenner erkennt.
.... schnipp...
> Ich hab meinen Code ausgemistet Peter, ich gebe dir vollkommen recht, bin
ja
> auch noch ein Grünschnabel da darf man das ja :-).
Nein, gerade als Einsteiger sollte man konsequent und ohne Ausnahme auf
saubere und typgerechte Deklarationen achten. Option Explicit ist dabei
absolute Pflicht und auch Option Strict sollte abgesehen von wirklich sehr
wenigen Ausnahmefällen immer eingeschaltet sein.
> Du ob die Deklaration
> Objekt sinnvoll oder nicht ist, entscheidend für mich ist das das
Ergebniss
> damals ok war..
>
> Ach ja wenn Du Option Strict auf On wählst dann bekommst Du unter VB 2005
> noch ganz andere Probleme sobald Du mit Strings arbeitest. Deshalb lasse
das
> lieber auf Off stehen.
>
> Aber eins kann ich dir sagen dank eurer Hilfe wäre ich nicht soweit
> gekommen, das jetzt alles funktioniert und ich noch einiges dazu lernen
> konnte.
Irgendwie habe ich immer noch das Gefühl, dass Du nach der Methode "erst mal
probieren ... und wenn es dann funktioniert, wird schon alles richtig sein"
arbeitest.
Das hat aber nichts mit konsequent sauberer Arbeitsweise zu tun.
Erst mal Option Explicit und Option Strict einschalten, alle benötigten
Variablen und Konstanten dem jeweiligen Verwendungszweck angepasst
typgerecht deklarieren, Deklarationen "as Object" nur in Fällen, in denen es
wirklich unumgänglich notwendig ist, sind Voraussetzung für stabil und
fehlerfrei laufende Anwendungen. Wenn dann alle Regeln eingehalten sind und
der Code steht, folgt das ausführliche Testen der Anwendung bzw. einzelner
Anwendungteile.
Gruß aus St.Georgen
Peter Götz
www.gssg.de (mit VB-Tips u. Beispielprogrammen)
.
- Follow-Ups:
- Re: VS 2005 prof. Mathe - Problem
- From: Arno Lesmeister
- Re: VS 2005 prof. Mathe - Problem
- References:
- VS 2005 prof. Mathe - Problem
- From: Arno Lesmeister
- Re: VS 2005 prof. Mathe - Problem
- From: Peter Götz
- Re: VS 2005 prof. Mathe - Problem
- From: Arno Lesmeister
- VS 2005 prof. Mathe - Problem
- Prev by Date: Re: Groupbox inhalt auslesen
- Next by Date: Re: Datagrid Spalte unsichtbar machen
- Previous by thread: Re: VS 2005 prof. Mathe - Problem
- Next by thread: Re: VS 2005 prof. Mathe - Problem
- Index(es):
Relevant Pages
|
