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