_Arvid_

Ich möchte an dieser Stelle (eigentlich wie sonst auch in solchen Belangen) auf das Framework Forms von JGoodies verweisen. Das beinhaltete FormLayout des Frameworks ist äußerst flexibel und recht einfach zu handhaben (siehe auch Einführung in Benutzung (Achtung: Link auf PDF)). In der Regel sollte man mit dem Wort "mächtig" sehr vorsichtig sein, insbesondere bei Programmbibliotheken. Aber bei Forms bin ich irgendwie immer wieder gereizt, genau das zu behaupten: Forms ist verdammt .... na, ich sag's mal lieber nicht. Auf jeden Fall ist Forms eine wahrhaft gute Lösung für Layoutprobleme mit Bedienoberflächen in Java. Daher also eine echte Empfehlung!

Ich fand damals das Tutorial auf Regenechsen.de ganz nett. (Nein, "nett" an dieser Stelle nicht als "kleiner Bruder von Schei?e", sondern als "gut". ) Beste Grüße Arvid

Hi, ich selbst hab erst vor wenigen Wochen erstmals Linux installiert (openSuSE 10.1) und ich bin folglich auch noch Neuling. Ich habe bislang sehr viel damit herum gespielt und auch diverse Konfig-Dateien von Hand bearbeitet (allein schon aus dem Grunde, Linux besser kennenzulernen). Dabei habe ich sogar schon meine menu.lst (von Grub) zerschossen und auch die xorg.conf (von kde). Mehrmals... Aber bisher hab ich immer alles wieder hinbekommen. Wenn ich es mal nicht mehr schaffen sollte, das System gerade zu biegen (was mit meinen marginalen Linux-Kenntnissen mal nicht auszuschließen ist), dann würde ich es einfach neu aufsetzen. Und selbiges würde ich dir an dieser Stelle einfach mal raten. Platt machen und neu rauf damit! (Es sei denn, du hast mittlerweile eine Lösung gefunden.) ...So viel zum Thema Noobs helfen Noobs.... Beste Grüße Arvid.

Wie schon eben geschrieben: Der Typ (bzw. die Klasse) der Rückgabe darf sich nicht unterscheiden, wenn du die Methode überschreibst.

Doch, das kann sehr wohl sein. Du sollst die Methode ja auch nicht umbenennen (das ist sowieso nicht möglich!). Du sollst sie überschreiben. Dabei darf sich weder der Name, die Parametersignatur noch die Klasse des Rückgabewertes ändern. Es ist einzig möglich, die Kapselung nach gewissen Regeln zu ändern (also nicht frei nach Belieben!). Schau dir in der API Doc von Java die Methode toString() mal an. Vielleicht fällt dir ja der Fehler auf, wenn du ihren Namen mit dem Namen deiner toString-Methode vergleichst. Danach überschreibe sie korrekt. Behalte den Namen bei (achte auch auf Groß- und Kleinschreibung) und der Rest ergibt sich von allein. Als Ausgabe solltest du dann den Namen deiner Teilnehmer-Klasse erhalten, ganz ohne den Hash-Code. Sofern du die Klasse in einem Package hast (ich vermute mal, dass du das nicht hast), wirst du auch noch das Package davor erhalten. Lies dich am besten mal durch die Einsteiger-Lektüre für Java. Einführungen und Tutorials. Derer gibt es unzählige, wie zum Beispiel die Java-Tutorials von Sun. Grüße aus HH Arvid.

Lies dich schlau! print(int i) der Klasse PrintStream Du solltest deine int-Variable in einen String konvertieren, ehe du sie auszugeben gedenkst. Hierfür gibt es mehrere Möglichkeiten. Siehe auch Java Tutorial - Converting Between Numbers and Strings. Beste Grüße, Arvid.

