Industrieminuten

[himitsu]

Zitat von StepByStep:

result := SimpleRoundTo((DT2 - DT1)*HoursPerDay, -2); Danke Uwe, das funktioniert jetzt wunderbar.

Zitat von himitsu:

HourSpan (man achte auf den Result-Typ)

HourSpan + RountTo oder HourSpan + RountTo+FloatToStr oder Format oder FormatFloat oder ...

Ein kleines - dokumentiert den Code nicht so schön wie z.B. HourSpan.

Zitat von hstreicher:

machte das aufaddieren von Arbeitszeiten beim erstellen von Arbeitsplänen

Ein schweizer Uhrenhersteller wollte mal, gegen Ende des letzten Jahrtausends, 'ne Uhr(zeit) mit 10 Stunden á 100 Minuten pro Tag einführen ... schade daß sich das nicht durchsetzte.

[Uwe Raabe]

Zitat von himitsu:

Ein kleines - dokumentiert den Code nicht so schön wie z.B. HourSpan.

Wenn dieses hier

Zitat von System.DateUtils.HourSpan:

HourSpan always returns a positive result and therefore the parameter values are interchangeable.

keine Einschränkung bedeutet oder sogar gewollt ist, dann würde ich auch HourSpan empfehlen.

[BadenPower]

Zitat von himitsu:

Ein schweizer Uhrenhersteller wollte mal, gegen Ende des letzten Jahrtausends, 'ne Uhr(zeit) mit 10 Stunden á 100 Minuten pro Tag einführen ... schade daß sich das nicht durchsetzte.

Und die Arbeitsverträge seiner Angestellten wären dann mit 8 Stunden pro Arbeitstag unverändert weitergelaufen.

Nette Idee!

[UliBru]

Zitat von Sir Rufo:

UPDATE Aber bitte keine MagicValues im Code benutzen sondern System.SysUtils.HoursPerDay

Wie es der Titel schon andeutet: woher weiss ich welche Konstante in irgendeiner der gefühlt tausend Delphi-Units definiert und verfügbar sind? Muss ich mir dazu alles vorher anschauen und dann auch merken? Wem ist das noch nicht passiert, dass er etwas für sich erfindet und dann feststellt, dass es das in der Bibliothek schon gibt. Oder besser, in den Bibliotheken und damit also noch mehrfach.

Ich verstehe zwar, dass es besser ist, z.B.

Delphi-Quellcode:

const
  StdProTag = 24;

zu verwenden als die Zahl 24 irgendwo in einer Funktion in einer Formel auftauchen zu lassen.
Aber muss man deshalb gleich immer die Monsterausdrücke wie System.SysUtils.HoursPerDay bemühen? Damit eindeutig ausgeschlossen wird, dass der Compiler irgendwo eine Definition HoursPerDay = 25 findet? Dann wäre doch die Definition eigener Konstanten sinnvoller, da weiss man was man hat. Oder?

[Mikkey]

Ich kenne die auch nicht, und mache das auch so

Delphi-Quellcode:

const
  StdProTag = 24;

Wenn ich dann irgendwann darauf stoße, dass es eine solche vorgefertigte Konstante in den Delphi-Tiefen gibt, mache ich daraus

Delphi-Quellcode:

const
  StdProTag = System.SysUtils.HoursPerDay;

... und gut is.

Allerdings ist das Verwenden der Tatsache, dass ein TDateTime ein double ist, genauso magisch, wie die 24. Deshalb halte ich eine solche Multiplikation für schlechten Code. Da es genügend Funktionen gibt, die fast alle denkbaren Anforderungen abdecken, brauchts so etwas nicht.

Wenn es doch so eine Anforderung geben sollte, kann man die benötigte Funktion entsprechend selbst erstellen.

[himitsu]

Zitat von UliBru:

woher weiss ich welche Konstante in irgendeiner der gefühlt tausend Delphi-Units definiert und verfügbar sind? Muss ich mir dazu alles vorher anschauen und dann auch merken?

Mit der Zeit lernt man, wo man für bestimmte Aufgaben meistens etwas findet und wo es sich wie zu suchen lohnt.

Wenn man weiß, daß es um einen Datumswert geht, braucht man nur noch un 2-3 Units zu suchen.
DateUtils und dort wo früher das Zeug rumgammelte, also vorallem die SysUtils.

Zitat von BadenPower:

Und die Arbeitsverträge seiner Angestellten wären dann mit 8 Stunden pro Arbeitstag unverändert weitergelaufen.

Eine Woche mit 10 Tagen ... und schon hast du dafür 5 Tage lang Wochenende.
Und bei 4 Wochen Urlaub im Jahr.......

[StepByStep]

Also nachdem das Rechnen nun einwandfrei funktioniert, möchte ich gerne eine TObjectlist in einem StringGrid ausgeben - das funktioniert bereits!
Es geht mir nur darum, dass ich in dieser Liste ein Kommentar habe (string) und ich dieses dort einfügen möchte.

Ich habe gelesen, dass man wohl keine Zeilenumbrüche in StringGrids machen kann, ist das richtig?
Ansonsten möchte ich nämlich so vorgehen (bisschen Pseudocode):

Code:

wenn Liste[i].DerString > Liste[i].DerString[60] (also länger als 60 Zeichen) dann
iZeichen := 60;
wiederhole:
wenn Liste[i].DerString[iZeichen] ungleich '' ist dann
iZeichen -1
ansonsten 
mache dort Zeilenumbruch
bis Leerzeichen kommt
schreibe String in StringGrid mit Zeilenumbruch

Soweit meine Idee...

[Uwe Raabe]

Zitat von StepByStep:

Also nachdem das Rechnen nun einwandfrei funktioniert, möchte ich gerne eine TObjectlist in einem StringGrid ausgeben

Dann empfehle ich dir, dafür einen eigenen Thread aufzumachen.

[Sir Rufo]

Zitat von UliBru:

Zitat von Sir Rufo:

UPDATE Aber bitte keine MagicValues im Code benutzen sondern System.SysUtils.HoursPerDay

Wie es der Titel schon andeutet: woher weiss ich welche Konstante in irgendeiner der gefühlt tausend Delphi-Units definiert und verfügbar sind? Muss ich mir dazu alles vorher anschauen und dann auch merken? Wem ist das noch nicht passiert, dass er etwas für sich erfindet und dann feststellt, dass es das in der Bibliothek schon gibt. Oder besser, in den Bibliotheken und damit also noch mehrfach.

Ich verstehe zwar, dass es besser ist, z.B.

Delphi-Quellcode:

const
  StdProTag = 24;

zu verwenden als die Zahl 24 irgendwo in einer Funktion in einer Formel auftauchen zu lassen.
Aber muss man deshalb gleich immer die Monsterausdrücke wie System.SysUtils.HoursPerDay bemühen? Damit eindeutig ausgeschlossen wird, dass der Compiler irgendwo eine Definition HoursPerDay = 25 findet? Dann wäre doch die Definition eigener Konstanten sinnvoller, da weiss man was man hat. Oder?

Du musst dir diese Monster-Ausdrücke nicht merken und auch nicht verwenden. Wenn du dann feststellst, dass es so einen Wert schon als Konstante gibt, dann kannst du ja auch ganz einfach übernehmen

Delphi-Quellcode:

const
  // StdProTag = 24;
  StdProTag = System.SysUtils.HourPerDay;

Ist aber im Prinzip dann auch egal, meine Bibliothek würde ich dann nicht mehr anfassen, sondern wie gezeigt entsprechend abändern.