ich habe das jetzt schon mehrfach probiert. Immer wieder anders gelöst. Aber jetzt brauche ich den vermaledeiten Dialog.
Also ich versuche einen stinknormalen DirectoryDialog zu öffnen.
Jedes mal hängt sich die komplette GUI auf und ich muss das Programm abschiessen.
DirectoryDialog dd = new DirectoryDialog(getShell());
dd.setText("Please choose your folder");
String path = dd.open();```
Ein FileDialog geht ohne Probleme auf, lässt mich aber leider keinen Ordner auswählen.
Wenn ich per Debugger das Programm pausieren sehe ich, dass er hier hängt:
OS.SHBrowseForFolder (BROWSEINFO lpbi)
also irgendwo tief unten in der Systemfunktion.
Über google finde ich nix, aber auch gar nichts.
Sitzen tue ich hier bei einer grossen Firma. Habe viele viele Netzlaufwerke verbunden (die ich auch brauche und spätere Benutzer des Tools ebenso)
Da der FileDialog aber keine Probleme hat denke ich, kann es daran nicht liegen (aber wer weiss).
Hatte jemand von euch schonmal solche Probleme? Ich weiss echt nicht mehr weiter.
Gruß Vayu
Ich bin jetzt auf den JFileChooser umgestiegen und reiche dem ein durch SWT_AWT erzeugten Frame rein.
Ich finds merkwürdig, dass sonst noch niemand auf dieses Problem gestossen ist.
Eventuell keine Berechtigung auf den standartmäßigen Pfad den der DirectoryDialog anzeigt? Wüsste nicht auf die schnelle wie der Dialog da reagiert.
Vielleicht enthält der übergebene String zeichen mit dem der DirectoryDialog nicht klar kommt, leerzeichen sind in Windows kein Problem bei Pfadangaben. Java hat dort aber schwer Probleme mit.
habe deine etwas spätere Antwort gar nicht gesehen.
Ich entwickle in einem 64Bit Eclipse Kepler SR1 auf einer 32Bit Eclipse Kepler SR1 Target Plattform unter Windows 7.
Hab auch meine Launchconfig mehrfach gecheckt.
habe nur swt + swt win 32bit ausgewählt.
Damals war ich noch auf Kepler. Mittlerweile sind wir auch SR1 umgestiegen. Habs dann heute nochmal probiert, aber es hat sich nicht verändert.
Bin da echt ratlos.
osgi mit swt
ich wollte nur alles angeben was ich so gemacht hab, daher auch mal eclipse angegeben. Und mit SR1 hätte es ja sein können, dass die am swt auch noch rumgeschraubt haben.
und ja ich arbeite auf nem laptop. Allerdings hab ich jetzt letztens nen ganz neuen fujitsu bekommen und auch auf dem läuft es nicht.
[QUOTE=Vayu]osgi mit swt
ich wollte nur alles angeben was ich so gemacht hab, daher auch mal eclipse angegeben. Und mit SR1 hätte es ja sein können, dass die am swt auch noch rumgeschraubt haben.
[/QUOTE]
Es gibt irgendwo noch eine Klasse, mit der man den Bug testen kann. Das Problem ist das Windows nur eine bestimmte Anzahl an nested Composite zeichnen kann ca. 48-50…
Und manche Graifk Treiber glaub nur 20 dann hast ein Problem
weil ich das ganze eclipse drumrum nicht brauchte für die Anwendung
aber ich benutze schon org.eclipse.osgi. Nur halt die ganze Anwendung drumrum hab ich weg gelassen.
Ich habe ne eigene kleine GUI gebastelt, habe plugin-support, update-support und bin froh … bis auf diesen doofen dialog.
Dieser Fehler kann es aber eigentlich auch nicht sein, da an selber Stelle im Code der FileDialog einwandfrei funktioniert.
[QUOTE=Vayu]weil ich das ganze eclipse drumrum nicht brauchte für die Anwendung
aber ich benutze schon org.eclipse.osgi. Nur halt die ganze Anwendung drumrum hab ich weg gelassen.
Ich habe ne eigene kleine GUI gebastelt, habe plugin-support, update-support und bin froh … bis auf diesen doofen dialog.
[/QUOTE]
Ja wenn du plugins + feature usw. verwendest kann es schon Vorteile zwecks plattformunabhäniges bauen haben.
Je was? Wie an gleicher Stelle funktioniert? Auf deinem Laptop geht er nicht, auf anderen Rechner kann es durchaus funktionieren, darum eben Grafiktreiber…
*** Edit ***
Mit der Klasse kannst du es auf verschiedenen Rechner testen… Wenn dein Rechner keine 40 counts schafft kommen keine Sysout Ausgaben, dann ist das schon mal schlecht
import org.eclipse.swt.SWT;
import org.eclipse.swt.custom.SashForm;
import org.eclipse.swt.layout.FillLayout;
import org.eclipse.swt.widgets.Button;
import org.eclipse.swt.widgets.Canvas;
import org.eclipse.swt.widgets.Composite;
import org.eclipse.swt.widgets.Display;
import org.eclipse.swt.widgets.Event;
import org.eclipse.swt.widgets.Listener;
import org.eclipse.swt.widgets.Shell;
import org.eclipse.swt.widgets.ToolBar;
import org.eclipse.swt.widgets.ToolItem;
public class Bug
{
/**
* @param args
*/
public static void main(String[] args)
{
Display display = new Display();
Shell shell = new Shell(display);
shell.setLayout(new FillLayout());
SashForm form = new SashForm(shell, SWT.HORIZONTAL);
form.setLayout(new FillLayout());
Composite child1 = new Composite(form, SWT.NONE);
child1.setLayout(new FillLayout());
Composite child2 = new Composite(form, SWT.NONE);
FillLayout fl;
child2.setLayout(fl = new FillLayout());
fl.type = SWT.VERTICAL;
new Button(child2, SWT.PUSH).setText("Button in pane2");
final ToolBar toolbar = new ToolBar(child2, SWT.None);
form.setWeights(new int[] { 30, 40 });
Composite parent = child1;
int count = 40;
for (int i = 0; i < count; i++)
{
Canvas c = new Canvas(parent, SWT.NONE);
c.setLayout(new FillLayout());
parent = c;
}
parent.setBackground(Display.getCurrent().getSystemColor(SWT.COLOR_BLUE));
child1.addListener(SWT.Activate, new Listener()
{
@Override
public void handleEvent(Event event)
{
System.err.println("creating toolitem");
try
{
new ToolItem(toolbar, SWT.None);
}
catch (Throwable t)
{
t.printStackTrace();
}
}
});
shell.setSize(200, 200);
shell.open();
while (!shell.isDisposed())
{
if (!display.readAndDispatch())
{
display.sleep();
}
}
display.dispose();
}
}
ich meinte der FileDialog klappt an selber Stelle, der DirectoryDialog nicht.
Wenn ich die Klasse ausführe geht ein Fenster auf, wenn ich dann in den blauen Bereich klicke krieg ich die Ausgabe auf der Console.
Erhöhe ich den Count auf 50 bekomme ich die „No more handles“
Das doofe ist halt wirklich, man findet nix über den Fehler im Netz … Hab ja auch nicht nur in der Application versucht das Ding zu öffnen … Bug Klasse erstellt und von dort probiert den Dialog zu öffnen führt auch nicht zum Erfolg.
Naja dann kann es ja fast nur noch mit dem Firmeninternen Netz zu tun haben, was vielleicht hier irgendeine Leseoperation blockiert … tät mich ned wundern -.-
Aber auf anderen Rechner funktioniert es problemlos? Nur bei deinem nicht?
Schon mal probiert einen einfachen RCP zu machen (gibt ja schon Vorlagen die dir IDE angibt) und das ganze mal in einer View auszuführen… Vielleicht liegt es doch an der swt.jar
Und zusätzlich bekommst du bei einer RCP immer ein log dazu vielleicht steht da was brauchbares drin
nope, funktioniert bei meinem kollegen auch nicht.
Hab es gestern nochmal in der Bug-Klasse probiert. Da ging der Dialog dann auf einmal problemlos auf … In der Applikation keine Chance.
Nochmal zum Verständnis wie ich es mache.
Ich habe ein ApplicationWindow mit einem MenuManager. Dort hänge ich eine Action rein. In deren run()-Methode versuche ich den Dialog zu öffnen.
Ich habs mit der Parent-Shell probiert. Hab ne Neue Shell mit dem Default-Display und dem Current-Display (was ja normalerweise auch dasselbe ist, aber egal … ) erstellt. Ich habs in ein sync und ein async-exec gesteckt.
Sonst läuft in der Applikation nix zu dem Zeitpunkt wo ich auf diesen blöden Menüeintrag klicke …
Also in meinem Eclipse geht zB der DirectoryDialog im “Switch Workspace”-Fenster ohne probs auf …
KSKB. Muss mal gucken. Müsste ich eigentich hinkriegen. Kleinen Moment ^^
*** Edit ***
Ok … jetzt schmeiss ichs gleich an die Wand.
Application Klasse und ApplicationWindow in ein frisches Plug-in rüberkopiert. Alles rausgeschmissen, bis auf die eine Action und einen Tab in der Content-Area … nu gehts -.-
Was kann denn eine Action blockieren? Wenn ich gerade nichts in der GUI mache. Wenn sonst kein Prozess läuft …
*** Edit ***
OK @SirWayne kannst aufhören zu suchen … ich hab den Schuldigen.
Ich benutze die Enterprise Architect API in meiner Application und erzeuge schon beim Start ein Repository.
Scheinbar blockiert der EA eben den Aufruf … OS.SHBrowseForFolder …
Tja … da meine Application genau dem Zweck dient, eben mit dem Enterprise Architect zu arbeiten, bleibt mir nichts anderes übrig, als den Swing-Dialog für diese Aktion zu nehmen. Der funktioniert immerhin.
OMG … was ich da jetzt für Zeit schon reingesteckt hab …
japp.
gibt ne jar und die nutzt die dll.
und wie der das blocken kann … ich hab keine ahnung. aber es reicht tatsächlich eine Klasse der API zu erzeugen.
schade. Hatte damals echt auf dich gehofft 