Taschenrechner 2.0 - Der Multi-Rechner

[LDProgrammierer]

Also gut hier eine völlig neue Version des Taschenrechnes, die nun in der Mitte des Bildschirms startet und mehrere Funktionen hat Wie : Umfang/Flächeninhalt von : Quadrat, Rechteck
Flächeninhalt vom Dreieck und Prozentrechnen, ich habe bei der Gelegenheit auch gleich das PageControl getestet. Natürlich sind auch die Grundrechenarten vorhanen, und ein XPManifest hab ich auch eingebaut, das verleiht dem Programm einen guten Stil. Auf dem Bild ist leider nur die Seite mit den Grundrechenarten zuseheh. mfg

[fLaSh11]

Willkommen in der DP,

dein Programm ist schonmal ansprechend und einfach aufgebaut, was den Bediener erfreut :)

meine Vorschläge:

• "Programm beenden"-Button von den anderen räumlich oder stil-technisch abtrennen
• Ergebnis-Label dynamisch verschiebbar oder linksbündig auf die Form setzen, denn wenn man große Zahlen als Ergebnis erhält, gehen diese über den Rand des Fensters hinaus
• Division durch Null abfangen

[p80286]

Hallo LDProgrammierer,

Da mußt Du wohl noch ein wenig dran arbeiten:
5,3 - 5,4 ist nicht -0,09999999 !

Gruß
K-H

[blackfin]

Der benutzt halt SAP-Logik! :lol::lol:

[PhilmacFLy]

Für ein erstens Programm nicht mal so schlecht. Ich hab auch mal mit nem Taschenrechner angefangen.
Zwei Punkte zum verbessern:

-Programm in der Mitte des Bildschirms starten lassen
-Kein Label sondern ein Edit Feld zu Ausgabe der Ergebnisse verwenden, das man sie auch kopieren kann.

[p80286]

Zitat:

Zitat von blackfin (Beitrag 1042761)

Der benutzt halt SAP-Logik! :lol::lol:

Das ist ja das Schlimme, in der Zwischenzeit glaubt ja beinahe jeder, was einem der Computer vorsetzt.

Gruß
K-H

[LDProgrammierer]

Geht klar ich werde tun was in meiner macht steht um das Programm zu verbessern, ich werde es aber wahrscheinlich erst morgen schaffen eine bessere Version zu präsentieren. mfg LDProgrammierer

[OrNEC]

Genau, setze den Rechner in die Bildschirmmitte. Auf meinem Netbook kann ich das Prog nicht testen, da der außerhalb des Bildschirms geöffnet wird und in die Mitte kann ich es nicht ziehen.

[OrNEC]

Leere Felder muss du auch abfangen. :wink:

[aurikel_Max]

Da ist aber einer fleißig, hast du gerade Ferien (wenn man fragen darf)? Wir haben sowas ähnliches letztens in Informatik gemacht (nach nem knappen Jahr Delphi) - wobei die meisten das nicht hingekriegt haben:roll:

Mach weiter so:cheer:
Ich werd jetzt auch eine Runde weiter programmieren :coder:

[himitsu]

Wenn man ganz krank ist, kann man sich da auch noch einen Matheparser erstellen, also daß man "123 * 456" in ein Editfeld eingibt, das Programm sich dieses zerlegt und dann ausrechnet.
Und falls man dazu auch noch komplett beklopt ist, dann nutzt man nichtmal die komplexen Rechenfunktionen von Delphi und dem PC, sondern macht das auch noch selber (vorallem für Zahlen, welche nicht in einen Integer, Int64, Extended usw. reinpassen).

[Namenloser]

Das ist dann aber schon 'ne ganz andere Größenordnung :lol:

[PhilmacFLy]

Zitat:

Zitat von himitsu (Beitrag 1043023)

Wenn man ganz krank ist, kann man sich da auch noch einen Matheparser erstellen, also daß man "123 * 456" in ein Editfeld eingibt, das Programm sich dieses zerlegt und dann ausrechnet.

Am besten man zeigt oben dann in nem Label die Rechnung an die man getätigt hat, und unten im nem Edit das Ergebniss

