Re: Sometimes all my menus are disabled

[Alastair Houghton]

On 14 Feb 2017, at 22:15, Graham Cox  wrote:
> 
>> On 15 Feb 2017, at 12:39 AM, Andreas Falkenhahn  
>> wrote:
>> 
>> I knew how to use IB on the old PowerPC Mac,
>> but that was 10 years ago.
> 
> Well, it hasn’t changed that much in principle. In fact it’s got a lot better 
> in most respects because it stays in sync with your code and is not a 
> separate app. Some things are worse though, like the pick list for UI 
> elements, which makes you do a lot of scrolling to get to the one you want.

Personally I preferred it as a separate app; the “staying in sync with your 
code” part wasn’t such a huge problem in practice and could probably have been 
fixed without integrating it (which, particularly because it went 
single-window, forces people to use Xcode as their editor).  I also liked 
having the separate window for the nib file structure - the side bar can get 
quite cluttered in more complicated nibs.

But I’m not going to turn this into a critique of Xcode design decisions.

> Now I'm trying to compile this old project on a
>> 10.12 system with the latest Xcode but somehow the project was messed up by
>> Xcode when converting it from the old format to the new one and now it 
>> shows weird issues.
> 
> So it messed up. That’s annoying, but should be fixable by spending half an 
> hour in IB to identify and fix the broken connectins (or whatever).

You will also need to check API behaviour.  Cocoa behaves quite differently in 
some places depending on the system version and Xcode version used to build 
code; I’m not sure if there’s a list of all of these places anywhere - it’d be 
quite useful for this kind of situation.  (Formatters in particular have rather 
different behaviour.)

When I first saw Apple doing this, I thought it was a good idea.  I now think 
otherwise.  It should have based behaviour changes on a separate API level 
setting, which would have meant Xcode could issue warnings when an API level 
stopped being supported so that you’d know what to focus on.  I know we’ve 
managed to ship bugs on a couple of occasions because of API behaviour changes 
that we didn’t appreciate or spot; thankfully these have tended to be cosmetic 
(e.g. percentages were being formatted incorrectly), but it’s still worth 
checking *everything*.

> Of course, I could just dump the old project and start a new one with the
>> latest Xcode, re-creating everything from scratch. But do you really think
>> that is a satisfactory solution?
> 
> It isn’t the ideal solution, but sometimes you are faced with hard choices.
> 
> One problem sounds like you’ve put a lot of interfaces into one nib file, so 
> that’s going to make life harder than necessary,

That isn’t a big problem in practice.  iDefrag and iPartition have quite a few 
things in a single main nib file that would probably be split out into multiple 
nibs in a more modern code base; I’ve had no reason to change that (they don’t 
use window controllers or view controllers, so it just isn’t a problem).

> and another is that you’ve gone against the usual conventions with menu 
> actions and targets, so that’s going to make life harder than necessary.

[snip]

> The obvious thing to me was to get into IB and start figuring out the 
> problem. Instead you ranted about how much of a time sink it was being 
> because IB was different and you’d forgotten how to use it. Not only that but 
> the way your project is organised is unconventional, to say the least. If you 
> prefer to swim upstream, you only have yourself to blame.

To be fair to Andreas, the stream has changed direction somewhat over the 
years, and I’d be lying if I said I’d never found updating projects to be 
compatible with the new version of Xcode I was forced to use because of OS 
compatibility issues was not an annoyance.

(Indeed, the last round of Xcode’s automatic project upgrades caused yet 
another problem, this time with code signing.)

Kind regards,

Alastair.

--
http://alastairs-place.net


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Are instances of a NSManagedObject subclass usable as regular objects?

[Jens Alfke]

> On Feb 14, 2017, at 3:16 PM, Daryle Walker  wrote:
> 
> How do I give managed objects enough permanence to be used with systems 
> expecting normal objects?

Managed objects are regular NSObjects and are ref-counted the same way. To keep 
one around, just use a regular strong reference.

—Jens
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: makeKeyAndOrderFront not working

[Ken Thomases]

On Feb 14, 2017, at 3:44 PM, James Walker  wrote:
> 
> I have a situation where makeKeyAndOrderFront is making a window visible but 
> not key.  Just before this call, [theWindow canBecomeKeyWindow] returns YES, 
> and just after, [NSApp keyWindow] returns nil.  Clicking on the window title 
> bar does not make it key.  However, if I bring some other app to the front 
> and then bring my app back to the front, the window in question finally does 
> become key.
> 
> When this problem occurs, [NSApp isActive] returns NO although my app's name 
> is in the menu bar, and doing [NSApp activateIgnoringOtherApps: YES] does not 
> rectify the situation.
> 
> This only happens if I have linked against a certain dylib that was built 
> with FireMonkey, not Xcode.  I haven't actually called any functions in said 
> dylib.  Any idea what nefarious things it might be doing?

It might provide categories on Cocoa classes that (inadvertently?) replace 
existing methods.  Alternatively, it might provide classes or categories which 
implement +load methods or it might use C++ static initializers or C/C++ 
__attribute__(constructor) functions.  Any of those can allow it to run stuff 
at load time whether you've explicitly called any functions or not.  Among the 
things such code could do is swizzle methods of Cocoa classes, changing their 
behavior.

Regards,
Ken


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Are instances of a NSManagedObject subclass usable as regular objects?

[Daryle Walker]

Looking at my code again, I had a massive brain-fart. I created all the data 
objects with local “let,” but forgot to assign the top-level object to my 
document’s data property.

Once I did that, the window doesn’t show up at all due to a different problem:

> 2017-02-14 18:43:00.018210 XNW[13100:1621112] Cannot create NSArray from 
> object Relationship 'header' on managed object (0x60885460) 
>  (entity: Message; id: 
> 0x60031300  
> ; data: {
> body = "Is this an accurate test?";
> header = (
> "0x600312a0 
> ",
> "0x60031140 
> "
> );
> }) with objects {(
>  (entity: HeaderField; 
> id: 0x600312a0 
>  ; data: {
> body = World;
> message = "0x60031300 
> ";
> name = Hi;
> }),
>  (entity: HeaderField; 
> id: 0x60031140 
>  ; data: {
> body = planet;
> message = "0x60031300 
> ";
> name = Bye;
> })
> )} of class _NSFaultingMutableOrderedSet

This error came up twice on app start. It came up once more when I tried 
clicking on the app icon.

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

> On Feb 14, 2017, at 6:16 PM, Daryle Walker  wrote:
> 
> I’m on macOS Sierra, running Swift 3 on Xcode 8.
> 
> I started the basic document-based project, with storyboards but without Core 
> Data. The main window has a table view and a text view. I connected them to 
> my document’s data object with Cocoa Bindings. I put in sample data into the 
> object and the window shows said data when run.
> 
> Now I want to switch to Core Data. I made a framework with the data model 
> file and the NSMangedObject subclasses (with slight tweaks). Usually, the 
> developer would use all the whiz-bang features of Bindings, CD fetches, 
> object controllers, and array controllers with the window. But I want the 
> Core Data change and the window change to be separate Git commits. So I just 
> replaced the name of my old data classes with my NSMangedObject subclasses.
> 
> The views come up blank when run. During “makeWindowControllers,” I print out 
> my top level data object, which is now of type “MyMangedObjectSubclass!”. I 
> crash with a NIL-dereference error. I guess it’s somebody’s fault (pun 
> totally intended). How do I give managed objects enough permanence to be used 
> with systems expecting normal objects?
> 
> [I’m at the stage where I know just enough to be dangerous, but not enough to 
> know what I’m actually doing.]

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Are instances of a NSManagedObject subclass usable as regular objects?

[Daryle Walker]

I’m on macOS Sierra, running Swift 3 on Xcode 8.

I started the basic document-based project, with storyboards but without Core 
Data. The main window has a table view and a text view. I connected them to my 
document’s data object with Cocoa Bindings. I put in sample data into the 
object and the window shows said data when run.

Now I want to switch to Core Data. I made a framework with the data model file 
and the NSMangedObject subclasses (with slight tweaks). Usually, the developer 
would use all the whiz-bang features of Bindings, CD fetches, object 
controllers, and array controllers with the window. But I want the Core Data 
change and the window change to be separate Git commits. So I just replaced the 
name of my old data classes with my NSMangedObject subclasses.

The views come up blank when run. During “makeWindowControllers,” I print out 
my top level data object, which is now of type “MyMangedObjectSubclass!”. I 
crash with a NIL-dereference error. I guess it’s somebody’s fault (pun totally 
intended). How do I give managed objects enough permanence to be used with 
systems expecting normal objects?

[I’m at the stage where I know just enough to be dangerous, but not enough to 
know what I’m actually doing.]

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Sometimes all my menus are disabled

[Graham Cox]

> On 15 Feb 2017, at 12:39 AM, Andreas Falkenhahn  
> wrote:
> 
> I knew how to use IB on the old PowerPC Mac,
> but that was 10 years ago.

Well, it hasn’t changed that much in principle. In fact it’s got a lot better 
in most respects because it stays in sync with your code and is not a separate 
app. Some things are worse though, like the pick list for UI elements, which 
makes you do a lot of scrolling to get to the one you want.


> Now I'm trying to compile this old project on a
> 10.12 system with the latest Xcode but somehow the project was messed up by
> Xcode when converting it from the old format to the new one and now it 
> shows weird issues.

So it messed up. That’s annoying, but should be fixable by spending half an 
hour in IB to identify and fix the broken connectins (or whatever).

> Of course, I could just dump the old project and start a new one with the
> latest Xcode, re-creating everything from scratch. But do you really think
> that is a satisfactory solution?

It isn’t the ideal solution, but sometimes you are faced with hard choices.

One problem sounds like you’ve put a lot of interfaces into one nib file, so 
that’s going to make life harder than necessary, and another is that you’ve 
gone against the usual conventions with menu actions and targets, so that’s 
going to make life harder than necessary.

It’s usually easier to float downstream.

> ...several more experienced people have had a look at the project and although
> it is really minimal, nobody (!) has been able to solve the issue.

That doesn’t seem to be the case, judging by ’s answer...

> Instead,
> it was suggested that this might even be a bug in Xcode or Mac OS. So it's not
> a matter of not knowing how to use Xcode but rather a matter of something
> being buggy.

Sure, it could be. Bugs happen. XCode bugs happen a lot.


> 
> Thanks for your effort but before jumping to quick conclusions next time
> you should probably just read all mails on the matter first, no offense! :-)


I did read all the mails.

The obvious thing to me was to get into IB and start figuring out the problem. 
Instead you ranted about how much of a time sink it was being because IB was 
different and you’d forgotten how to use it. Not only that but the way your 
project is organised is unconventional, to say the least. If you prefer to swim 
upstream, you only have yourself to blame.

No offence (and none taken). Good luck!

—Graham




___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

makeKeyAndOrderFront not working

[James Walker]

I have a situation where makeKeyAndOrderFront is making a window visible 
but not key.  Just before this call, [theWindow canBecomeKeyWindow] 
returns YES, and just after, [NSApp keyWindow] returns nil.  Clicking on 
the window title bar does not make it key.  However, if I bring some 
other app to the front and then bring my app back to the front, the 
window in question finally does become key.


When this problem occurs, [NSApp isActive] returns NO although my app's 
name is in the menu bar, and doing [NSApp activateIgnoringOtherApps: 
YES] does not rectify the situation.


This only happens if I have linked against a certain dylib that was 
built with FireMonkey, not Xcode.  I haven't actually called any 
functions in said dylib.  Any idea what nefarious things it might be doing?

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: No prompt for Location Services

[Laurent Daudelin]

Yeah, that was it. Completely missed that one. Thanks Saagar.

-Laurent.
-- 
Laurent Daudelin
laur...@nemesys-soft.com 
AIM/iChat/Skype:LaurentDaudelin 
http://www.nemesys-soft.com/ 
Logiciels Nemesys Software

