[arcticmac]

I've got an app that I'm working on which uses a full screen, transparent window to draw on the desktop (essentially), and... yeah... anyway, the problem is that when the screen size is changed while the app is running, I need it to resize the window... unfortunately, this doesn't happen automatically, so I'm going to have to find a way to be notified when the screen size changes.

does anyone know how?

[smeger]

This should get you going. I think there's also a Carbon Event you can register for.

Code:
bool
InstallResolutionWatcher ()
{
	// get a procedure pointer for our display change notification
    DMExtendedNotificationUPP notificationUPP = NewDMExtendedNotificationUPP( ResolutionChanged );
    if ( ! notificationUPP ) 
    {
    	return false;
    }
    
    // register to receive notifications when the resolution changes
    ProcessSerialNumber currentProcess;
    OSStatus theErr = GetCurrentProcess( &currentProcess );
    if ( noErr == theErr )
    {
		theErr = DMRegisterExtendedNotifyProc ( notificationUPP, NULL, NULL, &currentProcess );
		if ( noErr == theErr )
		{
			return true;
		}
    }
    
    return false;
}


pascal void
ResolutionChanged
(void *userData,
 short theMessage,
 void *notifyData)
{    
    if (theMessage == kDMNotifyEvent || theMessage == kDMNotifyDisplayDidWake) 
    {
		//	NSLog(@"DEBUGGING:  Resolution changed");
    }
}

[arcticmac]

Sorry... forgot to mention I needed objective-c (and cocoa) fortunately, I found it anyway.

NSWindow has a method that it sends to its delage called windowDidChangeScreen: which seems to work pretty well for what I had in mind.

thanks anyway.

[Chuckit]

Originally posted by arcticmac:
Sorry... forgot to mention I needed objective-c (and cocoa)

That code does work in Objective-C.

[Angus_D]

Originally posted by arcticmac:
Sorry... forgot to mention I needed objective-c (and cocoa) fortunately, I found it anyway.

Uh, the code above was C. As Objective-C is a superset of C, it is by extension 100% valid Objective-C code.

Why are you arbitrarily tying yourself down to one framework? There is a whole wealth of functionality in OS X that is in other APIs, if you don't use them then you (and your users) will miss out.

[arcticmac]

Originally posted by Angus_D:
Uh, the code above was C. As Objective-C is a superset of C, it is by extension 100% valid Objective-C code.

Why are you arbitrarily tying yourself down to one framework? There is a whole wealth of functionality in OS X that is in other APIs, if you don't use them then you (and your users) will miss out.

of course c code works in objective-c. the problem is that I've learned objective-c, not c. for example, with the given code, I wouldn't know:
1. what the ***** is going on
2. do I have to import any other header files?
3. etc.

vs. objective-c (appkit) where I did 10 seconds of work in IB and added four or five lines of code, all of which I understand, and it works just fine.

Maybe some day I'll go more in depth with use of c and other APIs, but right now, cocoa seems to meet my needs fairly well, and I haven't seen any reason to use any others yet.

Is there something wrong with my approach? is it a lot slower or something?

[Chuckit]

Originally posted by arcticmac:
of course c code works in objective-c. the problem is that I've learned objective-c, not c.

You can't learn "Objective-C, not C." C is a subset of Objective-C. Therefore, if you don't know C, you don't know about 75% of Objective-C.

As for what's wrong with the NSWindow notification: maybe nothing. But I don't see it guaranteed anywhere that the notification will be sent when the resolution is changed, so it may not work in the future. Besides that, there is a lot of functionality not included in Cocoa. If you continue programming, there's a good chance you'll need to use another framework in the future. So it is good advice not to limit yourself unnecessarily.

[Angus_D]

Originally posted by arcticmac:
of course c code works in objective-c. the problem is that I've learned objective-c, not c. for example, with the given code, I wouldn't know:
1. what the ***** is going on
2. do I have to import any other header files?
3. etc.

If you don't know C then you can't be a very good Objective-C programmer, period.

There are C functions, structs, etc exposed by Cocoa. If you don't know how to call C functions and use structs, etc, you'll have trouble working with rects, ranges, and all kinds of other things.

[arcticmac]

If you don't know C then you can't be a very good Objective-C programmer, period.

There are C functions, structs, etc exposed by Cocoa. If you don't know how to call C functions and use structs, etc, you'll have trouble working with rects, ranges, and all kinds of other things.

of course... what I meant when I said that I haven't learned C is not that I have no clue how it works, but rather that all i've looked in to is a very basic understanding of it, including things like structs, enums, pointers, etc. I really haven't got any more of an in-depth understanding than that though.


On the other hand, I suspect that you guys are right and that I really should learn it (in more detail) eventually. The problem is that right now, i have no motivation to do so, and in any case I'm not sure where to begin.

[Rickster]

A better notification to watch:

Code:
- (void)applicationDidChangeScreenParameters:(NSNotification *)aNotification

It's an NSApplication delegate method, so see the NSApp docs for usage. (Seems a little odd it's not tied to NSScreen, but whatever.) It may be currently that -windowDidChangeScreen; happens to be called in the circumstances you're trying to monitor, but that's not guaranteed to always be the case. Subscribe to the notification that's actually documented to be called at the times you're looking for, and your software is more future-proof.

Angus_D and Chuckit are right about it being a bad thing to arbitrarily tie yourself down to Cocoa/ObjC APIs... but if there is one that does exactly what you need, there's no reason to bring in all sorts of messy Carbon gunk. Save your brain for when you need to do something that really is only available in C APIs, like Icon Services, deep CoreGraphics features, AppleEvent/OSA internals, et cetera.