[Edit]
also division durch null wird nicht abgefangen und du solltest schauen das man nur Zahlen in die Edits eingeben kann [/Edit]

[himitsu]

http://www.delphipraxis.net/140346-t...tml#post952017
und das steckt auch noch intern mit drin
http://www.delphipraxis.net/135569-m...athelib-_.html

Also es gibt zu diesem Thema schon viele Beiträge.
Es wird halt oft in Schulen gelehrt) und es ist auch ein gutes Einführungsbeispiel um sich mit dem Programmieren zu beschäftigen.
z.B. einfach mal nach Taschenrechner und MatheLib/BigMath suchen.

Oftmals liegt der Quellcode mit bei, so daß man etwas "abgucken" kann und auch aus den zugehörigen Threads/Beiträgen/Antworten kann man meist viele Informationen und Tipps rausziehen.
Also gut um sich ein paar Anregungen und eventuell andere Lösungswege anzusehn.

z.B. läßt sich ein Taschenrechner auch mit DLLs kombinieren.
Ein Taschenrechner wird zumindestens in vielen DLL-Tutorials verwendet, wo dann die unterschiedlichen Rechenoperationen quasi jeweils als Plugin vorliegen.

Zitat:

Zitat von PhilmacFLy (Beitrag 1043026)

[Edit]
also division durch null wird nicht abgefangen und du solltest schauen das man nur Zahlen in die Edits eingeben kann [/Edit]

Jupp. Wie gesagt, hier lassen sich viele Bereiche mit integrieren.
- Prüfung von Eingabewerten
- Fehlerbehandlung
- sogar GUI-Design
- uwm.

[PhilmacFLy]

Was auch noch ein schönes Addon währe was sich sogar ziemlich leicht machen ließe, währe ein Funktions Drucker

[blackfin]

Überfordert doch den Armen nicht so! :)
Ich finds toll, wenn jemand mit einem einfachen Taschenrechner anfängt und diesen (über evtl. lange Zeit) immer weiter Stück für Stück ausbaut.
Da gibt es ganz andere Kandidaten, die keinerlei Programmier-Erfahrung haben, aber mal schnell Half Life 3 programmieren wollen :lol::lol:

Von dem her: Nettes Programm, auch wenn es noch ein paar Bugs enthält, wird es sicher stetig wachsen. Weiter so! :thumb::thumb:

[himitsu]

Keine Sorge, für einen "Anfänger" und so als eines der ersten Projekte ist es schonmal nicht schlecht gelungen.

Heißt aber nicht, daß man ihm nicht doch schonmal ein paar Tipps geben kann, mit was er da Stück für Stück drauf aufbauen kann. :-D

[OrNEC]

Schau dir mal meine Rechner an, wenn du so weit kommst, dann kann aus dir was werden. :wink:

http://ornec.de

[blackfin]

Angeber :P

[mkinzler]

Ist mir zu kompliziert :mrgreen:

[p80286]

vielleicht sollten zunächst einmal die noch vorhandenen Unebenheiten beseitigt werden.
Es wäre schön wenn der Benutzer einen Hinweis bekäme welches Zeichen er als Dezimalkomma nutzen darf und welches wenn überhaupt als Tausender-Trennzeichen.
Wie oben schon erwähnt fehlt der Umgang mit leeren Eingabefeldern, und bei der Prozentrechnung hat es mich ja schon gejuckt mir den Ausgangswert berechnen zu lassen, aber das ging irgendwie so nicht!

Gruß
K-H

@orNEC hübsch (die Rose)

[OrNEC]

Zitat:

Zitat von blackfin (Beitrag 1043046)

Angeber :P

Also so hab ich angefangen, aber natürlich mit eurer Hilfe. :wink: Wie denn sonst. :-D

[blackfin]

War auch nur scherzhaft gemeint :wink:

[LDProgrammierer]

Ich weiß leider überhaupt nicht wie man eine Eingabe abfängt, könnte mir bitte jemand den Source-Code geben? Wäre sehr hilfreich. LDProgrammierer

[aurikel_Max]

Zitat:

Zitat von LDProgrammierer (Beitrag 1043374)

Ich weiß leider überhaupt nicht wie man eine Eingabe abfängt, könnte mir bitte jemand den Source-Code geben? Wäre sehr hilfreich. LDProgrammierer

Nun, du könntest mehrere Sachen machen .. um zB. dafür zu sorgen, dass nur Zahlen (und zB. Punkte) eingegeben werden, musst du das OnKeyPress-Ereignis von deinem Editfeld abfangen. Ich benutze hierzu Variante 3 von diesem Link (dies fängt allerdings nur Buchstaben ab).

Wenn du zB. auf eine Division durch 0 prüfen möchtest, so würde ich bei einer Division prüfen, ob der Divisor 0 ist. (if StrToFloat(edDivisor.Text) = 0 then ...)

[LDProgrammierer]

Danke ich werde ausprobieren ob es geht.

[LDProgrammierer]

Also ich habe das mit dem dividieren durch null verhindern leider irgenwie nicht geschafft obwohl ich folgenden Code verwendet habe

Delphi-Quellcode:

if strtofloat(edit2.Text)= 0 then ShowMessage ('Durch null darf nicht dividiert werden');

dann kann er das Programm das öffnen, jedoch zeigt er nicht die Nachricht die ich gezeigt haben wollte, selbst wenn ich durch null dividiere. Wenn ich jedoch folgenden code schreibe :

Delphi-Quellcode:

if strtofloat(edit2.Text)= 5 then ShowMessage ('Durch null darf nicht dividiert werden');

, also das er bei fünf eine Meldung ausgeben, soll und sonst weder Position noch irgendwas anderes am Code verändere erscheint doch eine Meldung. Was soll ich tun? Ich habe das Gefühl das liegt daran, das dann die Meldung floating point division by zero ausgegeben wird. Bitte helft mir :?

[Satty67]

Wenn eine Exception ausgelöst wird (hier Division durch 0) wird der nachfolgende Code bis zum Ende des Try Except bzw. Finally Block abgebrochen.

Vorm Berechnen auf 0 prüfen:

Delphi-Quellcode:

if strtofloat(edit2.Text)= 0 then 
  ShowMessage ('Durch null darf nicht dividiert werden')
else
  Berechnen;

[aurikel_Max]

Zitat:

Zitat von LDProgrammierer (Beitrag 1043657)

Also ich habe das mit dem dividieren durch null verhindern leider irgenwie nicht geschafft obwohl ich folgenden Code verwendet habe

Delphi-Quellcode:

if strtofloat(edit2.Text)= 0 then ShowMessage ('Durch null darf nicht dividiert werden');

dann kann er das Programm das öffnen, jedoch zeigt er nicht die Nachricht die ich gezeigt haben wollte, selbst wenn ich durch null dividiere. Wenn ich jedoch folgenden code schreibe :

Delphi-Quellcode:

if strtofloat(edit2.Text)= 5 then ShowMessage ('Durch null darf nicht dividiert werden');

, also das er bei fünf eine Meldung ausgeben, soll und sonst weder Position noch irgendwas anderes am Code verändere erscheint doch eine Meldung. Was soll ich tun? Ich habe das Gefühl das liegt daran, das dann die Meldung floating point division by zero ausgegeben wird. Bitte helft mir :?

Ehm .. ich bin mir nicht sicher, hast du nach deinem

Delphi-Quellcode:

IF StrToFloat(edDivisor.Text) = 0

auch ein Exit? Denn es darf ja nichts mehr geschehen, wenn du durch 0 dividierst.
Also:

Delphi-Quellcode:

IF StrToFloat(edDivisor.Text) = 0 THEN
begin
    ShowMessage('..');
    Exit;
end;

[himitsu]

Ich würde auch noch auf StrToFloatDef und TryStrToFloat hinweisen.

[Satty67]

Die beiden Funktionen würden sich fast schon aufdrängen.

Alternativ evtl. mit Try Except arbeiten:

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject);
var
  x,y : double;
