Hello,
I have a problem with a trivial (at first glance) instruction that generates a software crash, impossible to manage even with a try … catch.
the statement is a creation of a picture object:
myPic = new Picture (v.Width, v.Height)
where v is an object of type DirectShowVideoInfoHeaderMBS (other than Nil!)
arrived at the mentioned instruction, the program crashes.
But the strangest thing is that even using a try catch you can’t handle the possible error.
Must be Integers and less than 32767.
Advice:
Create two local Integers (say vWidth As Integer and vHeight As Integer), fill them with the vlues, check the values and pass vWidth and vHeight to New Picture.
You may check in the Debugger the vWidth and vHeight values to be sure everything is OK.
Which version of Xojo? macOS, Windows, Linux? Can you make an example? Do you get a crash log that you could post? Have you verified that v is not nil and has sensible values for width and height?
Inglese
I had already done this. I have regular values
What do you get in the Debugger ?
obviously, being DirectShow, we are on windows. Xojo 2019 3.1
I forgot! often the function is performed normally. Only a few times I have an error. I believe it may be internal to directshow, but the frustrating thing is that not even a try…catch … avoids the sudden crash. No error message. the program closes and you return to the xojo idea. I therefore cannot even identify the nature of the error
What happens if you use:
myPic = new Picture (1920, 1080)let’s say that the call, basically, works. If I then change the camera, I have a system that resizes the preview of the live stream (which contains this function). At that point, not at the first change, sometimes it crashes
That is why I tell you to use intermediate Integers and check their values.
Try that; and change the camera any times to know if this continues (if so, you will get the offending values) or not…
You may display the values using System.DebugLog vWidth and vHeight…
I have already done the test with the intermediate values, using support variables. Reading v.width and v.height never gave an error. The error was always on the “New Picture (…)” 
But the intermediate values can be wrong (may be).
Beside that and lack of available Memory, I do not know of any source of error.
I begin to think it may be a memory problem: in parallel another function linked to a timer acquires frames at regular intervals.
maybe the operating system dedicates a slice of memory to the running app and, when this threshold is reached, fatal errors occur? I’m not sure how these aspects work.
in any case thanks to all for now
Check for memory leaks. Open the Tasks manager and look at your app, over time. Does it takes more and more RAM up to the moment it crashes?
done. and I think I have had confirmation of what I had already suspected. With a certain resolution, the memory occupied by the app even goes up to 2 GB. With a higher resolution, it goes beyond 3.5!
at this point I believe that instruction will crash ONLY when the memory is full. that’s why, in other situations, it works regularly.
Yes, that’s rather “classic”.
So, you’re making sure your pictures are released?
it’s not that simple to explain. It is a very complex acquisition system, with different types of acquisition. In short, behind it there is a system that collects a few frames and, by calling the pause, you can go back / forward one frame at a time. The solution is to reduce the maximum number of retained frames (from 500 to 100, for example)
This explains that.
I worked with a photofinish system (as a user, not a developer). It keeps some images in memory, but beyond a certain number of images, older ones are transferred to disk. Once the picture acquisition is completed, the remaining images are saved from memory to disk. The navigation back and forth uses in-memory images loaded from a determined time point. Perhaps you could implement something similar? The key here is that every image is a very thin vertical slice of space, taking relatively little memory each.