1

Here's an image of an NSPredicateEditor in one of my apps:

NSPredicateEditor

What I'd like to do is stop the class from drawing the grey background in each row and the "separator" lines between rows, leaving just the popup buttons, textfields and text in each row. After much googling and various attempts to hack the class, I haven't found a way to do this.

I AM aware of another, similar question about NSPredicateEditor on SO, but that person wanted to draw custom, alternating rows. I'm hoping someone might have a trick to simply stop the background drawing altogether.

Thanks!

Bryan
  • 4,628
  • 3
  • 36
  • 62

2 Answers2

1

Unfortunately, there's no way to do this. :(

I suggest that you file an enhancement request at https://bugreport.apple.com.

Dave DeLong
  • 242,470
  • 58
  • 448
  • 498
  • Thanks Dave; I've done so. One more bug report down the black hole of death. – Bryan Oct 21 '13 at 07:30
  • 1
    @Bryan what was the number of the bug report? I'll make sure the AppKit team gets it and it doesn't get lost. EDIT: never mind, I found it: #15147978 – Dave DeLong Oct 21 '13 at 14:32
1

To prevent the drawing of separator lines in the NSPredicateEditor, just use this extremely simple sub class (Swift 4):

import Cocoa

class PredicateEditor: NSPredicateEditor {
    override func draw(_ dirtyRect: NSRect) {}
}
Ely
  • 8,259
  • 1
  • 54
  • 67
  • Hmm. I haven't tested this, but this is an approach that's super fragile. You never know when Apple might change their internal drawing for this class in an OS update, rendering your app broken. On the other hand, it's also been 5 years since Dave DeLong requested an enhancement from the AppKit team, so it appears the black hole of death that is Radar continue unabated. – Bryan Mar 18 '18 at 07:47
  • @Bryan: I disagree with you that this approach is 'super fragile'. Apparently Apple only draws some lines within the editor. All other drawing is done by the sub views, which are not affected by this code. – Ely Mar 18 '18 at 09:10
  • Ok. But at any time they could decide to do additional drawing in that method. And, if you've overridden it to be a no-op, that breaks. It's a two-part problem because you can't anticipate Apple's future moves. – Bryan Mar 25 '18 at 05:55
  • @Bryan: I don't share your fear for breaking stuff by using an empty `draw` implementation. If Apple decides to put some new efforts on this control (which is already very hypothetical these days), you will probably miss some new 'chrome'. But this will not affect the usability of the control, because this is handled by the sub views, which are not effected by this `draw` method. And if I miss that new chrome in the future, I just update my app by removing or updating this `draw` method. – Ely Mar 25 '18 at 09:31