geloescht_Newlukai

onClick="document.<Formularname>.Color.value+='#ffff00';"

Hast ja recht.

Ich bin mathematisch nicht in Topform. Aber der Satz gilt doch nur im rechtwinkligen Dreieck. Bei der Aufgabenstellung wird über das aufgespannte Dreieck nichts gesagt.

Meine Interpretation der Aufgabe: Drei Punkte beschreiben im 2-dimensionalen Raum bekanntlich ein Dreieck. Nehmen wir z. B. das rechtwinklige Ideal-Dreieck mit den Kantenlängen 3, 4 und 5. Es sind 3 Wege vorstellbar, die die Punkte verbinden: 3 + 4 = 7 3 + 5 = 8 4 + 5 = 9 Deine Aufgabe besteht nun darin, die beiden Punktepaare auszugeben, die über den kürzesten Weg verbunden sind. Vektoren dürften dabei hilfreich sein. An sich mußt Du für jedes Punktepaar den "Verschiebungsvektor" berechnen. Mit diesem kannst Du dank dem Satz des Pythagoras die Strecke zwischen den Punkten berechnen. Dann mußt Du nur noch die kleinste Strecke raussuchen.

Ich denke, daß das Caching vom Browser erledigt wird und Dein Programm als Applet keine Chance hat, daran etwas zu ändern. Ist aber nur eine Vermutung.

So, wie ich das verstehe, erhält Dein Applet aus irgendeiner Quelle ein Bild und soll dies anzeigen. Und alle 2 Sekunden soll bei der Quelle noch einmal angefragt werden, ob ein neues Bild da ist? Die sleep-Funktion gibt's: Thread.sleep(int)

Stimmt. Aber zur Not schreibst Du statt f.newLine einfach f.write("\n"). Richtig. Meiner Meinung nach gehört es aber immer noch in die Rubrik "Grundlagen" den Rückgabewert (der übrigens ein String ist, falls Du noch nicht in die API geschaut haben solltest) von JOptionPane.showInputDialog() einem String zuweisen zu können.

Dann weißt Du wie man den Rückgabewert von JOptionPane.showInputDialog() in einem String speichert. Und Du weißt, was der Konstruktor FileWriter(String fileName, boolean append) bedeuten könnte. Zur Not hilft auch dieser JavaDoc-Auszug des genannten Konstruktors: Wahrscheinlich habe ich meine Erwartungen an die Uni immer zu hoch gesteckt. Ich dachte immer, Studenten, die irgendwas programmieren, wissen, was eine Funktion, eine Prozedur, eine Parameterliste, ein Rückgabetyp und eine Zuweisung sind. Mehr mußt Du nicht wissen, um die 2 Probleme zu beheben.

Klar, könnte ich das, aber Jaraz hat Dich ja schon drauf gestoßen. Google hat einen Übersetzer, der sagt Dir, was 'append' bedeutet. Was gibt Dir denn JOptionPane.showInputDialog(this, "Geben Sie Ihren Namen an") zurück? PS: Ja, ich könnt' Dir alles vorkauen. Ich bin aber nicht im geringsten dazu bereit. Das alles hier gehört zum Thema "Grundlagen" und wenn ich Dir die vorkaue, lernst Du nichts dabei.

paint() wird imer dann ausgeführt, wenn das Fenster gezeichnet werden muß, also bei jedem Verschieben, etc ... Richtig. Ist nur eine Kleinigkeit. Die findet man in der Java-API. Tip: Schau' Dir die verschiedenen Konstruktoren von FileWriter an. Schau' mal, wenn Du grad in der API rumblätterst, nach JOptionPane.

Klar, daß 'ne Exception geworfen wird. Ich vermute mal ... eine IndexOutOfBoundsException? Liegt wohl daran, daß Du zwar das Array highscArr initialisierst, aber keine Größe angibst. Das mehrfache Auftreten der "Bitte Namen eingeben"-Meldung könnte daran liegen, daß Du das ganze in die paint-Methode geschrieben hast.

Das ist schon klar. Nur solche Stellen wie Dateihandling mußt Du ja nicht in ein PAP fassen. Statt PAPs würde ich aber Struktogramme verwenden.

