führe ich mein programm aus so wird '¿' zu einem wert von dezimal -65, was bei einem signed interger dem binärwert von b1100 0001 entspricht.
Was Plantschkuh schreibt, ist richtig, dies hier jedoch nicht. In der üblichen 2erkomplementdarstellung hat -65 genau die Darstellung 0xBF (in 8 Bit – bei 16 Bit würde es dann so aussehen: 0xFFBF, bei 32 0xFFFFFFBF usw.).
Wahrscheinlich ist das Label so groß, dass der Text gerade mal hineinpasst. Dann ist es natürlich komplett egal, welches Alignment du dem Label gibst.
Weil's wohl über den Socket auch in eine 8bit-Darstellung gebracht wird.
(Das bezieht sich jetzt auf dein 55555-Zeichen):
Wenn du so ein Zeichen auf der Konsole ausgibst, dann muss es irgendwie in eine 8-bit-Darstellung gebracht werden. Typischerweise in latin-1, aber auch utf-8 ist heutzutage nicht unüblich. Im Fall von latin-1 kann das Zeichen natürlich nicht dargestellt werden, daher das ?. Falls es utf-8 ist, könnte trotzdem ein ? rauskommen, wenn die Konsole zwar utf-8 versteht, aber nicht weiß, wie sie das Zeichen darstellen soll. GUIs haben damit normalerweise kein Problem, weil sie intern soundso mit Unicode-Strings arbeiten und daher das Umkodieren entfällt.
SIGSEGV oder Exception?
Du kannst dem Ausdruck "j%6" nichts zuweisen. Ich verstehe auch nicht wirklich, was du vorhast.
Das Tray-Icon verschwindet immer dann auf die von dir beschriebene Art und Weise, wenn der Prozess nicht mehr lebt, der es erzeugt hat.
Fuer diesen Fall sind vermutlich die Methoden Scanner#hasNextLine() bzw Scanner#nextLine() besser geeignet, denn die arbeiten plattformunabhängig, mit System.getProperty('line.separator') als Delemiter. '\n' ist ja nicht zwingend das Zeichen für einen Zeilenumbruch.
Das soundso.
java-girl meinte anscheinend, dass der Scanner bei \n ein Token liefert (also wenn man auf der Konsole Enter drückt). Ja, tut er üblicherweise. Aber von "abbrechen" kann keine Rede sein. Du kannst ja auch noch mehr Zeilen eintippen wollen.
Würde mich sehr wundern, wenn's da was fertiges gäbe, nachdem das ja sehr Win32-spezifisch ist. Auf anderen Plattformen kann man die Files ja beliebig "unter dem Hintern" wegziehen.
Eine Menge Arbeit hast du dir da jedenfalls gemacht ;).
Der Scanner hört nicht bei EOL auf.
Nein, ist vollkommen wurscht. Normalerweise wartet man bei der Konsole auf '\n' und bricht dann ab. Stell dir einfach den Zeilenumbruch als Delimiter ein dann müsste der Scanner eh aufhören.
Im Allgemeinen nicht.
denn welcher Benutzer gibt nach jeder eingabe ein EOF ein (Bei Konsolenanwendungen)?
Welcher Benutzer macht Eingaben händisch auf der Konsole? Nachdem man die Sache ja meistens nicht nur einmal macht, verwendet man soundso immer ein File.
Das ist gar nicht ad absurdum geführt, aber wenn das Programm auf einer Konsole läuft, kann es ja nie wissen, ob noch was kommt, daher muss es warten.
Wenn du es beenden willst, musst du ein EOF schicken (üblicherweise Ctrl-D unter Unix und Ctrl-Z unter Windows). Oder du schickst mittels Pipe ein File in den Standardinput deines Programms hinein. Dann ist es einfach aus, wenn das File aus ist.
Dort, wo population deklariert wird. Aber die Stelle zeigst du uns ja nicht.
Wenn du wüsstest, dass du hier bist, weil du Hilfe brauchst, würdest du Leute, die dich auf dein Problem hinweisen, nicht anmachen.
Ich hab gedacht, da muss man 100 von der Größe abziehen. Stimmt aber anscheinend nicht. Aber v.a. hab ich mich verlesen. Sorry.
Trotzdem verwendest du Ganzzahlendivisionen und handelst dir dadurch Probleme ein. Nachdem Größe häufig zwischen 100 und 200 liegen wird, ist "groesse/100" in diesen Fällen immer 1. Das Quadrat davon auch. Wie ich gerade sehe, hast du's eine Zeile weiter oben sogar richtig gemacht...
Abgesehen davon, dass die BMI-Berechnung soundso falsch ist, verwendest du Ganzzahlendivision, die nicht das Ergebnis liefert, das du dir erwartest. Wenn du dir einfach den Wert der Variablen BMI ausgeben würdest, dann könntest du auch erkennen, dass die ifs nicht dein Problem sind.
So wie es dasteht, macht es genau das, was es soll.
1. Bitte verwende code-Tags.
2. Das Programm beendet sich wenn zufallszahl != 0. Und das ist wohl immer der Fall.
3. Du musst noch viel lernen.
Das Umbenennen wird typischerweise nicht aufgezeichnet (in Unix zumindest nicht, bei NTFS bin ich mir nicht ganz sicher). Falls doch, könntest du am ehesten mit GetCreationTime Glück haben. Aber was auch immer du tust, es ist wahrscheinlich eine schlechte Idee, sich auf das Filesystemdatum von Verzeichnissen zu verlassen.
Ja ok, das Paper kenne ich. Das war das, was ich mit der Uneinigkeit über Compilertransformationen gemeint habe.
Ad Itanium - interessant; habe mit dem Teil leider keine praktische Erfahrung.
