What about using CallDelegateOnMainThreadMBS instead? I mostly use the method to de-spaghettify my code. So far I never resulted in strange crashes.
Since Im already operating on the main thread, I am not sure what this would do for me.
May I ask what NumberOfRows and NumberOfColumns is typically set to? And what are the maximum values?
What Im thinking is that within those two loops, the numbers are multiplied. So 4 rows and 4 columns means that the timer is called 16 times… and to be clear, v is also initialized 16 times. Which means that when the loop comes around again, v gets reinitialized and the previous instance goes out of scope and the weakAddress no longer points to anything.
My guess is that this method works perfectly when rows and columns = 1 and anything larger causes the nilobjectexceptions youre seeing.
Uh, no. Greg, I am NOT getting an NOE exception here. The timer never fires in Windows. Thats the problem in this instance.
Please read my posts more thoroughly. But you have your paradigm about my problem.
Each v is separately created and added to an array that is a property of the window. So its impossible for them to go out of scope. The number of rows and columns could be anything. Depends on the users system and how many video previews they are displaying.
I am creating multiple canvases. Each one then gets painted onto the window. The loops create the canvases but they dont go out of scope because they are stored in a property. I have stated this multiple times.
The timer is not firing in windows. It fires fine in OS X in this instance.
This is my point: Xojo.core.timer.calllater is unreliable.
This gives you the same functionality as CallLater but uses the classic framework:
http://www.katkosoft.com/Persistent%20Timer/PersistentTimer.html
And it’s free.
[quote=396301:@Karen Atkocius]This gives you the same functionality as CallLater but uses the classic framework:
http://www.katkosoft.com/Persistent%20Timer/PersistentTimer.html
And it’s free.[/quote]
YUP. It’s what I am using exclusively now instead of the new Xojo Framework call. It’s reliable and it works.
[quote=396291:@Greg O’Lone]…Which means that when the loop comes around again, v gets reinitialized and the previous instance goes out of scope and the weakAddress no longer points to anything.
My guess is that this method works perfectly when rows and columns = 1 and anything larger causes the nilobjectexceptions youre seeing.[/quote]
So now that I am back to my laptop, let me expound upon this some more:
Here is the code where "v’ is created:
If Create Then
v = New ViewCanvas // Create a new canvas
v.SourceDevice = SourceDeviceArray(SourceArrayIndex) // This is an object that gets assigned to the canvas
v.SetupHandler // Setting up all my event handlers
Else
v = PreviewCanvases(k) // Not new - picking from my array of canvas objects already created
End IfSo if create is False, then I pull “v” from my property array named “PreviewCanvases”
And this is where I store “v” when I am creating it:
If Create Then
v.OriginalWidth = CanvasWidth
v.OriginalHeight = CanvasHeight
self.Height = v.Top+v.Height
CanvasWidth = v.Width
CanvasHeight = v.Height
v.indx = k
v.CaptureTime = CaptureTime
PreviewCanvases.Append v // Append the new canvas to the array
Xojo.Core.Timer.CallLater(0,AddressOf v.DoCapture) // THIS IS THE TIMER THAT DOES NOT FIRE IN WINDOWS!
End IfSee the line: PreviewCanvases.Append v - That’s where v gets stored to the window. So that object does not go out of scope when the next iteration of the loop occurs.
And let me make it clear again - I am not getting an NOE exception in this case. In Windows, the v.DoCapture method never runs. The timer never fires. Never gives any errors. In OS X it is fine. Seems like this did work in earlier releases of Xojo as I’ve been using this for a couple years but compiled with 2018r1.1 it doesn’t work.
Using Karen’s SingleActionTimer.CallLater method in place of the Xojo.Core.Timer.CallLater method works flawlessly.
Please Xojo - there IS a problem with Xojo.Core.Timer.CallLater. Somewhere the instance of the object is being lost at random. It doesn’t happen all the time. But it does happen particularly when multiple calls to Xojo.Core.Timer.CallLater have been made around pretty similar times. In my case I may have 16 or more of these all firing pretty quickly after each other.
Like I said, I have seen odd ball NoE errors that occur at random, errors like above where the code just doesn’t run, and Xojo.Core.Dictionary Iterator errors (dictionary was muted while iterating over it or something like that) that are clearly due to something happening inside the Xojo code (not mine as in the dictionary cases, no dictionary was involved on my end). And no, these seem to be at random and are NOT easily reproducible in en example bug report. Believe me, if I could, I would.
What happens if you try windows with 1ms delay instead of 0.
Or am i missing something about why its set to 0 ms?
[quote=396320:@Derk Jochems]What happens if you try windows with 1ms delay instead of 0.
Or am i missing something about why its set to 0 ms?[/quote]
As I understand it, 0 ms is really 1 ms. Basically 0 states to fire the timer as soon as possible. (ie: no delay).
Are you compiling the windows edition in 32 or 64 bit?
64 bit
Not meaning to ignore your words about the timer not firing. I just never experienced it and would like some way to reproduce it.
Therefore: Does your code depend on the order of vs created? If so, it will not work on Windows because stacked CallLater calls will be executed First In Last Out while on Mac they are FIFO.
I think you mentioned that it worked in previous versions without issue?
Personally, I wouldn’t release anything on Windows in 64bit at the moment with 2018r1 or later.
<https://xojo.com/issue/52211>
Give it a build in 32bit and see if the problem goes away.
Just a hunch.
[quote=396355:@Ulrich Bogun]Not meaning to ignore your words about the timer not firing. I just never experienced it and would like some way to reproduce it.
Therefore: Does your code depend on the order of vs created? If so, it will not work on Windows because stacked CallLater calls will be executed First In Last Out while on Mac they are FIFO.[/quote]
It should not. The “v” is just an object (canvas) that gets positioned in the window at specific coordinates.
[quote=396356:@]I think you mentioned that it worked in previous versions without issue?
Personally, I wouldn’t release anything on Windows in 64bit at the moment with 2018r1 or later.
<https://xojo.com/issue/52211>
Give it a build in 32bit and see if the problem goes away.
Just a hunch.[/quote]
OK. I can try that. But that still doesn’t solve the issue of all the other problems I’ve had with these but it could solve this.
[quote=396356:@]I think you mentioned that it worked in previous versions without issue?
Personally, I wouldn’t release anything on Windows in 64bit at the moment with 2018r1 or later.
<https://xojo.com/issue/52211>
Give it a build in 32bit and see if the problem goes away.
Just a hunch.[/quote]
Damn, Julian! As usual you are correct. I compiled in 32 bit and it worked fine.
This is one thing that is so embarrassing about Xojo. Something works fine in one version. I release a new build and unbeknown to me, Xojo broke something that I have to go work around. It’s happened more than once and I have to apologize to my customers for the bug introduced by my framework vendor.
What’s even stranger is now that I’ve built it a second time in 64 bit, it seems to be working…
That’s my whole point - it’s not reliable…
Yeah, I had a sneaky feeling as I was narrowing down your issue with all the questions I was asking on the different threads.
From my limited time replicating the issue in the demo of my ticket I think it’s highlighting a fundamental problem. At a guess, if you get memory or allocation of free space in the right order things will work if not then it’s the roll of a dice if it’ll work.
I don’t think it’s a timer issue per se but a serious low level issue, your use cause is just causing the problem to surface much like my use case in the ticket.
It’s bitter sweet but it’s good that there’s another issue linked to the problem, maybe this will accelerate the importance of getting to the bottom of the issue as I’m a bit surprised its not been look at in the last two months.
Well maybe it may not fire on windows for some reason when you set it to 0?
Im not sure but it could be they are using this WinAPI for it:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms644906(v=vs.85).aspx
Which has a minimum value of 10ms (0x0000000A).