I have a problem with a refresh on a Label.
I have an function like this :
public void majMontantPaye(Double montantPaye) {
System.out.println("montant paye : "+montantPaye);
setMontantPaye(this.montantPaye+montantPaye);
Platform.runLater(() -> labelMontantPaye.setText(String.format("%.2f", this.montantPaye)+Messages.getMessage("0052")));
}
And My function is call by an API. This API communicate with a machine who allow to insert coin. And my function must to show the sum insert in the machine.
The problem is, when I insert a lot of coin in the same time in the machine, my function is correctly call every coin detected, so the System.out.println("montant paye : "+montantPaye); is correctly show every coin detected, BUT the Label "labelMontantPaye" is not refresh to every coin detected. Just on finish with the total sum.
I guess that the UI is not correctly refresh but I don't know how refresh correctly my Label.
Help please and sorry for mistake, i'm french.
You can follow the logic below:
As mentioned in the comments:
Using Platform.runLater(...) you queue the task into the JavaFXThread. But when you have many "events" you will only see the last result. (And maybe previous ones for a short time).
🍄Use a BlockingQueue to store each coin that is inserted.Use the method below(also have a look at the tutorial for the available methods,here i am using put which is blocking the current thread if a maximum of coins are inserted into the Queue,if you don't want this set the maximum to something like 500.000):
public void insertCoin(//maybe the kind of coin){
//add the coin into the BlockingQueue
blockingQueue.put(//coin);
}
Use a Thread which is running an infinity loop.The Thread is waking up
every time a new coin is inserted and when that is done , that Thread
waits JavaFXThread to refresh the Label Text:
new Thread(() -> {
//Run an infinity Thread
while (true) {
// Blocks until the queue has really any coins inserted
blockingQueue.get();
// Synchronize with javaFX thread
CountDownLatch latch = new CountDownLatch(1);
Platform.runLater(() -> {
label.setText(....);
latch.countDown();
});
// Block the Current Thread until the text is refreshed from
// JavaFX Thread
latch.await();
}
}).start();
Related
I'm trying to display "Game Over" once the player runs out of lives. However, it's never displayed after the game ends. Here is some example code.
void Game::end()
{
QGraphicsTextItem *text = new QGraphicsTextItem("GameOver");
text->setPos(400, 500);
scene->addItem(text);
sleep(2);
QApplication::quit();
}
You dont get the desired result because the drawing occurs after the function it's been called inside returns, and it never returns since you are quiting the application before. As drescherjm pointed out, try to delay the quit by using QTimer::SingleShot. Like this:
QTimer::singleShot(1000, [](){
QApplication::exit();
});
Thus QApplication::exit() is called in given interval, by which time Game::end() should return.
I found time to investigate a bit into QT, and it is very interesting for me. However, right now I am encountering a problem that I am not aware about how to solve it. My aim is actually simple. I have a QCheckBox that I want to activate. If it is activated, I am starting a process (I am opening a file, reading it, taking some values out and change different labels accordingly). This process is repeated until the user is deactivating the QCheckBox. Some small code example to get a better idea of what I am going to do.
void Analyzer::on_actualTemperature_stateChanged(int arg1)
{
// Read data and change labels
if (arg1 != 0)
{
qDebug() << "Start data analysis";
// Infinity loop to get the data and display it
while true
{
// Open file and extract data
const actualTemperature = getData();
// Change any label or do something with the data
ui->anyLabel->setText(actualTemperature);
// Some break
QThread::sleep(1);
// Leave the loop if user deactivate the QCheckBox
// Something like on_actualTemperature_stateChange == 0
}
}
// Stop reading the data
else
{
qDebug() << "Stop data analysis";
}
}
It is obvious that after activating the QCheckBox, the loop will not finish at all and the GUI will not recognize anything anymore. Hence, I guess I have to start some new thread and have to kill it. However, I have no idea how to proceed here. An idea would be:
void Analyzer::on_actualTemperature_stateChanged(int arg1)
{
// Read data and change labels
if (arg1 != 0)
{
// Start reading the file and updating the label using some other thread
startThread(XY);
}
// Stop reading the data
else
{
// Kill thread 1234
killThread(XY);
}
}
Any hint is warmly welcomed and I hope this question is not too basic for you. Thank you for reading, Tobi.
I think killing a running thread is not a decent behavior. Let's be gentle to our threads with a loop control variable. In this example it named keepLoop. Set keepLoop when checkbox checked. Then start thread if it is not running. We are using QtConcurrent::run, and monitoring it by a QFuture in this case.
connect(ui->checkBox, &QCheckBox::toggled,
[&](const bool checked) {
analyzer->keepLoop = checked;
if (checked && !future.isRunning())
future = QtConcurrent::run(analyzer, &Analyzer::on_actualTemperature_stateChanged);
}
);
Don't call user interface slots directly, instead connect them to signals. Connections will be queued connection when signals emitted from another thread. It means slots will be called in event loop of main thread and changes will be shown when the next frame painted.
connect(analyzer, &Analyzer::temperatureCalculated, ui->anyLabel, &QLabel::setText);
Our asynchronous function does not forced to die immediately when user toggle checkbox. Instead we letting it to finish the iteration it already on halfway through.
Analyzer::on_actualTemperature_stateChanged() {
while (keepLoop) {
// Open file and extract data
const QString& actualTemperature = getData();
// send data
emit temperatureCalculated(actualTemperature);
}
}
You can use atomic bool if you want a more precise loop control.
Bonus:
If you don't want to mess with threads, you can avoid GUI freezing by using QTimer to run your loop periodically in main thread.
When I create slots by name with this kind of syntax:
on_<widgetname>_clicked();
If I want to display a particular widget Inside this function it won't display until it reaches the end of the function.
That is, when I create the following function:
void MyWindow::on_myWidget_clicked()
{
// the stackedWidget is composed of:
// page_1 with myWidget
// page_2
ui->stackedWidget->setCurrentWidget(ui->page_2);
waitSomeTime();
}
whith
void MyWindow::waitSomeTime()
{
QThread t;
t.sleep(2); // Wait 2 seconds to see which line is going to be executed first.
}
When the code is launched, the 2 seconds elapsed first and only then the page_2 is displayed.
Why the line
ui->stackedWidget->setCurrentWidget(ui->page_2);
is not executed first?
void QThread::sleep(unsigned long secs) [static]
Forces the current thread to sleep for secs seconds.
the waitSomeTime function make the main (current) thread sleep, so it will block everything, even GUI processing. As #scopchanov commented, you could use QApplication::processEvents(), which will process the event of setCurrentWidget. However, the whole GUI will still be blocked until the sleep is done, which means, that the widget will be shown, but won't be able to handle any operation.
So it would be better to use QTimer::singleShot if you want to delay the work, or start another new QThread to do it.
What I want to do is display a set of pages setting up a test. Once all the details are correct the user presses Commit and the next wizard page is displayed that I want to immediately run a series of tests in. Displaying those to the user and once complete the user can then click Next.
I know to disable Next is simply a case of returning false on isComplete() and that is implemented okay. So, I want to use the function that is called just after the widget is displayed and so I used showEvent() which was indicated to me as the function to use.
At the moment my test is just displaying a progress bar as a test hence using a timer.
void RunTestWizardPage::showEvent(QShowEvent *event)
{
ui->statusEdit->setText("Running Tests");
timer = new QTimer(this);
connect(timer, SIGNAL(timeout()), this, SLOT(update()));
timer->start(100);
}
void RunTestWizardPage::update()
{
static int i = 10;
ui->statusEdit->append("Running Tests...");
ui->testProgress->setValue(i++);
if(i == 100)
{
i = 0;
timer->stop();
complete = true;
emit completeChanged();
}
}
However this function appears to be called twice (and I think before the widget display although that may be a trick of my debugging) and as such it causes issues with the timer I think as the timer never ends. I did read in the docs about spontaneous events but from what I can see both calls to the function are not spontaneous.
Is it being called twice intentional and if so how do I stop it or is there another function to use?
Thanks!
There is QWizardPage::initializePage() which is called just before showing the page.
In an AIR application I have the following code:
theDialog = PopUpManager.createPopUp( this, TheDialogClass, true ) as TheDialogClass;
theDialog.addEventListener(FlexEvent.CREATION_COMPLETE, cpuIntensiveCalc);
At the end of cpuIntensiveCalc the dialog is removed. The dialog informs the user that "something is going on, please stand by."
The problem is that cpuIntensiveCalc starts before the dialog draws. So the user experience is that the application freezes for 10 seconds with no indicator, then the modal dialog flashes quickly (less than a second) on screen.
The Adobe docs say this about creation_complete
Dispatched when the component has finished its construction,
property processing, measuring, layout, and drawing.
So this feels like the correct event.
In the name of completeness, I also tried
theDialog = PopUpManager.createPopUp( this, TheDialogClass, true ) as TheDialogClass;
cpuIntensiveCalc();
But had the same results.
TIA
The reason for this is that the Flash Player is single threaded, and so you are blocking the UI from reacting to the Dialog Popup until the maths chunk is finished.
Hacky fix time...
You have two options.
(This one should work, but is untested) Wrap the cpuIntensiveCalc() call in a callLater, so that the UI can finish rendering before you block the rendering.
Or
Use "Green Threads" to break up your processing so that you don't completely block the UI processing. Take a look.
(I just had the same issue => even if this thread is old, I just wanted to contribute my solution)
(disclaimer: this is a bit ugly, but they say that's ok in the UI layer... ;-) )
Flex is single threaded (at least from our developer's perspective, I think behind the scene threads are used by the VM)
=> you typically execute your code in the UI thread, after the user did some action on a widget. Any call to update a UI component (like setProgress or setLabel) will only be rendered on screen at the end of the render cycle (see again UiComponent life cycle).
=> In therory calling "cpuIntensiveCalc" in a callLater will let the framework display your popup before executing the method.
In practice though, I noticed you typically have to have for a couple of UI cylces before the popup be displayed, like this:
new MuchLaterRunner(popup, 7, cpuIntensiveCalc).runLater();
MuchLaterRunner being defined like this:
public class MuchLaterRunner
{
var uiComp:UIComponent;
var currentCounter = 0;
var cyclesToWaitBeforeExecution=0;
var command:Function;
public function MuchLaterRunner(uiComp:UIComponent, cyclesToWaitBeforeExecution:uint, command:Function)
{
this.uiComp = uiComp;
this.command = command;
this.cyclesToWaitBeforeExecution =cyclesToWaitBeforeExecution;
}
public function runLater() {
currentCounter ++;
if (currentCounter >= cyclesToWaitBeforeExecution) {
uiComp.callLater(command);
} else {
// wait one more cycle...
uiComp.callLater(runLater);
}
}
}
The issue is the same when calling setProgress afterward: we must divide cpuIntensiveCalc into small callable methods that can be ran at each UI cycle, otherwise the progressbar won't, err, progress.
Use enterFrame event on popup. Don't forget to remove the listener in the enterFrame event handler - otherwise the cpu intensive method will be called in each frame, crashing your app. If this doesn't work at first, use a private number as a counter and keep incrementing it in the enter frame handler - call cpu heavy method only when the counter reaches the appropriate value. Find the 'appropriate' value by trail and error.
theDialog = PopUpManager.createPopUp(this, TheDialogClass, true) as TheDialogClass;
theDialog.addEventListener(Event.ENTER_FRAME, onEnterFrame);
private function onEnterFrame(e:Event):void
{
//can use theDialog instead of e.currentTarget here.
(e.currentTarget).removeEventListener(Event.ENTER_FRAME, onEnterFrame);
cpuIntensiveCalc();
}
//in case the above method doesn't work, do it the following way:
theDialog.addEventListener(Event.ENTER_FRAME, onEnterFrame);
private var _frameCounter:Number = 0;
private function onEnterFrame(e:Event):void
{
_frameCounter++;
var desiredCount:Number = 1;//start with one - increment until it works.
if(_frameCounter < desiredCount)
return;
//can use theDialog instead of e.currentTarget here.
(e.currentTarget).removeEventListener(Event.ENTER_FRAME, onEnterFrame);
cpuIntensiveCalc();
}