Just noted that while in the debugger in 2016r2 events happen in the background (Timers, Receive Events etc).
This does not happen in 2016r1.1, making debugging in 2016r2 impossible in complex environments where stuff happens in the background.
Running IDE on Windows 10 64-bit.
<https://xojo.com/issue/44572>
(I could not select the correct IDE version on the FB Case, maybe someone can set it correctly)
Fixed.
Thank you. Sorry, it happens to me earlier today, but I forgot to note it.
Sure is disappointing since my original problem with 2016r1.1 - the slow HTTPSocket now seems to be fixed (<https://xojo.com/issue/40580>) … Back to 2014r2.1 again…
This wasn’t present in beta 1 through 23 ?
I’ll be honest with you Norman and admit that I have only used the 2016r2 betas on non-shipping projects and testing.
The project I found this in is one of my company’s core products downloaded by hundreds of people every day and I cannot afford risking the code nor spend all the time needed to port it from 2014r2.1 (UIAccessFromThread Exceptions). When 2016r2 was actually released today I branched and started working on getting rid of UI accesses from Threads and within a couple of minutes I found this.
I use the betas to verify the status of my actual bugs (like 40580 mentioned above) and play with the new functions added to new versions of Xojo (like the HiDPI in 16r1 that I was very vocal about on the beta forums if you remember).
/Mattias
Nothing running in the background here
If you dont rapidly press the button in the sample then the timer runs and is does a sem.signal
Th default set up is multiple 1000 msec
And it NEVER does a release
So when you do press the button and continue the second sem.signal can’t complete - the sem has not been released by the timer IF it ran before the button was pressed
So it locks the sample app up tight waiting for the second sem.signal
Add in releases and things work as expected
And the timer really never does run while at the breakpoint in the button
Did you mean to have timer.mode initially set to OFF ???
Other than that I cant see anything “running in the background”
Yes, the Timer is initially set to OFF and then single-shot from the code.
However - now my Wierd-sh*t-O-Meter is showing 11: this problem ONLY happens when I use my EXTERNAL USB wireless mouse (Logitech), NOT when I use the HP’s touchpad.
Never happens in 2016r1.1, even when using the external mouse.
in the sample project its initially set to single
so if you dont press the button very quickly the timers action runs, grabs the semaphore & then things dont work in the buttons action event
if I set the timers mode to off then it doesn’t run even when set to one shot in the action event
Yes, but wouldn’t I get two debugger breaks then…?
Anyhow - rebooted the system now and it seems to be working again (at least I can no longer reproduce it with my FB case).
Hmmm… Didn’t see your comment until now. In my copy it is Off. So - my bad I guess. However the problem was still in my large project so I will get back to that and see if I run into this “problem” again (it’s more convoluted with Sockets etc).
Why would you get two breaks ?
There’s one break statement in the entire project in the buttons action
The only thing that seems different is that in 2016r1.1 the app should have locked up tight since nothing ever releases but didn’t
Now it does
If you change the timer to be off initially then the only break & signal is still in the button
Now it may eventually also lock up tight if you press the button repeatedly
Again calling signal without a matching release on the same thread, in this case the main thread, will do that and things are documented that way