Zitat von Apfelsaft

Warum so aggressiv? Das es sich um ein Problem handelt hat außer dir niemand geschrieben.

War aber nicht bös gmeint, nur nerdy

Zitat von Apfelsaft

Weiß jemand warum so viele Leute JAVA statt Java schreiben?

Weil du so Hardcore bist, dass dein Gehirn ein String.toUpperCase() macht, bevor es einen Text verarbeitet!

Wär mir noch nicht aufgefallen, dass derart viele Java nur in Großbuchstaben schreiben würden .. ich glaube das Problem ist so allgegenwärtig wie Minarette in der Schweiz!

Zitat von Kampi

doch doch, das stimmt schon. laut standard ist die auswertungsreihenfolge nur fuer '&&', '||', ',' und '?:' garantiert.

Was jetzt, für Java oder C? Java ist doch garantiert von links nach rechts.

Zitat von bimmelresonanz

kennt da wer was?

Die "head first" Reihe von Büchern scheint Inhalte recht anschaulich zu erklären - hatte aber noch nie ein Buch der Serie in der Hand. Es müsste hier in der Programmierecke einige Threads geben, in denen über Java-Bücher diskutiert wird - such mal etwas, ich glaub, da wirst du schon fündig.

Also soviel ich weiß wird's jeweils unterrichtet in "Prolog", "Einführung in das Programmieren", "Algorithmen, Datenstrukturen und Programmieren". Da die Qualität des Unterrichts sich aber in Grenzen hält, läuft es eh darauf raus, dass du mit Skriptum, Büchern (z. B. "Das Java Handbuch" und "Java ist auch eine Insel" sind online gratis erhältlich), und diversen Online-Tutorials lernst.

Bei Mietstreitigkeiten selbst geht man offenbar zur sogenannten "Schlichtungsstelle", weiß aber nicht, zu welchem Magistrat sie gehört. Die Mietervereinigung nimmt dir den ganzen Papierkram ab, berät dich, etc. .. theoretisch alles Sachen, die man alleine machen kann, aber die 50 Euro im Jahr ist die Mitgliedschaft bei der Mietervereinigung wert. Kannst womöglich noch eine Mietreduktion und Rückzahlung rausschlagen (die Differenz muss für bis zu 3 Jahre vor der Entscheidung zur Mietsenkung rückgezahlt werden). Aja und die Mietervereinigung hat auf der Website einen Rechner .. kannst guckn, ob deine Miete dem üblichen entspricht, oder nicht.

Also soviel ich weiß trägt der Laserdrucker Pulver aufs Papier auf .. da "rinnt" nix .. und transportiert hätt ich meinen auch schon oft genug, raus kommen wär da noch nix .. also ich würd ma da keinen Kopf machen. Wär der Drucker ein derart zartes Pflanzerl, dann würds ja schon drauf stehn .. wobei .. wie wärs mit Bedienungsanleitung lesen? ^^^^^^^;

Habe da etwas recherchiert, und eine Lösung scheint die Verwendung eines BoundesRangeModels zu sein. Folgender Code aktualisiert den JSlider, sobald er den Fokus verliert:

import java.awt.GridLayout;


import javax.swing.BoundedRangeModel;
import javax.swing.DefaultBoundedRangeModel;
import javax.swing.JFrame;
import javax.swing.JSlider;


public class SliderFrame extends JFrame {
	private static final long serialVersionUID = 7123905268649335702L;


	private JSlider valueASlider;
	private JSlider valueBSlider;
	private JSlider valueCSlider;


	public SliderFrame() {
		setTitle("Slider Demo");
		setLayout(new GridLayout(3, 1));


		add(valueASlider = new JSlider(new SliderModel()));
		add(valueBSlider = new JSlider(new SliderModel()));
		add(valueCSlider = new JSlider(new SliderModel()));


		pack();


		setDefaultCloseOperation(EXIT_ON_CLOSE);
		setLocationByPlatform(true);
	}


