Close app as soon as the event loop is idle instead of using qApp->quit()
to allow dispach of other events.
This prevent app to not closing properly in rare situations like:
- Interpreter is running a program
- Interpreter emit() a blocking function in Controller (using QWaitCondition or BlockingQueuedConnection).
- User request to close app while function is runnig in main loop. So, closeEvent is put in queue.
- Function ends and return control to Interpreter. Interpreter request to run another code in main loop using emit().
- Instead of running this code, the previous closeEvent() from queue is run.
- Using qApp->quit() this will block forever Interpreter (never return), so, i->wait() will never return.
This is an old issue. It takes me a lot to manage it.
To see this bug, run code below in debug mode and close BASIC256 window while running:
for a=1 to 20
call ggg
next a
print msec
end
subroutine ggg()
dim b(100000)
end subroutine
Before:
- look at array1d, it is displayed as 2d array
- look at x array. It is displayed with wrong dimensions
After: perfect.
The order in variable window it did not bother me before. But andrask is right.
Before: a[0], a[1], a[10], a[11]..a[19],a[2]
After: perfect order
Just hold the mouse over the type of variable (I, F, S...) for description.
Run this program and sort variables by value in variable window:
a=111
b=67.34
c=PI
d=-2
e=-10
f=-19
g=10
h=20
i=0
j=19
k=3
l=-9
Before: OMG
After:
Before:
After:
If user changes preferences about printing numbers (number of digits, decimal point type etc.) the variable window will use the new settings.
for f=0 to 1000
dim b(50,50)
next f
print msec
Result: 20056 ms vs. 36202 ms
for a=1 to 100
call ggg
next a
print msec
end
subroutine ggg()
dim b(10000)
end subroutine
Result: 6353 ms vs. 17380 ms
for a=1 to 100
dim b(10000)
b=0
next a
print msec
Result: 6517 ms vs. 17179 ms