Build breakage in tip

I just updated to the tip and there seems to be a build breakage (XCode 3, OS/X 10.5):

/development/rec/projects/slow/Builds/MacOSX/…/…/…/…/…/juce/modules/juce_gui_basics/native/juce_mac_Windowing.mm:325:0 /development/rec/projects/slow/Builds/MacOSX/…/…/…/…/…/juce/modules/juce_gui_basics/native/juce_mac_Windowing.mm:325: error: request for member ‘backingScaleFactor’ in ‘s’, which is of non-class type ‘NSScreen*’

If you try derefencing the variable s, there’s a new error:

/development/rec/projects/slow/Builds/MacOSX/…/…/…/…/…/juce/modules/juce_gui_basics/native/juce_mac_Windowing.mm:325:0 /development/rec/projects/slow/Builds/MacOSX/…/…/…/…/…/juce/modules/juce_gui_basics/native/juce_mac_Windowing.mm:325: error: ‘struct NSScreen’ has no member named ‘backingScaleFactor’

I’m replacing it with the constant 1.0 in my local copy for now (I unfortunately overwrote my good copy through inattention) and we’ll see how it goes.

It would be super cool if there was some server that compiled JUCE for all platforms every time Jules made a commit, and then reported the results to the #Juce IRC channel.

Looks like backingScaleFactor is 10.7 only.

When you say dereferencing s, do you mean actually dereferencing it (using * or -> operators) or messaging it (using . or [] operators). You should be able to message nil safely in objective-C, it should just return nil. So the respondsToSelector message below should just fail and the 1.0 be returned.

Does changing the line above to:

fix it? That should be the same as hard coding your 1.0 in. But saying that it shouldn’t be compiled with 10.5 anyway. What SDK are you using?

I’m on 10.6.

I meant “actually dereferencing it”.

Without even trying it :smiley: I can tell you that that line will fix it, because it’s functionally equivalent to what I have, which worked fine.

Thinking about it (I’m new to all these MAC_OSX macros) it should probably read:

Right, if your on 10.6 that explains the error message. You mentioned 10.5 in your original post which is what confused me.

I don’t think you can treat an objective-C object like you would a normal C/C++ pointer, you have to use the [] messaging operators or the . operator to access properties of the object. Using the standard * or -> indirect operators would probably treat it as a standard C/C++ object which is why you get the ‘struct’ error, the obj-C classes are probably laid out differently in memory.

URG, yes, I meant 10.6.

(We’re having an “issue” where our (third-party) copy protection doesn’t work on 10.5 so that’s in my thoughts…)

Doh! Sorry chaps, I always get those OSX macro statements wrong :oops: Fixed now.