Cocoa/NSPopupButton y-coordinate weirdness

[duncanparsons]

afternoon...

In our sparkly new Cocoa implementation there's an issue with the popupmenus..

We have popups attached to voice and patch selectors, and when needed they are invoked thus:

Code: Select all

	NSWindow* theWindow = (NSWindow*)mContext->GetWindow();
	NSView* contentView = NULL;
	if(theWindow){
		contentView = theWindow.contentView;
	}else{
		contentView = mContext->GetViewControl();
	}
	NSRect bounds = [macStuff->mPopupButton frame];
	bounds.origin.x = inLocation.x;
//folk of KvR, it's this next line..
	bounds.origin.y = contentView.bounds.size.height - inLocation.y;
//yes, that one just above
	[contentView addSubview:macStuff->mPopupButton];
	[contentView setNeedsDisplay:YES]; // needed
	[macStuff->mPopupButton setFrame:bounds];
	bounds = [macStuff->mPopupButton frame]; 

Now...

On all hosts /but/ Cubase, that subtraction is needed to get the popup to appear in the right place. With it there, all is well, apart from Cubase (version 7, to be exact, prior to this our Carbon implementation kicks in). However, to get Cubase looking as it should means removing the subtraction, which fouls up all the other hosts.

So... It strikes me that we must have /something/ wrong somewhere, I can't believe that hosts are using differing co-orinate systems; and anyway all other clicks are being interpreted properly/controls working/even the controls that the popups are attached to are getting the correct clicks.

What am I missing? I'm sure it's something very straightforward, but woods, trees..

[Bremmers]

I can't believe that hosts are using differing co-orinate systems

Hey, it's Apple

Have a look at NSView::isFlipped.

[duncanparsons]

oh, you're kidding.. I suppose with iOS, that would make some sense..

right, I'll check that out, thank you