Frag' Microsoft mal nach einem kompletten PAP von Word. Die werden Dich auslachen und dann ... nochmal auslachen. Im Ernst. Ich hoffe nicht, daß Du vorhast zu einem kompletten Programm vorab ein komplettes PAP zu erstellen? Das wird nicht funktionieren. Konzepte sind schön und gut. Aber PAPs und Struktogramme taugen nur zur Veranschaulichung eines Algorithmus innerhalb des Programms. UML kann man verwenden um das ganze Programm abzubilden, aber auch das ist zu aufwendig. Damit kann man interessanten Code visualisieren, aber ein ganzes Programm?!? Sobald Du irgendwo Code änderst mußt Du Dein PAP eh' wieder anpassen. Wenn Du nur die interessanten Stellen vorher konzeptionierst, ist der Rattenschwanz bei einer kleinen Codeumstellung wesentlich kürzer.

Die muß Du nicht großartig "integrieren". Du baust die Zahl im Textfeld so zusammen wie bisher, nur eben mit einem Komma. Und dann verwendest Du Double.valueOf(String) um den String in ein Double zu casten. @perdi: Das kann ich alles nachvollziehen und stimme Dir zu. Doch mit den Menschen ist es wie mit den Bäumen im Wald: alle von der gleichen Sorte und trotzdem unterschiedlich. Es mag viele Leute geben, die lernen so wie Du, wie z. B. ich Aber gerade am Anfang ist so etwas viel schwerer als die gute alte 'trial-and-error'-Methode: Lernen, ausprobieren und dann drübersehen und nachschauen, wo man was besser oder einfacher machen kann. Ich sag' ja nicht, daß die Konzepte weniger wichtig seien. Ich denke nur, daß man die beim Lernen des Entwickeln selbst, diese etwas weiter hinten anstellen kann.

1. Es würde ungemein helfen, beim nächsten Mal die Fehler zu notieren. Damit kann man viel anfangen. Aber egal. Dieser Codeschnipsel wirft bei mir einige Fragen auf. Als erstes vor allem: Wozu 2 Durchgänge? Du benötigst nur einen. Das was Du im 2. Durchgang machst, solltest Du beim Drücken aug '=' machen. Eine Zahl wird eingegeben Ein Operator wird gewählt. Die Zahl wird gesichert. Eine zweite Zahl wird eingegeben. Es wird '=' gedrüückt. Die eingegebene Zahl wird gesichert (Zahl2) und das Ergebnis ausgegeben. Wenn Du das so umsetzt, verschwindet Problem 2: Wenn es der erste Durchgang ist, setzt Du am Ende die Variable Durchgang auf 2. Danach kommt eine Abfrage, ob Durchgang auf 2 gesetzt ist, was logischerweise der Fall ist. Dann liest Du die eingegebene Zahl aus ("") und versuchst diese zu parsen. Es wäre schön, wenn kein Fehler geworfen würde, aber das läßt sich dann nicht vermeiden. Denn was sollte parseInt() im Fehlerfall sonst tun? 0 zurückgeben klappt nicht, denn im String könnte ja 0 stehen. Und zwei gleiche Ergebnisse, einmal für den Fehlerfall, einmal für den "korrekten" Gebrauch, sind sinnfrei.

Meiner Meinung nach ja. Etwas zu idealistisch. Es wird doch oft erwähnt, auch von Dir, daß man Programmieren nur durch Programmieren lernt. Wenn man vom Programmieren noch nicht so den großen Plan hat, geschweige denn von ganzen Klassenkonstrukten, und froh ist mit primitiven Datentypen etwas anfangen zu können, dann kann man den Taschenrechner ruhig dreckig zusammenklimpern. Auf den funktionierenden Taschenrechner folgt das geilste beim Programmieren: das Erfolgsgefühl. Du merkst, da funzt was. Wenn ich hier klicke, passiert das und das. Und Du machst weiter, lernst mehr über OOP und das ganze Drum und Dran. Wenn Du Dich dann nochmal mit der Aufgabe hinsetzt, einen Taschenrechner zu programmieren, wirst Du ganz anders an die Sache rangehen. Mit Konzept und allem Geschnörkel. Bei mir war's so; und auch Du wirst anfangs, wie jeder andere Entwickler, dreckig programmiert haben. Das ist nicht schlimm, es ist der Anfang. Schlimm wäre es, wenn man nicht dazulernt. @DarkNeon: Mach' Dir keine Sorgen. Wir streiten nicht. Nur wieder eine normale Grundatzdiskussion zwischen Entwicklern

Sowas dürfte man doch mit einem regülären Ausdruck gehen. Du legst ein Pattern an, daß alle Deine unerlaubten Zeichen enthält und sobald das matcht, weißt Du: Schissendreck.