	private class SliderModel extends DefaultBoundedRangeModel implements
			BoundedRangeModel {
		private static final long serialVersionUID = -8168548302661988023L;


		@Override
		public synchronized void setValue(int n) {
			int valueTotal = valueASlider.getValue() + valueBSlider.getValue()
					+ valueCSlider.getValue() - getValue() + n;
			if (valueTotal <= 100) {
				super.setValue(n);
			}
		}


		@Override
		public int getMinimum() {
			return 0;
		}


		@Override
		public int getMaximum() {
			return 100;
		}
	}


	public static void main(String[] args) {
		java.awt.EventQueue.invokeLater(new Runnable() {
			public void run() {
				new SliderFrame().setVisible(true);
			}
		});
	}
}

Habe jetzt aber nicht probiert, ob es ursprünglich mit dem ChangeListener den selben Effekt gehabt hätte. Vielleicht wäre eine Lösung, die Komponente dazu zu bringen, dass sie sich neu zeichnet mit dem neuen Wert, wie sie es macht, wenn sie den Fokus verliert. Klingt aber nicht zu elegant .. aber das BoundedRangeModel scheint die richtige Richtung vorzugeben.

Kann da jetzt nicht weiß Gott wieviel Zeit investieren .. aber viel Erfolg noch .. und wenn du eine Lösugn findest, dann poste sie bitte.

Poste vielleicht mal den relevanten Code, damit man das mal ansehen kann.

Nicht konkret .. aber schon probiert danach ein repaint auszulösen?

Zitat von Ringding

Das Verhalten der Vererbungen und Rechte ist in Java tatsächlich recht kompliziert und unüberschaubar.

Die zahlreichen Belege dafür wären mir unbekannt. Hättest du Beispiele? Das von LordNecro beschriebene Problem ist noch das komplexeste, das ich bisher gesehen habe.

Zitat

In C++ kann man ja locker mal in einem Headerfile etwas von private auf public umstellen und damit eine Object-Datei compilieren, die auf das private Feld zugreift;

An den Regeln selbst scheint das ja nichts zu ändern - und ob das ein Vorteil ist, sei dahingestellt: Wenn Sichtbarkeiten sich derart leicht umgehen lassen, dann ist es nicht weit her mit der Sicherheit.

Zitat von LordNecro

A liegt in package1, B und C liegen im package2. Dieser Aussage oben muss ich leider wiedersprechen.

Aja, absolut .. schräg! Und die Beschreibung machts auch nicht gerade leicht verständlich ..

Zitat von LordNecro

Du musst in der Parameterliste von doSomething den Typen von var auf B ändern, dann solltest den Fehler haben den ich nicht verstehe.

Habe ich jetzt gemacht, ändert nichts.

Zitat von Paulchen

... dann liegt alles in demselben Package. In LordNecros Beispiel ist aber A in pack1 und B und C sind in pack2.

Tut es. Die packages hat er ja als "Typo" bezeichnet, ich habe ihn so verstanden, dass doch alle Klassen im gleichen Paket liegen.

Das Problem taucht auch nur auf, wenn man die Klassen in verschiedenen packages platziert. Das liegt daran, dass "protected" bedeutet, dass das Feld nur zu Subklassen im eigenen package hin sichtbar ist, nicht allgemein zu jeder erbenden Klasse hin.

"protected" Felder sind zur Subklasse hin sichtbar, jedoch nur, wenn sie im gleichen package liegt. Wenn man packages als Module betrachtet, das nur über (public-)Schnittstellen kommunizieren sollte, dann ist das Verhalten durchaus sinnvoll.

Wenn ich in einer Datei folgenden Code schreibe, funktioniert alles wie erwartet:

class A {
	protected int i;
}


abstract class B extends A {


}


class C extends B {
	public void doSomething(C var) {
		if (i == var.i) {


		}
	}
}

Kann deinen Fehler also nicht ganz nachvollziehen. Nachdem aber jetzt dein Beispiel schon einen Fehler zu haben scheint, könnte es ja vielleicht auch in anderen Aspekten vom Original abweichen - vielleicht in etwas, das du als unwichtig übersiehst. Zeig mal den Original-Code her, dann lässt sich das Problem vielleicht erkennen.