[...Dann möchte ich mal an perdi's Ratschlag, dich in Grundlagenforschung zu vertiefen, anknüpfen...] Des Weiteren musst du deinem Ausbilder / Betreuer / Aufgabengeber / whatever sofort sagen, dass du nicht weiter weißt oder einen Lösungsansatz brauchst. Bringe ihn dazu, es mit dir notfalls gemeinsam zu machen, wenn du wirklich nicht weiter weißt. Auf jeden Fall musst du Kund tun, dass du das (noch) nicht alleine kannst. Fange bloß nicht an, dich zu genieren, Fragen zu stellen. Dafür bist du ja schließlich Azubi. Du bist eben noch am Lernen. Da ist das mehr als legitim, etwas nicht zu wissen oder zu können (das gilt im Übrigen auch über die Ausbildung hinaus). Und genau daran kann man arbeiten, auch gemeinsam mit Ausbilder oder Kollegen. Und ganz ehrlich: Zu Beginn meiner Ausbildung hätte ich da auch auf der Stelle getreten. Ich hätte sicher auch nicht gewusst, wo ich anfangen soll. Also nochmal: Fragen, fragen, fragen. Das ist keine Schande. Und schon gar nicht als Neuer. Und im Idealfall gleich deinen Ausbilder fragen und nicht hier (soll nicht heißen, dass wir nicht gerne Fragen beantworten). Aber lasse deinen Ausbilder ruhig wissen, wo du stehst. Sonst werden seine Anforderungen immer größer und plötzlich siehst du keine Hand mehr vor Augen, kannst deine Aufgaben nicht mehr bewältigen und dein Ausbilder fragt sich warum: "Du hast ja sonst nie was gesagt. Ich dachte, du kannst das alles ..." Kein guter Ausbilder würde dir schräg kommen, wenn du mal an einer Stelle nicht weiter kommst. Also zier dich nicht, es ihm zu sagen. Wie gesagt - ich persönlich hätte da auch Probleme mit gehabt. Ich finde, das ist auch eine sehr gewagte Aufgabe für neue Azubis. Mehr kann ich dazu (glaub ich) erstmal nicht sagen. Beste Grüße! Arvid.

Ich möchte mich an dieser Stelle gerne einmal selbst zitieren Damit wollte ich zum Ausdruck bringen, dass eben nicht auf diesen einen Post von mir geantwortet wird. @alle: Ich wollte wirklich nur etwas mit dem Zaunpfahl winken und Kaeyu nichts weiter als einen kleinen Tipp für die Zukunft auf den Weg geben. Also macht den Kleinen () jetzt nicht fäddich... @Kaeyu: Ich hatte nicht von dir erwartet, dich zu rechtfertigen. So war das nie von mir gemeint. Ich kenne Situationen, in denen es einfacher ist, mal eben jemanden zu fragen, anstatt selbst darüber einen Moment nachzudenken (oder in der entsprechenden Dokumentation nachzuschauen). Insofern verstehe ich jegliche Zuneigung zum "Schnell-mal-die-Frage-im-Forum-stellen"-Vorgehen. Aber ich wollte trotzdem Alternativen aufzeigen und einen Denkanstoß geben. Ich wollte, dass du mal überlegst, welchen Vorteil es für einen selbst hat, wenn man sich ohne fremde Hilfe zu helfen versucht. Najut. Ich denke, das genügt wieder von mir. Macht's jut, ihr Nasen! Beste Grüße, Arvid. @Moderator: So wie ich das sehe, ist die eingangs gestellte Frage beantwortet worden. Der Thread kann wohl geschlossen werden. Und jetzt noch eine kleine Entschuldigung von mir, dass ich so offtopic wurde und damit auch eine Offtopic-Diskussion entfachte.... T'schulliung! =)

Mal etwas offtopic. @Kaeyu: Ist nicht böse gemeint.... Aber ich denke, du solltest nicht jedes kleine Problem hier im Forum erfragen, sofern es mit etwas Überlegung oder auch mit etwas Recherche selbstständig hätte gelöst werden können. Wirklich, nimm das nicht persönlich. Ich habe lediglich den Eindruck, dass du dich mit der kleinsten Lapalie an uns wendest, was in zweiter Linine natürlich lobenswert ist, da du ja soziale Bindungen aufzubauen und aufrecht zu erhalten versuchst. Aber in erster Linie würde es dir wesentlich mehr helfen, wenn du selbst mal genau überlegst, warum dein Problem überhaupt auftritt und anschließend wie du es (auch ganz ohne fremde Hilfe) lösen kannst. Ich denke, nur so kannst du dich am erfolgreichsten weiter entwickeln. Sicherlich sehen es nicht alle hier in diesem Forum so wie ich. Du wirst also wahrscheinlich weiterhin Antworten auf deine Anfragen erhalten. Aber ich möchte dir ans Herz legen, darüber wenigstens mal nachzudenken. Wo möchtest du mit der Java-Entwicklung mal hin? Und willst du da lieber mit fremder Hilfe hin? Oder möchtest du dich auf dich alleine verlassen und dabei etwas viel wichtigeres als einfach nur neues Wissen gewinnen? - Nämlich Erfahrung und die Fähigkeit, selbstständig komplexe Zusammenhänge zu erkennen und sie zu bearbeiten? Für welchen Weg du dich auch immer entscheidest: Ich wünsche dir weiterhin viel Erfolg beim Lernen von Java im Speziellen und im Allgemeinen! Beste Grüße aus HH. Arvid. post scriptum: Ich erwarte keine Antwort darauf. Ich erwäge nicht, hier eine Grundsatzdiskussion oder Ähnliches loszutreten. Ich wollte nur mal meine Gedanken zu dem Vorgehen äußern, jeden Schlonz, und sei er noch so klein und nichtig, im Fachinformatiker-Forum an die Leute zu bringen.