Langsam. Er soll das mal eben als Hausaufgabe machen. Da muß man nicht unbedingt ganze Klassenstrukturen anlegen. An sich reicht folgende "Knauberei": - Zahl zusammenbauen bis auf einen Operator geklickt wird. - Zahl in einer Variablen sichern. - In einem Integer (0: +, 1: -, 2: *, 3: /) den Operator sichern. - Zahl zusammenbauen bis auf '=' geklickt wird. - Berechnung durchführen und ausgeben. Leider hast Du das große Glück, daß ich diese Woche nicht mehr an meinen Taschenrechner, der ähnlich funktioniert (heute würde ich das anders implementieren), rankomme.

Ich hab's auch nur über Java ist auch eine Insel und die anschließende Praxis im Betrieb gelernt. Und langsam aber sicher will ich von Java nicht mehr weg. Heute morgen hatten wir in der BS wieder OOP mit C++. Thema Typumwanldungskonstruktor. Fragt mich nicht, warum man da einen extra Begriff für erfinden muß, aber egal. Aufgabe war es eine Klasse zu schreiben, die einen Konstruktor anbietet, der nur ein char-Array entgegennimmt. Mit den Methoden aus string.h war dann das Array zu parsen. In Java 3mal einfacher.

Wo genau hakt es denn? Du hast doch alles nötige schon im ersten Programm gemacht. new FileOutputStream("schueler.txt"); fileOut.write(text.getBytes(), 0, text.length()); fileOut.close(); Mehr ist es nicht. Statt "text" benötigst Du halt den Inhalt aus dem zu schreibenden Textfeld, also z. B. textfeld.getText();

das mahcst du indm du dem prog sagst es soll bei drcken eines buttons save die eingaben in eine textdaei speichern und das geht genauso wie oben in dem prog

Da muß ich zustimmen. Aber der größte Nachteil an Typo3 ist die Lernkurve. Um mit diesem CMS gut umgehen zu können, kannst Du vorneweg 1-2 Wochen Intensivtraining einplanen. Auch ich hab' mich an dem Teil versucht. Aber für eine kleine persönliche Homepage kann ich nur etomite empfehlen. Mit etomite kannst Du nämlich auch jedes Layout umsetzen und das um einiges einfacher. Der größte Nachteil den ich daran aber sehe, ist das Entwicklerteam. Nicht das es nicht gut wäre, das Teil ist absolut spitze. Aber man kann die Entwickler an einer Hand abzählen.

Du sollst das ganze also in C implementieren (nicht C++?)? Sorry, aber in C/C++ bin ich nicht ganz so fit. Vielleicht hakst Du da nochmal eher im entsprechenden Forum nach.

np Dann wird's etwas schwieriger, da Du dann vor dem Tauschen erst einmal durch die Liste "latschen" mußt, um die Knoten vor den zu tauschenden Knoten zu finden. :confused: Ach so. Du meinst, ob das in der main reicht?!? Naja. Wenn es nur eine Übung ist, sicher. Eleganter ist natürlich eine Klasse Liste, die mehrere Knoten hat. Liste bietet dann noch eine Methode exchange(KnotenA, KnotenB) an, die dann das gewünschte fabriziert. Streng genommen ist sogar Liste unnötig. Du benötigst ja eigentlich nur den Anfang der Liste. Aber das sind alles listen-implementierungs-spezifische Geschichten. :hells: Das waren wir alle mal. Es gibt keine doofen Fragen. Nur doofe Antworten

Einfach oder doppelt verkettet? Im Prinzip hast Du also nur 2 Zeiger. Die zeigen auf Knoten, die jeweils einen Zeiger auf den nächsten Knoten haben. Du mußt die Zeiger "umbiegen": Knoten B zeigt auf C und Knoten E zeigt auf F. B und E sollen getauscht werden. D. h. Knoten B muß auf F und Knoten E auf C zeigen. A -> B -> C -> D -> E -> F // wird zu |-------------| A -> B |-> C -> D -> E |-> F |-----------------| Das ist dann aber erst die Hälfte. Denn jetzt kommen noch Knoten A und D ins Spiel. A zeigt auf B und D auf E. Um die Knoten B und E zu tauschen, muß A auf E und D auf B zeigen. Wenn Du das geschafft hast und einfach den Zeigern folgst, erhältst Du A -> E -> C -> D -> B -> F