> On Feb 14, 2017, at 13:37, Saagar Jha  wrote:
> 
> You may have already done this, but you’ll need to call CLLocationManager’s 
> requestAlwaysAuthorization() method for the prompt.
> 
> Saagar Jha
> 
>> On Feb 14, 2017, at 10:01 AM, Laurent Daudelin > > wrote:
>> 
>> Adding features to an app under iOS 10 that needs to access the location 
>> services. So, I added the “NSLocationWhenInUseUsageDescription” with a 
>> description. When checking Privacy -> Location Services, I see my app there 
>> with 2 choices: “While using the app” and “Never”. But none is checked. I 
>> deleted the app from the device, re-installed but I’m never prompted to 
>> allow access to Location Services.
>> 
>> What am I missing?
>> 
>> -Laurent.
>> -- 
>> Laurent Daudelin 
>> laur...@nemesys-soft.com  
>> >
>> AIM/iChat/Skype:LaurentDaudelin   
>> http://www.nemesys-soft.com/  
>> >
>> Logiciels Nemesys Software
>> 
>> ___
>> 
>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com 
>> )
>> 
>> Please do not post admin requests or moderator comments to the list.
>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com 
>> 
>> 
>> Help/Unsubscribe/Update your Subscription:
>> https://lists.apple.com/mailman/options/cocoa-dev/saagar%40saagarjha.com 
>> 
>> 
>> This email sent to saa...@saagarjha.com
> 

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Table selection and bindings

[John Brownie]

OK, that makes sense. Tracing through, I do have a reloadData call, so 
I'll ensure that the selection gets maintained after that.


Yes, there is a mixture of data source and bindings, with the table view 
relying on data source and a bit of KVO, while the inspector relies on 
bindings. Things get rather messy with both the document window and the 
inspector panel having tabbed interfaces, meaning that I keep having to 
check which tab is active in order to activate the appropriate views. It 
may well be that I could do it all with bindings, but, with it all 
working (more or less), I don't want to break it. When I get that far in 
the Swift rewrite, then I can poke at it some more in the hope of making 
it cleaner.


Hopefully all will be well, so thanks for the pointers.

John

Quincey Morris 
14 February 2017 at 20:45

+1 what Keary said.

But there’s another question, which is why your selection is changing 
at all when you edit the object it represents. One possibility is that 
you’re invoking a reloadData on the table view when updating your 
model. If you do that, you must also re-establish the desired 
selection after the reload. Or, if you’re simply replacing the entire 
underlying array with a new instance that contains the modified 
object, the table view might treat that as a reload, depending on how 
your table view content is connected to your data model.


So, I think you are probably doing something “incorrectly”, in the 
sense that you need a lighter hand on the model update, or you need an 
extra step at the end of the update. Currently, it sounds like you are 
effectively but unintentionally clearing the selection 
programmatically, leading to the situation Keary describes.


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/john_brownie%40sil.org

This email sent to john_brow...@sil.org
Keary Suska 
14 February 2017 at 19:25

If you are otherwise getting delegate calls when you manually (i.e. 
NOT programmatically) change the selection, then you are running into 
the situations where notifications are not sent when programmatic 
selection changes are made. The only way around this is to watch 
directly for selection changes, which you may be able to accomplish 
either by observing selectedRowIndexes of NSTableView or 
selectionIndex(es) of an NSArrayController that the table view is bond to.


HTH,

Keary Suska
Esoteritech, Inc.
"Demystifying technology for your home or business"


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/john_brownie%40sil.org

This email sent to john_brow...@sil.org


--
John Brownie
In Finland on furlough from SIL Papua New Guinea
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Table selection and bindings

[Quincey Morris]

On Feb 14, 2017, at 09:25 , Keary Suska  wrote:
> 
>> On Feb 14, 2017, at 8:37 AM, John Brownie > > wrote:
>> 
>> Am I doing things incorrectly, or is there something that I can do to ensure 
>> that the change to the underlying array shown by the table triggers a 
>> selection change?
> 
> If you are otherwise getting delegate calls when you manually (i.e. NOT 
> programmatically) change the selection, then you are running into the 
> situations where notifications are not sent when programmatic selection 
> changes are made.

+1 what Keary said.

But there’s another question, which is why your selection is changing at all 
when you edit the object it represents. One possibility is that you’re invoking 
a reloadData on the table view when updating your model. If you do that, you 
must also re-establish the desired selection after the reload. Or, if you’re 
simply replacing the entire underlying array with a new instance that contains 
the modified object, the table view might treat that as a reload, depending on 
how your table view content is connected to your data model.