Wie viel Prozent wovon? ... Von der umschließenden Komponente? Zum Beispiel ein Fenster mit der Größe x % von der Auflösung? Oder ein JLabel mit der Größe x % von der Fenstergröße? Mit Boardmitteln von Java ist das meines Wissens nicht möglich. Aber das heißt nicht, dass du sowas nicht auch selbst mal implementieren kannst. Gruß, Arvid.

Ich verstehe dein Problem ehrlich gesagt jetzt nicht richtig. :confused: Ich versuche es trotzdem..... XML-Elemente können nicht "aufgerufen" werden, sondern sie werden gelesen/geschrieben. Was drum herum passiert, hat nichts mehr mit XML zu tun. Wenn es darum geht, die Elemente nur zu ermitteln, kann ich dich wieder auf die API Doc verweisen. Neben getchild(String) gibt es auch getChildren(String). ...Ob es das ist, was du suchst...? Welches? Element "ZWEI"? ==> Das hast du doch schon "an der Hand". Anderenfalls aus dem Root-Element holen mit getChildren("ZWEI"). Oder meinst du etwa das Root-Element selbst? ==> API Doc - Document#getRootElement(). Es gibt jetzt genau 3 Möglichkeiten: 1. Ich habe dir zufälligerweise geholfen, ohne dein Problem wirklich verstanden zu haben. ==> Thema beendet. 2. Ich habe dir nicht geholfen. ==> Du musst deine Frage etwas ausführlicher erklären, so dass auch ich dein Problem verstehe. (Sonst kann dir niemand richtig gut helfen.) 3. Ich habe dir nicht geholfen. ==> Du musst die Dokumentation(en) lesen. (Anmerkung meinerseits: Das ist mein absoluter Favorit. wie sagt man doch so schön: Wer lesen kann, ist klar im Vorteil.) Punkte 1 und 3 sind natürlich die Idealfälle. Wenn du den 2. Punkt bevorzugst, dort aber deine Probleme hast, dann ist das nicht schlimm. Nimm dir einfach etwas mehr Zeit zur Formulierung deiner Problematik. Und vor Allem: Lies sie nochmal in Ruhe durch, bevor du sie abschickst. Gruß. Arvid.

...Schon mal daran gedacht, in die Dokumentation zu schauen? Oder in die API Doc? Dort würdest du sehr schnell finden, dass du Kind-Elemente eines Elements mit der Methode getChild(String) ermitteln kannst, siehe auch http://jdom.org/docs/apidocs/org/jdom/Element.html#getChild(java.lang.String). Tipp für die Zukunft: Erst gucken, dann fragen. =) Grüße aus Hamburg! Arvid.

Die Meldung ist eindeutig. Das hast du ja bereits erkannt. Dass du kein root-Element hast, ist nicht wirklich XML-konform. Auf die Schnelle fällt mir kein XML-Parser ein, der das kann, was du möchtest. Auch ein Beispiel, wieso man soetwas machen wollte, fällt mir nicht ein. Was spricht also dagegen, um alle ersten Elemente herum ein root-Element zu legen? Dann wäre dein XML-Dokument "well-formed" und du hättest mit dem Parser keine Schwierigkeiten. Wer oder was auch immer das XML-Dokument schreibt, welches du auslesen möchtest. Ich denke, er/sie/es sollte lernen, dass XML auch Regeln hat. Wenn du darauf keinen Einfluss hast, kann ich an dieser Stelle keine weitere Hilfe anbieten. :-/ Grüße. Arvid. =)

macht euch nix draus, ihr freunde der lederkugel! deutschland ist doch noch immer exportweltmeister.

Benutze auf jeden Fall den Link von Enrico. Das Tutorial ist wirklich sehr empfehlenswert. Bei Formularen kommst du natürlich auch nicht drum herum, die Felder und Labels und Buttons usw. auf dem Panel anzuordnen. Hierfür musst du dich entsprechend auch mit LayoutManagern auseinander setzen. Ein entsprechender Abschnitt im Tutorial hilft dir da weiter. Wenn du damit durch bist, kann ich dir zusätzlich noch das FormLayout von JGoodies empfehlen, einem sehr flexiblen und mächtigen LayoutManager. Darüber hinaus kann ich dir noch jenen Link nennen. Das ist eine Sammlung weiterer frei nutzbarer Java-Bibliotheken, welche ihren Sinn in der Unterstützung der Dialogentwicklung mit Swing haben. Das sind also teilweise recht nützliche Sachen und auch teilweise nur sinnfreie Spielereien, die niemand benötigt. Ich finde, allemal einen Blick Wert. Zunächst solltest du dich aber wirklich auf das Basiswissen konzentrieren und das Java Tutorial von Sun durcharbeiten, es ist tatsächlich der Klassiker schlechthin. Auf einige Fragen kann dir sicher auch die Insel eine Antwort geben.

Was denn nun: Werden sie gern gesehen oder nicht? Wenn sie sowieso nicht gelesen werden: Wozu dann solch eine Folie...? - Vollkommen überflüssig also! Mach einfach auf jeder Folie, auf der sich eine Grafik befindet unter die Grafik einen kleinen Vermerk (muss nicht unbedingt Schriftgröße 20 sein... ), in dem steht, wo sie her ist. Zum Beispiel: "Gefunden auf www.blablubb.de/visualisierungen" Oder wenn es vielleicht von dir selbst ist: "Erstellt von Mr Krabs" Oder entsprechend vermerken, dass die Grafik Eigentum deiner Ausbildungsfirma ist. 'N Copyright setzen oder so... Aber eine ganze Folie für so einen Schmonsens halte ich für keine gute Idee. Gruß Arvid

Ich sehe hingegen einen recht großen Unterschied. Bei der von dir aufgezeigten zweiten Variante lässt sich zwar vielleicht ermitteln, von welcher Klasse aus die Methode liesTabelleBla() aufgerufen wurde und sicher auch noch die Klasse darüber und so weiter. Das gibt ja der Stacktrace schließlich einiges her. Aber mit der ersten Variante kann man noch zusätzlich ermitteln, unter welchen Umständen die Methode liesTabelleBla() aufgerufen wurde, als sie abflog. Man könnte da also Daten in den "oberen" Klassen haben, die letztlich den Fehler ganz unten in irgend einer Weise verursachen, an die man aber von der unteren Klasse aus nicht mehr rankommt (kann es alles geben). Mit dem Hochthrowen neuer Exceptions kann man jene Information halt sammeln. Und zwar da, wo sie sind - nämlich weiter oben. Das ist spätestens dann sinnvoll, wenn man Fremdbibliotheken nutzt, dessen Sourcen man nicht hat und in etwa folgendes rauskommen könnte, weil alles sofort ausgegeben wird: Exception in thread "main" test.TestException at test.TestBla.machWas(unknown source) at de.tkdmatze.deinpackage.DeineKlasse.rufeTestBlaAuf(DeineKlasse.java:12) at de.tkdmatze.deinpackage.DeineKlasse.main(DeineKlasse.java:20) Dagegen wäre es doch schöner, zumindest zu wissen, mit welchen Parametern die Methode #TestBla.machWas() aufgerufen wurde, oder? Dann hätte man vielleicht sowas:de.tkdmatze.DeineException: Abflug mit den Parametern A="123", B="456" at de.tkdmatze.deinpackage.DeineKlasse.rufeTestBlaAuf(DeineKlasse.java:12) at de.tkdmatze.deinpackage.DeineKlasse.main(DeineKlasse.java:20) caused by test.TestException at test.TestBla.machWas(unknown source)...Das an dieser Stelle nur als kleines und sehr triviales Beispiel. Ich hab eben mal in der Wikipedia folgenden Satz gefunden: "Es ist sinnvoll, Exceptions abzufangen, um zusätzliche Informationen anzureichern und erneut auszulösen." Das ist das, was ich auch zu erklären versuche. Die Fehlerquelle zu haben ist schön und gut, aber ohne die Fehlerursache zu kennen, ist das recht nutzlos. Und oft geben einfache Exceptions in den unteren Programmschichten darauf keine Antwort. Von ihnen kriegt man nur die Quelle, mehr nicht. ...So, nun hab ich aber genug vom Diskutieren. Schönes restliches Wochenende noch! Gruß, Arvid. post scriptum: Neue Exceptions werfen, nennt man im Übrigen nicht Ableiten. Das nennt man neue Exceptions werfen. Ableiten ist das Spezialisieren einer allgemeinen Klasse durch eine Unterklasse.