Eine Komponente von Grund auf zu entwickeln wäre ein aufwändiges Projekt, bei dem du sehr viel falsch machen könntest. Unter anderem müsstest du verschiedene Look & Feels unterstützten. Ich hab's zwar noch nicht gemacht, aber wenn man sich näher ansieht, was eine Komponente alles können muss, dann wäre die Entwicklung einer sich korrekt verhaltenden eigenen Komponente für deinen Anspruch völlig übertrieben - vor allem, wenn du eh nur ein JTextField leicht modifizieren möchtest, was sich mit dem Überschreiben der Methoden bereits wunderbar erledigen lässt.

Zitat von Nicholas1991

Oh der funktioniert ganz ausgezeichnet kann ich dir sagen ^^.

Aja, falsch gschaut xD

Ich bezweifle, dass das so funktionieren wird. Der 2. Konstruktor weist sich seine eigenen Objektvariablen zu.

Zitat von JohnFoo

Konnte keine Probleme durch die Vererbung erkennen. Du wiederholst dich halt nur gern im Code, das könntest du etwas reduzieren durch gegenseitigen Aufruf von Methoden/Konstruktoren oder Auslagerung von Code in eigene Methoden. Finde also höchstens stilistische Mängel, aber Code sieht ok aus.

Schadet sicher nicht, wenn du bei der Namenswahl durchgehend englische Namen verwendest (hier z. B. "placeholder"), das fügt sich besser in den bestehenden Java-Code ein. Auch abgesehen davon gibt's nur Kleinigkeiten die man evtl. ändern könnte:

• Die Klasse ist serialisierbar und sollte eine serialVersionUID deklarieren.
• Ein expliziter Aufruf des parameterlosen Superkonstruktors super() ist nicht nötig, da er ohnehin eingefügt wird, wenn nicht vorhanden.
• Vermutlich kann der parameterlose Konstruktor den Konstruktor mit Parametern mit this() aufrufen und wiederholt so Code nicht.
• Zur Überprüfung, ob ein String leer ist, gibt es seit einiger Zeit getText().isEmpty(). Damit kannst du Überprüfungen wie text.equals("") oder text.length() == 0 ersetzen.
• Code wie
  
  
  Code

  if(textEingegeben) {
      return super.getText();
  } else {
      return "";
  }

  
  lässt sich auch knapper als

  Code

  return textEingegeben ? super.getText() : "";

  
  formulieren.
  Auch "textEingegeben==false" kann man auf "!textEingegeben" umformulieren. Die explizite Verwendung von true und false

• Ist es nicht etwas übertrieben, bei Verlust/Erlangung des Fokus jedes Mal den Listener zu entfernen oder hinzuzufügen?
• Evtl. kannst du das setzen und zurücksetzen von Text und Farbe in eine Methode auslagern, du scheinst den Vorgang oft zu wiederholen. Was ist, wenn du auch die Hintergrundfarbe ersetzen möchtest? In diesem Fall müsstest du den Code an mehreren Stellen einfügen. Versuche eine Lösung zu finden, bei der du das nur an einer Stelle machen müsstest.

Insgesamt aber nette Idee schön umgesetzt.

Zitat von Nicholas1991

Hat denn hier keiner eine Meinung ;). Kann ja nicht sein, dass das der Weisheit letzter Schluss ist...

Konnte keine Probleme durch die Vererbung erkennen. Du wiederholst dich halt nur gern im Code, das könntest du etwas reduzieren durch gegenseitigen Aufruf von Methoden/Konstruktoren oder Auslagerung von Code in eigene Methoden. Finde also höchstens stilistische Mängel, aber Code sieht ok aus.

Zitat von Swoncen

Und wegen den Punkten bin ich mir nicht so sicher.. ich hab ein Tokina Makro mit weißem Punkt, passt aber auch auf Vollformat hab ich gehört. Gilt vielleicht nur für Canon Objektive?

Die Punkte sind auch kein Standard. Der Mount entscheidet. Auf Canon Vollformatkameras kommt EF, auf Modelle mit kleinerem Sensor EF und EF-S. Des woas.