So, I think you are probably doing something “incorrectly”, in the sense that 
you need a lighter hand on the model update, or you need an extra step at the 
end of the update. Currently, it sounds like you are effectively but 
unintentionally clearing the selection programmatically, leading to the 
situation Keary describes.

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: No prompt for Location Services

[Saagar Jha]

You may have already done this, but you’ll need to call CLLocationManager’s 
requestAlwaysAuthorization() method for the prompt.

Saagar Jha

> On Feb 14, 2017, at 10:01 AM, Laurent Daudelin  
> wrote:
> 
> Adding features to an app under iOS 10 that needs to access the location 
> services. So, I added the “NSLocationWhenInUseUsageDescription” with a 
> description. When checking Privacy -> Location Services, I see my app there 
> with 2 choices: “While using the app” and “Never”. But none is checked. I 
> deleted the app from the device, re-installed but I’m never prompted to allow 
> access to Location Services.
> 
> What am I missing?
> 
> -Laurent.
> -- 
> Laurent Daudelin  
> laur...@nemesys-soft.com 
> AIM/iChat/Skype:LaurentDaudelin   
> http://www.nemesys-soft.com/ 
> Logiciels Nemesys Software
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/saagar%40saagarjha.com
> 
> This email sent to saa...@saagarjha.com

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Throwing an error from a NSDocument.init override

[Quincey Morris]

On Feb 14, 2017, at 00:26 , Daryle Walker  wrote:
> 
> But I can’t call the “super” versions of those other initializers from within 
> my override.

This is the essence of your problem. Your “override” cannot be a convenience 
initializer because convenience initializers cannot call “up” to the 
superclass, and it cannot be a designated initializer because designated 
initializers cannot call convenience initializers. For one solution, see here:


http://stackoverflow.com/questions/38908902/overwriting-nsdocuments-initcontentsofoftype-in-swift
 


Answering the same question in another way, look at the comments for 
init(type:) in the NSDocument header file:

> "Initialize a new empty document of a specified type, and return it if 
> successful. If not successful, return nil after setting *outError to an 
> NSError that encapsulates the reason why the document could not be 
> initialized. The default implementation of this method just invokes [self 
> init] and [self setFileType:typeName].”


This tells you exactly what the superclass convenience initializer does, and 
the fact that it’s in the header file makes the behavior a public API contract. 
So, you are allowed to implement your own subclass convenience initializer 
(that throws) which does *not* invoke super, but simply does what the super 
method is documented to do. (That’s basically the solution given on Stack 
Overflow.)
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

No prompt for Location Services

[Laurent Daudelin]

Adding features to an app under iOS 10 that needs to access the location 
services. So, I added the “NSLocationWhenInUseUsageDescription” with a 
description. When checking Privacy -> Location Services, I see my app there 
with 2 choices: “While using the app” and “Never”. But none is checked. I 
deleted the app from the device, re-installed but I’m never prompted to allow 
access to Location Services.

What am I missing?

-Laurent.
-- 
Laurent Daudelin
laur...@nemesys-soft.com 
AIM/iChat/Skype:LaurentDaudelin 
http://www.nemesys-soft.com/ 
Logiciels Nemesys Software

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Table selection and bindings

[Keary Suska]

> On Feb 14, 2017, at 8:37 AM, John Brownie  wrote:
> 
> I have an NSTableView in a document window, and a utility window which 
> functions as an inspector, so its content is bound to the selected object in 
> the table in the document window. Everything seems fine, but there is a place 
> which doesn't function as I expect.
> 
> In the inspector, I can change the display name of the object, which makes 
> the table drop its selection, so that nothing is selected any more. All OK, 
> but the tableViewSelectionDidChange: delegate method isn't called in this 
> instance. In a way, I can see that it's not the user changing the selection, 
> but the problem becomes that now the inspector is still pointed at an object, 
> but there's no selection, and the logic goes badly wrong.
> 
> Am I doing things incorrectly, or is there something that I can do to ensure 
> that the change to the underlying array shown by the table triggers a 
> selection change?

If you are otherwise getting delegate calls when you manually (i.e. NOT 
programmatically) change the selection, then you are running into the 
situations where notifications are not sent when programmatic selection changes 
are made. The only way around this is to watch directly for selection changes, 
which you may be able to accomplish either by observing selectedRowIndexes of 
NSTableView or selectionIndex(es) of an NSArrayController that the table view 
is bond to.