@tkdmatze: Ich glaube, du übersiehst da was. Schau dir in der Java API Doc mal die verschiedenen Konstruktoren der Klasse Throwable an. Du wirst erkennen, dass 2 der Konstruktoren als Parameter ein weiteres Throwable-Objekt erwarten, nämlich den Fehlerursprung. Wenn du also eine Exception in einem Catch-Block auffängst, dann kannst du eine neue Exception werfen, die vielleicht sogar noch weitere Informationen liefert, welche die "untere" Excpeption einfach nicht hat. Zusätzlich gibst du der neuen Exception die aufgefangene gleich mit. So gehen dir nicht nur keine Informationen verloren, wie du es befürchtest, sondern du kannst sogar noch mehr Informationen über den Fehler sammeln. Ein Beispiel für die Implementierung dieser Informationssammlung: package de.tkdmatze.deinpackage import /*...*/ public class DBLeser { private Statement stmt; liesTabelleBla() throws DBLeserException { try { stmt.execute("SELECT * FROM tabelleBla WHERE id = 4711"); } catch (SQLException e) { throw new DBLeserException("Lesefehler: tabelleBla.", e); } } liesTableBlubb() throws DBLeserException { try { stmt.execute("SELECT * FROM tabelleBlubb WHERE id = 4711"); } catch (SQLException e) { throw new DBLeserException("Lesefehler: tabelleBlubb.", e); } } }Würdest du die SQLException nicht weiter hochthrowen, hättest du am Ende nix anderes als diese eine SQLException. Im Falle einer nichtsaussagenden Fehlermeldung der Exception ist dir nicht geholfen und du bist dann ziemlich aufgeschmissen bei der Fehlerbehebung. Auf die obige Weise könntest du zumindest noch weitere Infos zusammen kratzen, die dir letztlich helfen können, den Fehler zu beseitigen. Gruß Arvid.

Das nenne ich mal einen unqualifizierten Beitrag, "Kleiner"! Als begeisteter Leser des Java-Forums möchte ich dich bitten, dich in deinen Ausdrucksformen in Zukunft zu zügeln. Denn ich möchte, dass mir das Lesen auch weiterhin Spaß macht, was mir bei solchen Kommentaren ziemlich schwer fällt. Danke! @Moderator: Ich schätze die Fragen hier sind eindeutig beantwortet. Ich schlage deshalb das Schließen dieses Threads vor.

Auch wenn der ursprüngliche Thread "etwas" älter ist, möchte ich auch mal kurz was dazu sagen. Ich finde es gut, wenn du im Flashen Erfahrung hast und dein Handwerk verstehst. Also nur zu, ran an den Speck! Aber: Bei allem, was ich bisher in diesem Forum gelesen habe und auch sonst in der Berufsschule in den letzten drei Jahren Ausbildung hörte, ist es ganz gleich, ob du noch echte Folien auf den OHP haust, ob du fette Animationen über den Beamer jagst oder ob du live am Flipchart zeichnest und erklärst. Du wirst in der Bewertung deiner mündlichen Prüfung höchstwahrscheinlich keinen einzigen Vorteil gegenüber jemanden heraus schlagen können, der seine gesamte Präsentation an der Pinwand zeigt. Und Power Point ist keinesfalls 08/15 oder ausgelutscht. Wenn doch, kannst du ja auch noch auf Open Office Impress zurück greifen. ;-) Übrigens kommen die Texte nicht zwangsläufig "stockernd von der Seite eingeflogen", auch PP oder Impress bieten die Möglichkeit, alles (oder nur Teile) sanft einblenden zu lassen. Ganz nebenbei: Meine persönliche Meinung ist, dass Einblendeffekte oder Ähnliches sowieso vollkommen unsinnig sind. Sie bewirken nur wenig und kosten obendrein Zeit. Dann doch lieber einen Klick und Zack, ist die nächste Folie da, ganz ohne Schnickschnack und sonstigen Kikifaxen. Ist doch echt albern sowas... Also nochmal unterm Strich: Natürlich wirst Eindruck machen können. Und dir wird sicher auch kein Prüfer Punkte deswegen abziehen wollen. Doch Extra-Punkte wirst du sicher auch nicht gewinnen... Also mein Tipp: Wenn du dir wirklich sicher bist, dass du deine Arbeit gut machst (Flash lenkt trotz Animation nicht ab, Inhalt kommt rüber, Vortragsweise stimmt, etc.), dann mach es einfach! Ich jedenfalls bleibe bei den ausgelutschten 08/15 Mainstream-Präsis mit OOo Impress... In diesem Sinne. Jedem das Seine. Arvid.