begin
  y := 0;
  try
    x := 1 / y;
    // ShowMessage wird nie ausgeführt,
    // da der Code davor eine Exception ausgelöst hat
    ShowMessage(FloatToStr(x));
  except
    on E:EZeroDivide do
      ShowMessage('Durch 0 darf nicht dividiert werden.');
  end;
end;

€: geht ja um Gleitkommazahlen, Code angepasst

[LDProgrammierer]

Nein ich verwende keine doubles sondern Real :

Delphi-Quellcode:

var a, b, c : Real;

dann geht es ganz normal weiter

Delphi-Quellcode:

a:= strtofloat(edit1.Text)

usw.

[mkinzler]

Hallo LDProgrammierer,

was spricht den gegen die Verwendung von Delpi-Tags?
Ich habe in diesem Thread hier deine Beiträge schon mehrmals in der Hoffnung korrigiert, dass du es merkst!

Ich bitte dich in zukünftigen Beiträgen, bitte die richtigen Tags zu verwenden.

[Satty67]

Zitat:

Zitat von LDProgrammierer (Beitrag 1043711)

Nein ich verwende keine doubles sondern Real

Sind ja beides Gleitkommazahlen, real ist nur der kleinere Bruder ;-)

Verwendung von Real macht aber imho seit den Pentium-Prozessoren mit integriertem Co-Prozessor keinen Sinn mehr. Man könnte also gleich Double mit höherer Genauigkeit nehmen. Meine selbst in der Delphi 5 Hilfe wird schon geschrieben, dass Real im Prinzip veraltet ist.
Nachdem ich einfach in die Hilfe geschaut hatte, hab' es wohl mit Real48 verwechselt.

Real in aktuellen Version ist identisch mit Double.

[OrNEC]

Zitat:

Zitat von Satty67 (Beitrag 1043739)

Meine selbst in der Delphi 5 Hilfe wird schon geschrieben, dass Real im Prinzip veraltet ist.

Und was heißt veraltet? Ist Real gebrechlich und das Gedächtnis lässt nach oder wie? :|

[himitsu]

Real Single ist nur schöne knuffige 4 Byte groß und wenn einem der etwas kleinere Wertebereich und die geringere Genauigkeit ausreicht, dann ist dieser doch erste Wahl?

Ich nehm auch nicht überall Int64 oder gar irgendwas BigInt-Artiges, wenn mit doch ein Integer oder Byteausreichen würde.


Float sollte von der Größe mit dem Integer übereinstimmen, also einer Registerbreite.

[edit]
ach mist, jetzt hab'sch Float mit Real verwechselt

[gammatester]

Zitat:

Zitat von himitsu (Beitrag 1043748)

Real ist nur schöne knuffige 4 Byte groß und wenn einem der etwas kleinere Wertebereich und die geringere Genauigkeit ausreicht, dann ist dieser doch erste Wahl?

Nein, das alte real war 48Bit = 6Byte groß (und wird wohl jetzt auf double umgelenkt)

Zitat:

Zitat von himitsu

Float sollte von der Größe mit dem Integer übereinstimmen, also einer Registerbreite.

Warum? Was haben die Floatingpoint-Register mit 80Bit mit den normalen CPU-Registern zu tun?

[himitsu]

Das hat eher was mit Speicher-/Recordausrichtungen zu tun.


OK, Real = Double (nicht Siglge), aber egal ... Real ist auf jedenfalls kein "alter" Typ ... es ist nur eine "Umleitung", welche aktuell auf Double zeigt.

Real48 (in aktuellen Delphis) und das 6 Byte "Real" in alten Delphis ist wirklich obsolete.

[LDProgrammierer]

OK endlich habe ich es geschafft ich habe aber den folgenden Code verwendet:

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject);
var a, b, c : Real;
begin
a:= strtofloat(edit1.Text);
b:= strtofloat(edit2.Text);
c:= a/b;
if b = 0 then ShowMessage('Durch NULL darf nicht dividiert werden!') else
begin
 c:= a/b;
Edit3.Text := floattostr(c);
end;

end;

end.

[himitsu]

Das

Delphi-Quellcode:

c:= a/b;

vor der IF-Abfrage ist wohl noch zuviel.