VaNaTiC

Jein. Ich würde mit einem festen Puffer arbeiten. Nicht das mal auf dem portablen Gerät eine Datei >50MB ist Also im try-Body: byte[] buffer = new byte[1024]; int count; while ((count = cStream.Read(buffer, 0, buffer.Length)) > 0) fout.Write(buffer, 0, count);

Process proc = ProcessBuilder.start(...); try { int iExit = proc.exitValue(); } catch (IllegalThreadStateException e) { // noch nicht beendet }

Ja, das mit dem delegates ist ziemlich heftig, aber einmal verstanden ist das sehr sicher. Nicht wie in anderen Sprachen, da muss man sich 100%ig selbst drum kümmern. Hab ein Beispiel für Dich aus einem Test von mir: public delegate void VoidColorStringDelegate(Color color, string text); public void Log(Color color, string text) { if ( text == null || text.Length == 0 ) return; if ( rtbLogs.InvokeRequired ) { rtbLogs.Invoke(new VoidColorStringDelegate(Log), new Object[] {color, text}); return; } int iPos = rtbLogs.Text.Length; rtbLogs.AppendText(text); rtbLogs.Select(iPos, iPos+text.Length); rtbLogs.SelectionColor = color; rtbLogs.Select(rtbLogs.Text.Length, 0); rtbLogs.ScrollToCaret(); } public void LogLine(Color color, string text) { Log(color, text+"\r\n"); }

Agree. Dafür nimmst Du nicht ReadByte(), sondern Read(Byte[] puffer, int laenge).

Hmm, ich hab noch nicht verstanden, welcher Code nach dem ENDIF nicht ausgeführt wird. Parst Yacc nach dem ENDIF nicht mehr oder erzeugt Yacc Code, der nach dem ENDIF nichts ausführt?

Hmm, also war meine Vermutung richtig, dass das JFrame keine Notwendigkeit sieht ein paint() zu machen. Du könntest das erzwingen indem Du Deine JTextFields in MyJTextField ableitest und dort die paint() und/oder updateUI() überschreibst: public class MyJTextField extends JTextField { public void paint(...) { super.paint(...); getParent().paint(...); } public void updateUI() { super.updateUI(); getParent().updateUI(); } } Damit sollte das Neuzeichnen beim Zeichnen eines Deiner Textfelder erzwungen werden. Aber Vorsicht: Verbessere das bitte selbst, so dass das JFrame nicht bei jedem einzelnen JTextField neu gezeichnet wird.

Es gibt in Delphi ein VCL-Control, was Dir schon während der Eingabe nur bestimmte Masken zulässt: TMaskEdit. Ansonsten nimmst Du TEdit.Text und validierst Dir die Eingaben selber. Aber bitte für den Anfang nicht gleich im OnChange oder OnKeyDown, ... sondern erst im OnClick eines Deiner Buttons. Validieren lässt sich das mittels: try einInt := StrToInt(EinEdit.Text); except on E: Exception do begin ShowMessage('Eingabefehler bei EinInteger: '+E.Message); end;//on E end;//except

Prinzipiell ist das wie Phil schon sagte, ziemlich heftiger Stoff den Du da einnehmen willst Fakt ist mit Java schaffst Du Dir hier zusätzliche Stolpersteine, die Du vermeiden solltest. Das wird schon so kompliziert genug. Vorgehensweise am Beispiel eines Browser, der das noch nicht unterstützt und keine Plugin-Technologie in sich trägt (zB IE), denn das wäre dann natürlich der richtige Weg: - Überwachen der WinAPI Calls zum Öffnen neuer Fenster mittels Hooks - dazu muss allerdings erstmal der Hook im zu überwachenden Programm installiert werden - dann musst Du noch entscheiden ob das eventuell nicht ein gewünschtes Popup war, also vorher drauf geklickt wurde -> wieder ein Hook auf Klicken und Co - und nu muss das Erstellen des Handles noch unterdrückt werden ohne den Browser eine Fehlermeldung abzuringen Aufgrund der Eingriffe in den anderen Prozess, was zB auch Malware macht, wird das Dein System glauben einen bösen Zugriff zu erkennen und das unterbinden.

Leider kann ich Dir das so pauschal nicht beantworten. Richtig ist auf alle Fälle, dass der Code in das paint() muss. Meiner Meinung nach sollte paint() jetzt bereits schon alles für Dich erledigen, aber wie mir scheint ist da noch irgendwo - vielleicht sogar im JDK selber - ein Bug. Mach mal in das paint() eine System.out.println rein und versuche herauszufinden bei welchen übergeordneten Window-Events er KEIN paint() ausführt. Beispiele: - Du veränderst die Größe Deines Frames mit der Maus -> println kommt -> OK - Du minimierst die Anwendung -> println kommt nicht -> OK - Du normalisierst die Anwendung wieder -> println kommt ja/nein - Du aktivierst ein anderes Fenster was NICHT überlagernd gezeichnet wird, so dass Du beide Fenster zu 100% sehen kannst, nur dass Dein Frame deaktiviert wird -> jetzt klickst wieder in den JFrame (am besten in die Titelzeile) -> jetzt kommt sicherlich kein paint Irgendwo fehlt der Hinweis, dass der interne Puffer des JFrames eben gerade kein paint() nötig hat, sondern nur die Sub-Controls ein update bekommen. Fakt ist so wie Du die Anzeige der Striche realisierst hast, musst Du sobald die Sub-Controls geupdated werden auch den JFrame updaten. Ich empfehle dazu der Einfachheit nicht paint() vom Frame zu nutzen, sondern stattdessen ein eigenes oder vorhandenes Control zu benutzen, und das ganze Neuzeichnen/Updaten die normale Java-Umgebung machen zu lassen. Leider weiss ich nicht auf die schnelle, welches Control Dir direkt weiterhelfen könnte. Wenn alle Stricke reissen nimm ein JLabel("|") Das ist einer der schmutzigen Tricks, denen man sich bedienen muss, um per Workaround das Fenster-Triggering vom JDK zum Leben zu erwecken. Das mit dem JLabel ist allerings wirklich nur die Notlösung, besser ist herauszufinden, bei welchen übergeordneten Ereignissen das JFrame kein paint() vom update() bekommt und dieses Event dann zu überschreiben und mit dem update() das paint() selbst anzustoßen.

Ich kenne zwei ScriptEngines, die beide genauso wie Du paule vorgehene. Schau Dir zum Beispiel mal PascalScript (jetzt) von RemObjects an. Aber prinzipiell hab ich noch nicht ganz verstanden, was Du mit endlos IF-ELSEIF-... meinst?! Willst Du dynamisches IF-ELSEIF in ASM abbilden? Oder in der Hochsprache? Sowas wie ein Case-Of?

nachm runterscrollen hab ichs mir schon gedacht, dass Du die Striche in der paint() zeichnest. Problem ist, wenn Windows Fenster überlagert/neu zeichnet, etc. muss man an den richtigen Stellen ein update() machen, damit auch die Java-paint() aufgerufen wird.

Hier kannst Du nach OIDs gucken: OID repository - {iso(1) identified-organization(3) dod(6) internet(1) private(4) enterprise(1)} siehe auch die Baumansicht zum Durchschauen.

System.Threading.Timer: ... // waits first time waitMSec and ticks every tickMSec after this yourTimer = new Timer(new TimerCallback(yourDelegate), yourParam, waitMSec, tickMSec); ... public (static) void yourDelegate(Object param) // param <= yourParam { if ( anyStateYouWant ) m_timer.Dispose(); // to destroy do with your param in any tick not }

Schleifen in T-SQL: WHILE (T-SQL) T-SQL Programming Part 2 - Building a T-SQL Loop Database Journal

Soweit ich weiss gibt es keinen automatischen Datumstest bei der Eingabe. Problem ist immer, dass erst alle drei Bestandteile Tag, Monat, Jahr eingegeben sein müssen, bevor eine Validierung Sinn macht. Und selbst dann muss man das mit Schaltjahrberechnung ermitteln. Ich hab allerdings schon oft gesehen, dass bewusst umgewandelt wird um mittels einer abgefangenen Exception zu testen ob die Eingabe ok ist, aber naja die feine Englische ist das nicht!

flashpixx hat Recht inbezug auf serialisieren von Objekten. Serialisieren (hier speziell ObjectOutputStream) hat einen Nachteil: es ist eine andere Darstellung eines flüchtigen Objektes. D.h. die binäre Darstellung des Objektes im Speicher kann sich durchaus ändern. Deshalb benutzt man für die persistente Darstellung von Objekten auch irgendein objectrelationales Mapping. Das kann XML sein, das kann aber auch auch was eigenes sein. Wichtig ist nur, Du solltest aufpassen, dass Du Dir nicht wieder ein neues Problem ins Haus holst. Das ist "nur" ein Chat über MultiCast. OR-Mapping ist da meiner Meinung nach mit Kanonen auf Spatzen. Gleichzeitig hat XML den Nachteil, dass der erzeugte Text relativ zum Objekt gesehen enorm groß ist. Das Mapping dauert zusätzlich natürlich auch Zeit! Und Du darfst nicht vergessen, MultiCast und UDP übertragen Daten pro Paket zusammengehörend. Fakt ist, wenn Du die Dinger als Text besser sogar noch binär überträgst, dann kostet Dich das etwas mehr Aufwand beim Entwickeln, aber ist robuster und performanter! just my 2 cents

Was bietet den der MultiCast-Socket zum Senden, wenn es keinen OutputStream gibt? CORBA, RMI und Derivate wie WebServices sind für Deinen Anwendungsfall nicht die beste Wahl, denn die arbeiten alle mit TCP und das ist nicht MultiCast. Dein Weg in Richtung serialisieren der Objekte übers Netzwerk ist brauchbar, aber Du musst Dich trotzdem darum kümmern, dass auf HIALLE ein HIDU und das dazugehörige Handling passiert. Und da ist es egal, ob HIDU per Text, Befehlsbyte oder Objekt erkannt wird.

Hmm, dafür gibts doch keine Codierung im eigentlichen Sinne?! Das sind Dinge, die bei der IANA registriert wurden. OID in MIB: Simple Network Management Protocol ? Wikipedia Infos über eine bestimmte OID: OID Repository - Home Private Numbers: http://www.iana.org/assignments/enterprise-numbers

Sowas nennt man dann anwendungsspezifisches Protokoll und gehört zur OSI7. UDP ist zB nur für den Transport zuständig. Du musst Dir halt jetzt den Aufbau und möglichen Inhalt Deiner Chat-Pakete überlegen. So nach dem Motto (Trennzeichen | ): Broadcast/AnAlle -> HIALLE|IchBinDerNeue|MeineVersion|Schnulli EinzelnVonAllen <- HIDU|IchBinEiner|MeineVersion|Schnulli Damit kann man zum Beispiel schonmal beim Anwendungsstart und eventuell zyklisch alle paar Minuten Updates der UserListe fahren. Wenn nun einer einen Text absendet, dann schreibts einfach: Broadcast/AnAlle -> TEXT|Das ist ein simpler - auch mehrzeiliger - Text. Einzigstes Problem ist, dass Du generell bei UDP (auch bei MultiCast) die Paketlänge begrenzen musst. Lange Texte kann man zum Beispiel einfach trennen. Man kann sogar ignorieren, dass eventuell das zweite Paket das erste überholt. Ist nicht so schlimm Ich würde die Paketlänge auf etwa 1000+Header begrenzen und dann splitten. Hinweis: Wunder Dich nicht, dass Du Deine eigenen abgesendeten Pakete wie jeder andere auch empfängst. Wenn Du das nicht willst musst Du das entweder beim Senden verhindern (find ich schwieriger) oder beim Empfangen Deinen eigenen Absende-Port ausfiltern (einfacher).

Und speziell bei grep: Miscellaneous: -s, --no-messages suppress error messages [COLOR="Red"] -v, --invert-match select non-matching lines[/COLOR] -V, --version print version information and exit --help display this help and exit --mmap use memory-mapped input if possible

Hmm, passt alles. Keine Ahnung, was bei Dir falsch läuft. Hab mir spasseshalber mal nen BeispielFrame gemacht: final DefaultTableModel data = new DefaultTableModel(100,1); final JTable table = new JTable(data); table.setDefaultRenderer(Object.class, new Cell_Renderer()); JScrollPane scroller = new JScrollPane(table); table.setFillsViewportHeight(true); JPanel buttons = new JPanel(); JButton test = new JButton("Test"); test.addActionListener(new ActionListener() { public void actionPerformed(ActionEvent ae) { StringBuffer sb = new StringBuffer(); for (int i = 0; i < data.getRowCount(); i++) { sb.append('0'+i); data.setValueAt(sb.toString(), i,0); } table.updateUI(); } }); buttons.setLayout(new FlowLayout()); buttons.add(test); getContentPane().setLayout(new BorderLayout()); getContentPane().add(buttons, BorderLayout.NORTH); getContentPane().add(scroller, BorderLayout.CENTER); Und mit Deinem Cell_Renderer funktioniert das prima?!

Ich brauch mehr Quellcode. Nicht das es außerhalb einer IF ist!

wenns nicht direkt um C, sondern um C++ gehen "darf", dann ist die IRC-Channelseite vom #c++.de ausm QuakeNet ziemlich gut: #c++.de im QuakeNet -- Hilfechannel zu C++

Ja, stimmt, denn das sagst Du auch explizit mit JTable.setRowHeight(int). Ja, genau Du nutzt einfach die falsche setRowHeight(...) Natürlich. Und das hab ich bereits gepostet mit dem Link aus dem JAVA-Doc-API. JTable.setRowHeight(int pixel) <--- global für alle Zeilen in Tabelle != JTable.setRowHeight(int row, int pixel) <--- nur für die eine Zeile !!!

Hmm, schäm Dich! Mir scheint Du kennst Deinen Quellcode nicht besonders Guckst Du hier: public Component getTableCellRendererComponent(JTable tabelle, Object value, boolean isSelected, boolean hasFocus, int row, int column)