<https://xojo.com/issue/36834>
This bug has been around for a while now, still happening in 2016r2.1 - no workaround (without ditching the native toolbar).
Hard crashes are bad news.
Pretty please?
Would like to see this fixed too, especially because of the hard crash. We can’t reproduce it consistently but have seen it in more than one app.
I have a project attached to the feedback request that reproduces it consistently (although it is a contrived stress test to make it happen quicker).
Still hoping for a fix (not fixed in 2016r3 or 2016r4)
Still hoping for a fix (not fixed in 2017r1)
Still hoping for a fix (not fixed in 2017r2)
Is the example supposed to crash? Doesn’t happen here with 2017r1 on High Sierra after a minute or so.
Which example? There are several attached to the case.
Your latest example, which so lovingly says “Crashy Bar”: ToolbarButtonCrashProblem1a.xojo_binary_project.zip
Still crashes for me (Sierra, not High Sierra) Xojo 2017r1, 2017r1.1, 2017r2. Takes no more than 4 or five rapid clicks on the button.
If anyone else, like me, cannot access the feedback , this post is pretty obscure.
So the original discussion is here:
https://forum.xojo.com/17933-toolbar-crashes
Strange. I downloaded the project attached to the bug report, and indeed, the crash happens like clockwork.
I tried to do the same in my app CheckPrint’R where I use the toolbar, and one of the button toggles between two different icons, I could not get it to crash.
It seems the issue could be due to the timers.
If instead of launching timers the change is effected in Action, no crash under Sierra with 2017R2, even after 10 or more rapid clicks :
[code]Sub Action(item As ToolItem) Handles Action
//dim n as new NSAutoreleasePoolMBS
Select case item.Tag.StringValue
case “1”
set1
case “2”
set2
end Select
End Sub
[/code]
The timers are there just to make it happen reproducibly, quickly. In a real world application, the button changes happen as the result of other asynchronous operations, like logging into a server, so those changes can’t be made during the action event.
OK. My app does not do asynchronous stuff?. I will stop worrying for nothing, then.
Still hoping for a fix (not fixed in 2017r3)
Didn’t realize I ran into this issue last week.
Worked around it with Xojo.Core.Timer.CallLater(0, WeakAddressOf HandlerMethod)
We do a few things like that as well and never have this particular crash
However what you cannot do is hold a static reference to one of the buttons
You have to hunt down the right button on the toolbar every time
Unfortunately, when the change comes asynchronously (not in the same event loop as a click on one of the toolbar buttons), there is no way to work around it with timer tricks. The crash happens on click, before we even get the opportunity to handle the click. (Think about a login button that is disabled on click, and enabled when the login finishes (asynchronously) - when the toolbar button is disabled/enabled, the Xojo framework swaps out the underlying Cocoa button, and when a user clicks at just the right time, boom, crash (because the button that was there on mousedown is gone before the actual message gets sent to it).
Maybe the crash I was experiencing was different. I saw “reallyReallySend:” in the crash log (or whatever it’s similar to). I found through trial and error that it was the code attempting to execute in the same event as Toolbar.Action was what was causing the hard crash. Using a 0 timer was my way of breaking it out of that event, and crashes no more!
Edit: and this was with a toolbutton that would get enabled and disabled frequently, it was a stop button for a media player.
There could be multiple paths to the same crash, some which are able to be worked around and some that aren’t.