HTH,

Keary Suska
Esoteritech, Inc.
"Demystifying technology for your home or business"


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Table selection and bindings

[Steve Mills]

On Feb 14, 2017, at 09:38 AM, John Brownie  wrote:

I have an NSTableView in a document window, and a utility window which 
functions as an inspector, so its content is bound to the selected 
object in the table in the document window. Everything seems fine, but 
there is a place which doesn't function as I expect.


In the inspector, I can change the display name of the object, which 
makes the table drop its selection, so that nothing is selected any 
more. All OK, but the tableViewSelectionDidChange: delegate method isn't 
called in this instance. In a way, I can see that it's not the user 
changing the selection, but the problem becomes that now the inspector 
is still pointed at an object, but there's no selection, and the logic 
goes badly wrong.


Am I doing things incorrectly, or is there something that I can do to 
ensure that the change to the underlying array shown by the table 
triggers a selection change?


Do you have an NSArrayController in the mix somewhere? I think the usual way to hook this 
up is to bind to an NSArrayController, Controller Key "selection". It's kinda 
hard to offer much more help without knowing your exact setup. You mention using 
bindings, but also mention the tableViewSelectionDidChange method. Either you connect 
everything with bindings and it works automatically, or you look for changes via the 
delegate and reflect them in your inspector manually.

Sent from iCloud's ridiculous UI, so, sorry about the formatting

 
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Table selection and bindings

[John Brownie]

I have an NSTableView in a document window, and a utility window which 
functions as an inspector, so its content is bound to the selected 
object in the table in the document window. Everything seems fine, but 
there is a place which doesn't function as I expect.


In the inspector, I can change the display name of the object, which 
makes the table drop its selection, so that nothing is selected any 
more. All OK, but the tableViewSelectionDidChange: delegate method isn't 
called in this instance. In a way, I can see that it's not the user 
changing the selection, but the problem becomes that now the inspector 
is still pointed at an object, but there's no selection, and the logic 
goes badly wrong.


Am I doing things incorrectly, or is there something that I can do to 
ensure that the change to the underlying array shown by the table 
triggers a selection change?

--
John Brownie
In Finland on furlough from SIL Papua New Guinea
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Sometimes all my menus are disabled

[Andreas Falkenhahn]

On 14.02.2017 at 15:02 じょいすじょん wrote:

>> On Feb 14, 2017, at 1:58, Andreas Falkenhahn  wrote:

>> On 13.02.2017 at 17:33 じょいすじょん wrote:

>>> Yeah, my first suggestion didn't work, but points out the problem overall 
>>> in you nib.
>>> Looks like somebody did try to edit the xml before and munged it.

>> I certainly did not mess with the XML! Xcode must have messed this up when 
>> converting
>> the nib file from the old Xcode PowerPC project format to the new one. 

>>> You also have nested menu duplicates inside your menus in the nib file 
>>> itself!

>>> MainMenu
>>>Hollywood
>>>Menu
>>>About Hollywood
>>>Separator
>>>MainMenu (duplicated here as sub menu...)
>>>Preferences
>>>... (and on)


>>> Delete that other MainMenu inside and it seems to work thus far.

>> I've removed the complete duplicate MainMenu tree (the one after the 
>> separator
>> item, see above) from designable.nib using a text editor. However, it still
>> doesn't work. Same behaviour as before. 
> Strange, because after the changes I've suggested I am no longer able to get 
> any issues.

Hmm, interesting. Can you upload your project so that I can give it a try?

-- 
Best regards,
 Andreas Falkenhahnmailto:andr...@falkenhahn.com


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Sometimes all my menus are disabled

[じょいすじょん]

