One of the Menus in my app has an Edit Menu with the typical Cut, Copy, Undo, and Paste items added to it. These items are used with the TextArea control I have on my window.
I noticed that on macOS there are additional items added to my editmenu that I simply don’t want. How can I remove them? (see screenshot).
These are standard menu items under macOS and expected to be there. I would just leave them alone.
I actually found a way to get rid of them. In the Text field of the Inspector for my EditMenu, I simply preceded it with an empty space.
You can also change the Text value to any else but the word “Edit” and that works just as well. Go figure.
It’s weird, but it works.
The problem I have is that on Linux and likely Windows as well (once I test it), the options differ and I prefer it to be consistent because I have clients who use multiple computing platforms.
You are working against the OS. That’s not a good idea.
Setting aside what YOU prefer – your clients use different platforms because that’s what THEY prefer, and you owe it to them to give them a UI experience that is authentic to that platform. That includes these menu items.
Appreciate the feedback.
It also mean that cut, copy and paste will not work in EditFields anymore. This is not a good idea.
The only edit field it has is TextArea and it works fine.
When I renamed the menu “mnuEdit” it completely failed. It says in the documentation that it must remain the same. I was changing it for consistency but I gave up on that. What is the problem with having them there. If you user wants to enter data via voice, why would you want to stop them.
Let me first apologize for causing us to go off script a bit from my original request.
Let me provide a bit of historical context here:
In the industry within-which I’ve been writing software (oil & gas) for the past 34 years, it has only been within the past 4 or 5 years that I’ve had to write anything for macOS. I have written software for iOS, however the dev tools of choice were either C# or SWIFT. As such, my experience with the nuances of Apple Intelligence (specifically the Writing Tools) is quite limited.
The two primary operating systems that I’ve had to deal with are Windows and Linux as most of my clients are in the Petroleum Engineering space and those are the two main operating systems that they use, however macOS has become a bit more prevalent as well in recent years.
Why I chose Xojo?
Please keep in mind that I’ve only been using Xojo for a year now! Prior to Xojo, my computer programming background has been in C++, C#, PL/SQL, VB.NET, and PowerBuilder.
There are (RAD and Cross-Platform support) primary reasons why I decided to begin using Xojo and becoming a Pro Plus subscriber:
RAD (Rapid Application Development
Cross-Platform (iOS, macOS, Windows, Android, and Linux
User Feedback:
Having said that, for the past couple of weeks I’ve been receiving feedback from my customers (two different corporations) as it relates to these additional menu items.
Truth be told, I never really noticed those menu items on the Mac during my testing because neither Windows, nor Linux adds anything to the Edit menu of my applications. Not even Copilot which is pretty much forced into nearly every aspect of Windows 11 does this. Several of my users brought it to my attention.
To give you a better idea of how my application is used. In oil & gas, users have to enter in (as an example) something called Well Test data. There are certain abbreviations and company-centric codes that are entered into the TextArea control of my application. Because of this, Apple’s AI tries to “assist” by adding capitalization and auto-correcting and underlining codes that it simply thinks are misspellings (or whatever it thinks it is). In short, while AI is acceptable in other 3rd party applications they use, it is unacceptable in this particular use case.
Yes! You can right click in the TextArea and selectively disable/enable the AI spelling and grammar options, however I have yet to find a way using Xojo to persist those selections once my application is closed.
The TextArea control has a property (TextArea1.AllowSpellChecking). I have a menu item called: “Spell Checking”. When the user enables/disables it, I store that value to an appsettings file so that when the application reopens the application, it retains that enabled/disabled state that the user last made to it (this is a customer requirement). Setting that property to False (no surprises here) does not disable the Apple AI spelling and grammar (thus the confusion).
I’ve been receiving support incidents about this because they thought it was something “I” explicitly added to the application.
Unfortunately, based on what I’ve seen thus far, the Xojo framework doesn’t provide a mechanism for capturing any of these Apple AI settings so that I can persist them to storage as well (or just disable them outright). The Engineers find it frustrating to have to go in and right-click to disable features they don’t want each time they use my application. They showed me another application (written by another company) used for a different use case on macOS that has spelling and grammar, Substitutions, Layout Orientation, and AutoFill all removed from the menu.
Summary:
I do agree with Ian Kennedy, however that the dictation feature is something good to retain (and none of the Engineers have a problem with that either).
Even Apple’s own Developer Documentation talks about times when you may want to disable Writing Tools and this is a direct quote from their documentation:
“The UITextView and UITextField classes have built-in support for Writing Tools, but you can customize how the feature works for your interface. You might choose to change how someone experiences Writing Tools in your app, or disable the feature for specific types of content. For example, you might disable Writing Tools in a view that you use to display code listings. You can also customize the type of content Writing Tools generates for your text view.”
I’m assuming that the Xojo TextArea is neither a UITextView or UITextField because of the need for cross-platform support.
Decisions-Decisions:
One of my desires for using Xojo is that I only have to maintain/support ONE code base for all 3 operating systems and seeing as how (coming from Geoff Perlman) the genesis of Xojo was macOS, I was hoping to find a solution using Xojo for this.
However, because this issue may quickly become a showstopper (and I highly suspect it will based on feedback I received from both companies yesterday in separate meetings), I am going to have to (unless any of you can suggest another way using Xojo) write the Mac version in SWIFT where I can disable the writing tools feature(s). The Windows and Linux versions can remain in Xojo.
Perhaps I could write an API using SWIFT that would tackle this and then use a Declare Function statement in Xojo to handle it that way. I dunno (i’m kinda thinking aloud right now).
I need to think it through pretty quickly so that I can wrap this project up and get paid.
So this isn’t “ME” just wanting to disable it to make it consistent across operating systems (Windows and Linux simply don’t currently do this). This is based on recent user feedback and my livelihood, gentlemen.
Again! I DO apologize for not being a bit more clear with my initial request, but I’m under-the-gun to get this application completed and sadly, if I need to have two code bases, then so be it.
My original lack of clarity lead to a discussion on the merits of keeping these menu items vs not keeping them.
I hope that this update helps provide that clarity.
I’m petty sure MBS offers the ability to turn off these elements from code. It’s also quite likely that they can be disabled via Declares directly from Xojo. Most things that can be called from Swift can be called from Xojo. A major exception is SwiftUI elements.
If you have a Swift method or variable you wish to access ask Google AI to provide a Xojo declare, it usually does a good job. Once you know the pattern you can do the declares yourself.
For example Google AI provided this example:
Declare Sub setAllowsWritingTools Lib "AppKit" Selector "setAllowsWritingTools:" (target As Ptr, value As Boolean)
setAllowsWritingTools(TheTextArea.Handle, false)
Declare Sub setAllowsWritingToolsAffordance Lib "AppKit" Selector "setAllowsWritingToolsAffordance:" (target As Ptr, value As Boolean)
setAllowsWritingToolsAffordance( TheTextArea.handle, false )
TextArea and TextField have Allow Spell Checking options in the Behavior section of the Inspector which can be turned off, which will solve a few of your problems.
I’m doing that already as I stated in my lengthy reply (above). It does not disable Apple Intelligence spelling and grammar checking, however.
Here is a sample with a simple edit pop-up menu in a DesktopTextArea.
Also see remarks by MarkusR in DesktopTextArea Right Click Options - #2 by Keith_Culotta
SimpleEditMenu.zip (5.6 KB)
At your place, I will check other applicatio and see if they share the same behavior (and they do since this is a macOS addition).
So, my answer will be the truth: “It is an OS set of Features. If you do not like it, do not use it”.
That said, I understand now why you want to do that.
If you get a simple solution, use it /implement it.
If you do not get a simple solution after a small, limited time (one hour ?), remember your billing hour, and tell your users you do not know how many time it will take to answer their demand, and tell them your billing hour. I am quite sure they will say something like: “forget it” (stop waste your time).
Thanks. Yep. I’ve already alerted them to this (effort vs duration). I did tell them that they can disable Apple Intelligence at the macOS level, but then they’d need to re-enable it for any other applications they use in which that functionality is desired.
You can disable all of the macOS TextArea “help” like this.
dim n as NSTextViewMBS = me.NSTextViewMBS
n.AutomaticQuoteSubstitutionEnabled = false
n.AutomaticSpellingCorrectionEnabled = false
n.AutomaticTextReplacementEnabled = false
n.AutomaticDashSubstitutionEnabled = false
n.AutomaticLinkDetectionEnabled = false
n.AutomaticDataDetectionEnabled = false
If you don’t have MBS plugins, then any AI can turn these into declares.
I will purchase a MBS Plugin license.
Thanks!