Ist aber nicht mal ansatzweise das Gleiche.

Mein Rezept ist Suggestion. Ich glaube an die Macht der Gedanken. Ich rede mir ein, dass alles halb so wild ist und dass ich keinen Grund habe, nervös zu sein. Irgendwann glaubt man einfach selbst daran... Also ganz wichtig: Immer ganz ruhig bleiben. Sich nicht selbst verrückt machen. Aber vor allem natürlich sollte man sich auch etwas vorbereiten. Einige Male die Abschlusspräsi in einer Probe präsentieren. Das macht man am besten vor Kollegen, die einem mit Kritik konstruktiv unterstützen können. Auch vor Freunden und Familie, die mit der Thematik deines Projektes nicht vertraut sind, zu präsentieren, ist sinnvoll. Vielleicht sollte man sich auch 2-3 Tage vor der Prüfung einfach überhaupt gar nicht mehr mit selbiger beschäftigen. Einfach was komplett anderes machen, um Körper und Geist zu entspannen. Treibe Sport, geh spazieren, mach einen Ausflug in die Natur, mach 'ne Radtour, ......... Lenk dich einfach selbst von dem Gedanken ab, bald in der Prüfung zu sitzen/stehen. Wie gesagt - bei mir persönlich reicht es meist schon, wenn ich mir suggeriere, es sei alles gar nicht so schlimm (ich bin auch überzeugt, dass es wirklich nicht schlimm ist). MwF (Mit winkenden Füßen) Arvid.

Hi Tom! Den PA als Zielgruppe zu wählen, ist gewagt. Bei einigen IHKs soll man genau das eben nicht tun (z.B. bei der IHK in Hamburg). Du solltest dich diesbezüglich also unbedingt bei deiner IHK in Bielefeld erkundigen. Im Zweifelsfall wähle als Zielgruppe lieber den Kunden/Auftraggeber des Projektes als Zielgruppe. Das mit der Wirtschaftlichkeitsbetrachtung siehst du richtig. Man rechnet mit einem Stundensatz, wie er dem Kunden/Auftraggeber in Rechnung gestellt wird. Darin enthalten sind der Mitarbeiterlohn für die 70h (sicherlich weniger als 81 €/h ) sowie weitere Aufwendungen wie zum Bsp. Materialeinsatz (Hard- & Software), Miete und Strom der Geschäftsräume, eine Gewinnpauschale u.a. ... Das hat Sinn, denn man soll ja errechnen, was das Projekt dem Kunden kostet, nicht dem Dienstleister. Dem Kunden soll das Projektergebnis schließlich auch einen Nutzen bringen, im Idealfall einen quantifizierbaren (ist nicht immer möglich, den Nutzen an konkreten Zahlen festzuhalten). So kann man für den Auftraggeber die Kosten und den Nutzwert gegenüber stellen. Du könntest dann auch noch berechnen, nach wie vielen Wochen/Monaten/Jahren oder nach wie vielen verkauften Programmmodulen die Projektkosten amortisiert sind, also ab wann die Kosten vom Nutzen "geschluckt" werden. Ein Ausblick ist meiner Meinung nach immer sinnvoll. Das zeigt, dass du dein Projekt nicht nur mit Scheuklappen vor den Augen bearbeitet hast, sondern auch in der Lage warst, während der Durchführung an zukünftige Erweiterungen/Anpassungen zu denken. Des Weiteren zeigt es, dass du Konzepte unter Beachtung von mittel- oder langfristigen Zielen erstellen kannst. Ich werde das jedenfalls auch so machen. (Werde meine Abschlusspräsi & Fachgespräch am 26.6.06 haben.) MsF (Mit stinkenden Füßen) Arvid.

...Aso, den kannte ich auf jeden Fall noch nicht... Wieder was gelernt! Danke dafür! Sonnige Grüße aus Hamburg! Arvid.