Accessing members from NSDictionary
I have a situation where a user might have a great many information windows
open at the same time (like the situation in Finder where you can click on a
file and select 'Get Info' ad infinitum.)
In order handle this situation, and so that I can still update each Window
individually, I decided to store the information window classes in an
NSDictionary so that I can fiddle with them individually (and release them
individually, obviously).
This seems to work quite well - except that I can't seem to access public
member variables. The following code gives the error 'No member named
'infoWindow' in 'struct objc_object'
NSEnumerator *e = [connectedDevices objectEnumerator];
id device;
while (device = [e nextObject])
{
if ([[device objectForKey:@LocationID] isEqualToNumber:[sender
representedObject]])
{
[device setObject:[[DisplayInformation alloc]
initWithDictionary:device] forKey:@InformationWindowRef];
[[device objectForKey:@InformationWindowRef] showWindow:self];
Error Here ---[[device objectForKey:@InformationWindowRef]-infoWindow
cascadeTopLeftFromPoint:NSMakePoint(20,20)];
}
}
So I have a few questions:
1. Am I approaching this problem correctly? After all, just because something
(mostly) works, it doesn't mean that it is the right, or efficient, way to do
things.
2. If my plan isn't utter lunacy, how do I get to the member variable?
3. If my plan is lunacy, or if there's a better more efficient solution, what
is it?
___
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: Accessing members from NSDictionary
On 5 Apr 2013, at 13:38, Pax wrote:
I have a situation where a user might have a great many information windows
open at the same time (like the situation in Finder where you can click on a
file and select 'Get Info' ad infinitum.)
In order handle this situation, and so that I can still update each Window
individually, I decided to store the information window classes in an
NSDictionary so that I can fiddle with them individually (and release them
individually, obviously).
This seems to work quite well - except that I can't seem to access public
member variables. The following code gives the error 'No member named
'infoWindow' in 'struct objc_object'
NSEnumerator *e = [connectedDevices objectEnumerator];
id device;
while (device = [e nextObject])
{
if ([[device objectForKey:@LocationID] isEqualToNumber:[sender
representedObject]])
{
[device setObject:[[DisplayInformation alloc]
initWithDictionary:device] forKey:@InformationWindowRef];
[[device objectForKey:@InformationWindowRef] showWindow:self];
Error Here ---[[device objectForKey:@InformationWindowRef]-infoWindow
cascadeTopLeftFromPoint:NSMakePoint(20,20)];
}
}
So I have a few questions:
1. Am I approaching this problem correctly? After all, just because
something (mostly) works, it doesn't mean that it is the right, or efficient,
way to do things.
2. If my plan isn't utter lunacy, how do I get to the member variable?
3. If my plan is lunacy, or if there's a better more efficient solution, what
is it?
For a start, trying to access instance variables directly is almost always a
bad idea. Expose proper accessor methods instead.
___
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: Accessing members from NSDictionary
On 5 Apr 2013, at 14:20, Mike Abdullah cocoa...@mikeabdullah.net wrote: For a start, trying to access instance variables directly is almost always a bad idea. Expose proper accessor methods instead. Why is it a bad idea? I do this quite often, and I find it has the double benefit of improving readability and reducing the number of lines of code. But if it's bad then I shall look to mend my ways - but I'll need to understand the badness first! ___ 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: Accessing members from NSDictionary
On 5 Apr 2013, at 14:55, Pax 45rpmli...@googlemail.com wrote:
On 5 Apr 2013, at 14:20, Mike Abdullah cocoa...@mikeabdullah.net wrote:
For a start, trying to access instance variables directly is almost always a
bad idea. Expose proper accessor methods instead.
Why is it a bad idea? I do this quite often, and I find it has the double
benefit of improving readability and reducing the number of lines of code.
But if it's bad then I shall look to mend my ways - but I'll need to
understand the badness first!
The reason it's a bad idea is because it means that you have two strongly
coupled components of code. You can not change the implementation of the class
with the ivar, without also changing the implementation of the other class now.
I don't really understand your argument about lines of code or readability, you
would be replacing
someObject-someIvar = 56.9f;
with
someObject.someProperty = 56.9f;
and
{
float someIvar;
}
with
@property (assign, nonatomic) float someProperty;
So neither is really true.
Thanks
Tom Davie
___
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: Accessing members from NSDictionary
Ah, I see. I shall try that out. And, referring to my earlier question, would
I be able to:
[[device objectForKey:@InformationWindowRef].infoWindow
cascadeTopLeftFromPoint:NSMakePoint(20,20)];
On 5 Apr 2013, at 15:00, Tom Davie tom.da...@gmail.com wrote:
The reason it's a bad idea is because it means that you have two strongly
coupled components of code. You can not change the implementation of the
class with the ivar, without also changing the implementation of the other
class now.
I don't really understand your argument about lines of code or readability,
you would be replacing
someObject-someIvar = 56.9f;
with
someObject.someProperty = 56.9f;
and
{
float someIvar;
}
with
@property (assign, nonatomic) float someProperty;
So neither is really true.
Thanks
Tom Davie
___
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: Accessing members from NSDictionary
…And how would I make '@property (assign, nonatomic) NSWindow* iWindow;' an
IBOutlet so that I can hook it up to my window in interface builder?
On 5 Apr 2013, at 15:00, Tom Davie tom.da...@gmail.com wrote:
The reason it's a bad idea is because it means that you have two strongly
coupled components of code. You can not change the implementation of the
class with the ivar, without also changing the implementation of the other
class now.
I don't really understand your argument about lines of code or readability,
you would be replacing
someObject-someIvar = 56.9f;
with
someObject.someProperty = 56.9f;
and
{
float someIvar;
}
with
@property (assign, nonatomic) float someProperty;
So neither is really true.
Thanks
Tom Davie
___
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: Accessing members from NSDictionary
1) yes you could use the code you outlined to access the property
2) @property (assign, nonatomic) IBOutlet NSWindow *iWindow;
Note though to be careful about the assign tag there – you may well want that
to be a retain.
Thanks
Tom Davie
On 5 Apr 2013, at 15:06, Pax 45rpmli...@googlemail.com wrote:
…And how would I make '@property (assign, nonatomic) NSWindow* iWindow;' an
IBOutlet so that I can hook it up to my window in interface builder?
On 5 Apr 2013, at 15:00, Tom Davie tom.da...@gmail.com wrote:
The reason it's a bad idea is because it means that you have two strongly
coupled components of code. You can not change the implementation of the
class with the ivar, without also changing the implementation of the other
class now.
I don't really understand your argument about lines of code or readability,
you would be replacing
someObject-someIvar = 56.9f;
with
someObject.someProperty = 56.9f;
and
{
float someIvar;
}
with
@property (assign, nonatomic) float someProperty;
So neither is really true.
Thanks
Tom Davie
___
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: Accessing members from NSDictionary
I never retain IBOutlet properties. The view retains the object when it is
added, so also retaining the property would increase the retain count to 2.
I have not encountered a condition where I was required to access an
IBOutlet property after the view had been unloaded, so this approach has
worked well for me. My foggy memory tells me this is (or was) best
practice, but I'm just too lazy to look it up right now. YMMV.
Regards,
-jwd
// Joseph W. Dixon
On Fri, Apr 5, 2013 at 9:18 AM, Tom Davie tom.da...@gmail.com wrote:
1) yes you could use the code you outlined to access the property
2) @property (assign, nonatomic) IBOutlet NSWindow *iWindow;
Note though to be careful about the assign tag there – you may well want
that to be a retain.
Thanks
Tom Davie
On 5 Apr 2013, at 15:06, Pax 45rpmli...@googlemail.com wrote:
…And how would I make '@property (assign, nonatomic) NSWindow* iWindow;'
an IBOutlet so that I can hook it up to my window in interface builder?
On 5 Apr 2013, at 15:00, Tom Davie tom.da...@gmail.com wrote:
The reason it's a bad idea is because it means that you have two
strongly coupled components of code. You can not change the implementation
of the class with the ivar, without also changing the implementation of the
other class now.
I don't really understand your argument about lines of code or
readability, you would be replacing
someObject-someIvar = 56.9f;
with
someObject.someProperty = 56.9f;
and
{
float someIvar;
}
with
@property (assign, nonatomic) float someProperty;
So neither is really true.
Thanks
Tom Davie
___
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/spam%40dixondata.com
This email sent to s...@dixondata.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: Accessing members from NSDictionary
On 5 Apr 2013, at 16:54, Joseph Dixon s...@dixondata.com wrote: I never retain IBOutlet properties. The view retains the object when it is added, so also retaining the property would increase the retain count to 2. This assumes that the property you're talking about is a view, and that it's a subview of another view that's retained. The issue isn't quite as simple as never retain IBOutlets. Thanks Tom Davie ___ 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: Accessing members from NSDictionary
On Fri, Apr 5, 2013 at 10:55 AM, Tom Davie tom.da...@gmail.com wrote: This assumes that the property you're talking about is a view, and that it's a subview of another view that's retained. The issue isn't quite as simple as never retain IBOutlets. Tom, You are right, of course. Most issues cannot be covered by hard and fast rules, and I have no intention of creating doctrine. In my experience using assign/weak references to IBOutlet properties has worked well. Yes, my IBOutlets are always pointing to subviews that are retained. Perhaps that makes my code .. quaint. -jwd // Joseph W. Dixon ___ 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: Providing a Service without activating an app
Thanks, Uli! Indeed the thing to do is start with a regular Application project and tweak it. Quite simple once you know how. I wrote up what I learned here: http://www.notesfromandy.com/2013/04/05/writing-a-service-bundle/ And here's the service I wrote. It copies a selector to the clipboard when you select a method declaration or invocation: https://github.com/aglee/copyselector#readme --Andy On Apr 4, 2013, at 8:02 AM, Uli Kusterer witness.of.teacht...@gmx.net wrote: I wrote CodingService a while ago (http://the-void-software.com/codingservice/), and as far I can see from a quick glance at the sources, all a .service is, is a faceless background application (LSBackgroundOnly == true in Info.plist) where you change the suffix in the build settings from .app to .service. It has the same NSServices key in its plist as a regular application implementing services would have, an app delegate, a main xib that instantiates it, etc. Cheers, -- Uli Kusterer The Witnesses of TeachText are everywhere... http://www.zathras.de On Apr 2, 2013, at 10:43 PM, Kevin Callahan kc...@mac.com wrote: On Apr 2, 2013, at 11:03 AM, Andy Lee ag...@mac.com wrote: I'm writing an app that provides an NSService. Is there a way to have the app not activate when the service is invoked? Alternatively -- where can I find good docs and/or sample code for creating a standalone .service bundle? --Andy Hi Andy - I ran into this same problem. When Accessorizer first came out in 2002, it was just a standalone NSService, not an app. However, because it needed to grow into an app in order to have settings, options and other things, I converted it to an app. Besides, several developers actually wanted it to be an app so they could work within the app itself. I couldn't figure out how to keep it from being activated once a service was invoked. The solution I came up with is two-fold: 1) I inform my users to minimize Accessorizer to the dock. I also have a preference for minimizing to the dock upon launch. So, if a service is invoked, and if Accessorizer is not running, then Accessorizer will launch, minimize itself to the Dock, and perform the service. At least this keeps Accessorizer's interface from being brought to the front and blocking Xcode. However, Accessorizer, at this point in the process, is still the active app. To solve that: 2) I have preferences to activate the editor (Xcode or TextMate) after a Service or Accessorizer Action (Accessorizer uses just one Service invocation for 28 code gen actions that you can pick from a status bar menu or floating menu). The effect is that you never leave Xcode. This works in full screen mode as well. I have other preferences for auto-inserting the results into Xcode at the current insertion point. So, basically, my solution was to minimize my app, do the service work, then activate Xcode, then insert results. Maybe there's a better way? -Kevin ___ 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/kcall%40mac.com This email sent to kc...@mac.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/witness.of.teachtext%40gmx.net This email sent to witness.of.teacht...@gmx.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
cursorUpdate was called, but cursor was not updated
I have a custom button, which was added as a subview of a textview. And I
want the cursor to be changed to arrowCursor instead of the beam cursor
when hover on the button.
So I added tracking area. The cursorUpdate method was indeed called, but
the cursor was still the beam cursor. It seems the cursor was changed back
to beam cursor after cursorUpdate method was called.
Any ideas?
- (void)cursorUpdate:(NSEvent *)event {
[[NSCursor arrowCursor] set];
}
// myAddTrackingArea is called in awakeFromNib.
- (void)myAddTrackingArea {
[self myRemoveTrackingArea];
NSTrackingAreaOptions trackingOptions = NSTrackingCursorUpdate |
NSTrackingMouseEnteredAndExited | NSTrackingActiveInKeyWindow;
_trackingArea = [[NSTrackingArea alloc] initWithRect: [self bounds]
options: trackingOptions owner: self userInfo: nil];
[self addTrackingArea: _trackingArea];
}
- (void)myRemoveTrackingArea {
if (_trackingArea)
{
[self removeTrackingArea: _trackingArea];
_trackingArea = nil;
}
}
___
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: cursorUpdate was called, but cursor was not updated
On Apr 5, 2013, at 12:25:05, Peng Gu pan...@gmail.com wrote: I have a custom button, which was added as a subview of a textview. And I want the cursor to be changed to arrowCursor instead of the beam cursor when hover on the button. So I added tracking area. The cursorUpdate method was indeed called, but the cursor was still the beam cursor. It seems the cursor was changed back to beam cursor after cursorUpdate method was called. Any ideas? I had a similar problem, and the only solution I found was to keep track of whether or not the cursor was in the subview, then in the superview, check that state and NOT set the cursor there if it was true. So, if the superview is not one of your custom subclasses, you'd make it a subclass just so you can do that. Hopefully there's a better solution, because this one is very icky. -- Steve Mills Drummer, Mac geek ___ 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: Accessing members from NSDictionary
On Apr 5, 2013, at 7:03 AM, Pax 45rpmli...@googlemail.com wrote: Ah, I see. I shall try that out. And, referring to my earlier question, would I be able to: [[device objectForKey:@InformationWindowRef].infoWindow cascadeTopLeftFromPoint:NSMakePoint(20,20)]; No, because -objectForKey: returns type id, i.e. a generic untyped object reference, but “.” syntax is strongly typed so it requires that the left-hand-side be an actual class that defines that property. Your choices are: [[device objectForKey:@InformationWindowRef”] infoWindow] ... or InfoWindowRef *ref = [[device objectForKey:@InformationWindowRef”]; ref.infoWindow ... —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: Providing a Service without activating an app
.service was also designed to allow for dynamic services where an app could write out just the info.plist in a bundle.service and the NSServices key points to services offered by other apps. You could then have services created by apps using a single entry point with different user data to take different actions. *Unfortunately* the implementation in the last couple versions of OS X continues to have serious bugs with this. Unless you have an executable, both the Finder the Service menu handler put a not compatible executable badge on your icon. And as a bonus, since sandbox apps cannot write to ~/Library/Services/ without the user specifying it (and not being able to offer help pointing them to the invisible ~/Library folder)-- there is no easy way for apps to specify dynamic services in sandboxed apps. Btw.. the solution I used to prevent Services from bringing the app forward is to have a background (LSUIElement) helper app that acts as the NSServices provider. Depending on what you need to do, you could either support the service directly in the helper app or use it to talk to the parent app to perform the necessary work (without requiring it to activate). I use the second approach. Mark On Thu, Apr 4, 2013 at 5:02 AM, Uli Kusterer witness.of.teacht...@gmx.netwrote: I wrote CodingService a while ago ( http://the-void-software.com/codingservice/), and as far I can see from a quick glance at the sources, all a .service is, is a faceless background application (LSBackgroundOnly == true in Info.plist) where you change the suffix in the build settings from .app to .service. It has the same NSServices key in its plist as a regular application implementing services would have, an app delegate, a main xib that instantiates it, etc. Cheers, -- Uli Kusterer The Witnesses of TeachText are everywhere... http://www.zathras.de On Apr 2, 2013, at 10:43 PM, Kevin Callahan kc...@mac.com wrote: On Apr 2, 2013, at 11:03 AM, Andy Lee ag...@mac.com wrote: I'm writing an app that provides an NSService. Is there a way to have the app not activate when the service is invoked? Alternatively -- where can I find good docs and/or sample code for creating a standalone .service bundle? --Andy Hi Andy - I ran into this same problem. When Accessorizer first came out in 2002, it was just a standalone NSService, not an app. However, because it needed to grow into an app in order to have settings, options and other things, I converted it to an app. Besides, several developers actually wanted it to be an app so they could work within the app itself. I couldn't figure out how to keep it from being activated once a service was invoked. The solution I came up with is two-fold: 1) I inform my users to minimize Accessorizer to the dock. I also have a preference for minimizing to the dock upon launch. So, if a service is invoked, and if Accessorizer is not running, then Accessorizer will launch, minimize itself to the Dock, and perform the service. At least this keeps Accessorizer's interface from being brought to the front and blocking Xcode. However, Accessorizer, at this point in the process, is still the active app. To solve that: 2) I have preferences to activate the editor (Xcode or TextMate) after a Service or Accessorizer Action (Accessorizer uses just one Service invocation for 28 code gen actions that you can pick from a status bar menu or floating menu). The effect is that you never leave Xcode. This works in full screen mode as well. I have other preferences for auto-inserting the results into Xcode at the current insertion point. So, basically, my solution was to minimize my app, do the service work, then activate Xcode, then insert results. Maybe there's a better way? -Kevin ___ 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/kcall%40mac.com This email sent to kc...@mac.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/witness.of.teachtext%40gmx.net This email sent to witness.of.teacht...@gmx.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:
