2017-02-10 1 views
0

Y at-il une possibilité d'afficher un indicateur de progression (tournant, non coincé) alors qu'il ya un gros soulèvement fait dans le fil ui javafx? J'ai besoin de charger une tableView assez grande dans un TitledPane (ce qui prend plusieurs secondes). La commande qui fait tout le décalage est TitledPane.setContent (myTableView). Donc, je veux au moins montrer une animation de chargement ou un indicateur pendant ce temps.Show ProgressIndicator lors d'un travail intensif dans le thread GUI doit être fait

Alors im en ce moment à faire ce qui suit, pour donner le fil ui assez d'espace pour respirer pour montrer mon animation de chargement avant de faire l'appel coûteux:

showMyLoadingAnimation(); 
PauseTransition pause = new PauseTransition(Duration.seconds(1)); 
pause.setOnFinished(event -> { 
    setContent(myTableView); 
}); 
pause.play(); 
dismissMyLoadingAnimation(); 

cela fonctionne obtenir l'indicateur de progression montré, mais une fois que la Le thread ui commence à travailler sur setContent, il se bloque. Ive vu certaines personnes utilisant swing pour afficher une escale ou un dialogue avec l'animation juste pour l'avoir fonctionné dans un fil différent et ne pas rester bloqué, mais ne pouvait pas trouver une solution convaincante pour le moment.

EDIT: Ok, j'ai trouvé cette racine du problème. donc ive got tables prefHeightProperty lié à la taille de la liste son affichage comme indiqué ici: JavaFX - Adapt TableView height to number of rows fait il ya des semaines, travaillé, oublié à ce sujet.

qui coûte BEAUCOUP de temps. Donc, bien que le timing de l'appel lors de la définition de la liaison ne montre pas que cela prend beaucoup de temps, le thread ui semble avoir un gros problème avec quand les tableaux deviennent gros.

grâce à James, sa réponse sera la bonne pour la plupart des gens qui se heurtent à ce genre de problème.

quelqu'un peut-il s'il vous plaît commenter cette question là-bas: JavaFX - Adapt TableView height to number of rows (puisque c'est la première question que je n'ai pas encore assez représentant pour commenter.)

+0

'titledPane.setContent (myTableView)' ne peut raisonnablement prendre un traitement temps appréciable. Quelque chose d'autre qui se passe dans le code prend le temps; probablement charger les données. Vous devez déplacer le travail qui prend du temps (ce qui n'est pas l'interface utilisateur réelle) vers un thread d'arrière-plan. –

Répondre

1

charge les données dans un Task, en cours d'exécution dans un thread d'arrière-plan. Affichez l'animation de chargement (ou ProgressIndicator, etc.) lorsque vous démarrez la tâche et supprimez-la à la fin de la tâche.

L'idée de base ressemble à:

TableView<MyDataType> table = new TableView<>(); 
// set up columns... 

Task<List<MyDataType>> loadDataTask = new Task<List<MyDataType>>() { 
    @Override 
    protected List<MyDataType> call() throws Exception { 
     List<MyDataType> data = ... ; 
     // load data and populate list ... 
     return data ; 
    } 
}; 
loadDataTask.setOnSucceeded(e -> table.getItems().setAll(loadDataTask.getValue())); 
loadDataTask.setOnFailed(e -> { /* handle errors... */ }); 

ProgressIndicator progressIndicator = new ProgressIndicator(); 
table.setPlaceHolder(progressIndicator); 

Thread loadDataThread = new Thread(loadDataTask); 
loadDataThread.start(); 
+0

Salut! déjà été là. mais j'ai encore essayé avec votre code mais sans succès. la préparation des données n'est pas un gros problème, c'est déjà là, ive a trouvé que la table.getItems(). Set ... ne prend pas ce long dans l'ensemble. maintenant après avoir creusé plus profond j'ai trouvé le coupable de ce gâchis, j'ajustait la hauteur de la table pour adapter le contenu avec ce http://stackoverflow.com/questions/27945817/javafx-adapt-tableview-height-to-number- des lignes en liant le prefHeightProperty de la table à la taille de la liste. l'appel lui-même ne prend pas si longtemps (essayé de le chronométrer), mais si je le commente il est soudainement rapide. – 84n4n4

+0

@ 84n4n4 Je ne comprends pas le commentaire sur la durée de 'table.getItems(). SetAll (...)'. Je ne cours pas 'getItems(). SetAll (...)' dans le thread d'arrière-plan, je l'exécute sur le thread d'application FX, après que le thread d'arrière-plan se termine.Et évidemment, même si vous liez la hauteur de la table à la taille de la liste des éléments (ce que je ne pense pas être assez robuste une solution à utiliser), si vous changez seulement la liste une fois (avec 'setAll (. ..) ') par opposition à l'ajout de chaque élément à la fois, ce n'est pas un problème non plus. On dirait que vous avez besoin de comprendre quel est le problème réel en premier. –

+0

désolé pour la confusion. La préparation de données n'est pas un problème de synchronisation. la définition des données dans la table n'est pas un problème de synchronisation. mettre une table vide ou petite dans mon volet pas un problème de synchronisation. mais quand il y a beaucoup de données, le tout se brise. >> si vous changez seulement la liste une fois (avec setAll (...)) au lieu d'ajouter chaque élément à la fois, ce n'est pas non plus un problème. c'est exactement ce que je fais, avec la liaison de prefHeight son lent, sans son rapide. Je vais pirater un petit exampe et essayer de le reproduire et de le poster ici. – 84n4n4