The aim of this thread is to list out all the issues that we discover with Mojave and possible solutions.
Accessing the Dock Icon crashes the application. Workaround: none yet. Note: I’ve tried to report this in Feedback and after writing it all up. Reported to Xojo & Apple. <https://xojo.com/issue/52636>
Xojo listbox header is drawn wrong. Workaround: Use a canvas and fake it. Note: Xojo are working on fixing it. <https://xojo.com/issue/52409>
Cocoa exceptions are no longer logged to the console. Workaround: none yet. Note: Trying to prepare applications for Mojave are hard when things have changed, which causes a Cocoa Exception. This results in a function silently failing, with no pointers or indication why. You must manually step through code until you find the line it fails on, then do research to figure out why that line fails.
Remote debugging to a Mojave machine, doesn’t remove the debug build. Workaround: Manually remove the build. Note: Feedback report <https://xojo.com/issue/52637>
Edit: Updated reported status, now that I could get back into Feedback. Also Kudos for auto saving the report and offering to submit when I got back into Feedback. Added Cocoa Exceptions silently failing & Remote Debugging issues.
@Sam Rowlands : you must be doing something odd ™ to the dock. Oh, that’s just 2 lines of code. Works fine with MBS so I don’t think the dock problem is an Apple problem.
It working fine with MBS means that it’s a Xojo issue and should not be reported to Apple.
@All - I would suggest holding off reporting issues to Apple unless you can recreate them in Xcode and are sure it’s an underlying Apple problem. My guess is that most issues are Xojo issues.
I’m using pure Xojo code, no declares or plugins used in this process, although I do have the declares in another project. I’ll dig them out and give it a try.
Dock icon crashing workaround.
Dug out my old code for doing this in the past and it works. I have updated the Feedback report to indicate this. Thanks to @Beatrix Willius for testing his code and forcing me to rethink about it.
[code]Dim p as new picture( 240, 240 )
Dim g as graphics = p.graphics
g.scaleX = g.width / 80
g.scaleY = g.scaleX
g.filloval 20, 20, 40, 40
#if targetMacOS then
Dim NSImage as ptr = p.copyOSHandle( picture.handleType.MacNSImage )
declare function NSClassFromString lib “Foundation” ( aClassName as CFStringRef ) as integer
declare function sharedApplication lib “AppKit” selector “sharedApplication” ( classRef as integer ) as integer
declare sub setApplicationIconImage lib “AppKit” selector “setApplicationIconImage:” ( NSApplicationInstance as integer, NSImageInstance as ptr )
setApplicationIconImage( sharedApplication( NSClassFromString( “NSApplication” ) ), NSImage ) #endif[/code]
Another bug, quite a big one for me, is that apps built with Real Studio 2012r2.1 crash on launch in 10.14b2, apparently due to an over-release of a CF object. Meaning I cannot use RS to develop on Mojave. I’m sure Xojo won’t fix this, but I still like to understand what’s changed to make this crash now. I then plan to report this as a regression bug to Apple and hope they’ll fix this.
After some analysis that Christian did, we now believe the crash at launch is not caused by MBS plugins in particular but by Xojo’s code that loads a plugin, i.e. any plugin.
We see this kind of crash:
[quote]Application Specific Information:
objc_msgSend() selector name: release
It seems that the code that loads a plugin (through dlOpen) does not correctly retain some object that is then later supposed to receive a notification.
Christian also found that this crash does not always occur, suggesting it’s a race condition where the object in question might get autoreleased too early, or live long enough for the notification to get posted.
Either way, this will break a few tools I and maybe others have released in the past unless we can coerce Apple to add a special case to avoid this particular crash in Xojo-made apps.
This occurs immediately after startup. MacBook Pro 8 Gb 2017. Scrollbars do not respond but after clicking on other screen objects they seem to get ‘unstuck’.
Bug Reports (as opposed to Feature Requests) no longer have a “Reviewed” status. We did away with that several years ago because it’s functionally indifferent from “Needs Review”. Once it’s reviewed, it will take on one of the following statuses:
Information required (and then back to Needs Review) If the tester needs more information from you to reproduce the bug.
Closed - If the case is not reproducible or otherwise not a bug.
Verified This doesn’t mean that it’s actually a bug however, just that a tester has been able to verify the behavior stated on a case. The engineering team will make the final determination whether or not something is a bug.
Since we are in the beta cycle for this summer’s release and Mojave isn’t due out until late fall, those cases are being gathered into a common place where we can keep track of them for testing all at once on a version of Mojave that is much closer to what will be actually released is available. As I’ve said before, It’s not uncommon for the things that our users to report in the first few public betas of an upcoming macOS release to be resolved by the time we reach late summer and we’d rather not waste the cycles trying to fix those things.