> On Feb 14, 2017, at 1:58, Andreas Falkenhahn  wrote:
> 
> On 13.02.2017 at 17:33 じょいすじょん wrote:
> 
>> Yeah, my first suggestion didn't work, but points out the problem overall in 
>> you nib.
>> Looks like somebody did try to edit the xml before and munged it.
> 
> I certainly did not mess with the XML! Xcode must have messed this up when 
> converting
> the nib file from the old Xcode PowerPC project format to the new one. 
> 
>> You also have nested menu duplicates inside your menus in the nib file 
>> itself!
> 
>> MainMenu
>>Hollywood
>>Menu
>>About Hollywood
>>Separator
>>MainMenu (duplicated here as sub menu...)
>>Preferences
>>... (and on)
> 
> 
>> Delete that other MainMenu inside and it seems to work thus far.
> 
> I've removed the complete duplicate MainMenu tree (the one after the separator
> item, see above) from designable.nib using a text editor. However, it still
> doesn't work. Same behaviour as before. 
Strange, because after the changes I've suggested I am no longer able to get 
any issues.
You really do just need to fix your nib. It's not that hard. If you're having 
trouble with modern Xcode, well, you have to pick it up.
IB has been pretty self similar for many years now.
Just spend the time doing fixing it.
It's not unreasonable to expect some project gets a little borked transitioning 
it from a 10 year old version of Xcode to a modern one. A LOT has changed since 
then.
 

> 
> 
> 
> This annoying issue is just another reason why I prefer doing things in code.
> This has already cost me hours over hours and it's still not solved. Even
> worse, there's a profound feeling of helplessness in the air. And re-creating
> everything from scratch is not an option! I certainly did not mess with the
> XML. Xcode must have messed this up when converting the project from the
> old format to the new one. All such things wouldn't be possible with code.
> Code could be cleanly adapted to new designs while nobody can tell what black
> magic is going on inside those arcane nib files. It's quite depressing. $0.02
> 
> 
> 
> -- 
> Best regards,
> Andreas Falkenhahnmailto:andr...@falkenhahn.com
> 


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Sometimes all my menus are disabled

[Andreas Falkenhahn]

On 13.02.2017 at 23:13 Graham Cox wrote:

> The problem here is that you seem unwilling to take a little time
> to learn the basics of Interface Builder. 

No, that's not the problem here. I knew how to use IB on the old PowerPC Mac,
but that was 10 years ago. Now I'm trying to compile this old project on a
10.12 system with the latest Xcode but somehow the project was messed up by
Xcode when converting it from the old format to the new one and now it 
shows weird issues.

Of course, I could just dump the old project and start a new one with the
latest Xcode, re-creating everything from scratch. But do you really think
that is a satisfactory solution? To me, this is a defeat because I'd have
to acknowledge that it's impossible to transition a project from an old
PowerPC Mac to the latest Xcode and I just refuse to believe that this
should be impossible. So the real problem here is to find out what's wrong
with this particular project which is not a matter of being "unwilling to
take a little time to learn the basics of Interface Builder" because...

> Don’t you think that would
> be time better spent than beating for hours on a problem that would
> take a developer experienced with IB a few minutes?

...several more experienced people have had a look at the project and although
it is really minimal, nobody (!) has been able to solve the issue. Instead,
it was suggested that this might even be a bug in Xcode or Mac OS. So it's not
a matter of not knowing how to use Xcode but rather a matter of something
being buggy.

> Someone has to point out the elephant in this particular room.

Thanks for your effort but before jumping to quick conclusions next time
you should probably just read all mails on the matter first, no offense! :-)

-- 
Best regards,
 Andreas Falkenhahnmailto:andr...@falkenhahn.com


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Throwing an error from a NSDocument.init override

[Daryle Walker]

The parameter-less version of “init” in NSDocument can’t throw. It’s suggesting 
to (save the error somehow and then) throw the error from one of the other 
initializers. This counts on the fact that you won’t initialize a NSDocument 
(subclass) instance with no parameters, but call one of the others, which calls 
“init()”.

But I can’t call the “super” versions of those other initializers from within 
my override. In fact, I can’t create overrides of them; the Swift compiler 
won’t auto-complete and insists that I mark them as “convenience” initializers. 
And I am limited to my “self.init()” call to start them up. Do I have to 
manually recreate the algorithm for each initializer overload(?)? Will 
NSDocumentController and other parts of the framework see my “overrides” of the 
standard NSDocument initializers and use them instead? Or should I just forget 
about throwing errors from “init()”? I could just call “fatalError” or similar 
instead.

(Oh, I got error objects because I’m initializing my (per-document) Core Data 
stack in “init()”.)

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com