Gray background behind app windows?
|
View:
New views
12 Messages
—
Rating Filter:
Alert me
|
 |
|
|
|
Re: Gray background behind app windows?
by Christiaan Hofman-2
::
Rate this Message:
On Sep 19, 2009, at 21:12, Duncan Champney wrote: > > On Sep 18, 2009, at 3:00 PM, macosx-dev-request@... wrote: > >> From: Duncan Champney <duncanc@...> >> Date: September 18, 2009 2:18:39 PM EDT >> To: macosx-dev@... >> Cc: Steve Sheets <ssheets@...> >> Subject: Gray background behind app windows? >> >> >> Folks, >> >> Apps like Photoshop (PS) used to have an option to blank out the >> desktop behind their windows to a flat gray. That reduced visual >> clutter so artists could focus on the app's windows. >> >> I have Photoshop CS3, not CS4 (I tend to update every other time to >> try to save a little money) so I don't know how it works in CS4, >> but in CS3 under Leopard, it looks like PS turns the document >> window into a "super window" that fills the whole screen and has >> gray borders all the way around. >> >> Our company is working on rewriting a legacy OS 7/8/9/ app for OS X >> (>= 10.5), and the legacy app has the option to blank out >> everything behind the app's windows to dull gray. >> >> Does anybody know a way to do this in OS X without either going to >> full-screen mode (and losing Cocoa's support for document windows, >> tool palettes, etc.) or turning the front document into a monster >> that takes up the whole screen, with the content placed in a >> resizeable view in the middle? That's doable, but less elegant than >> the gray background old OS 9 apps used to use, and doesn't allow >> the user to see more than one document window at a time. >> >> >> >> Thanks in advance, >> >> Duncan C >> WareTo LLC >> >> >> >> >> >> >> >> From: Kyle Sluder <kyle.sluder@...> >> Date: September 18, 2009 2:56:29 PM EDT >> To: Duncan Champney <duncanc@...> >> Cc: macosx-dev@..., Steve Sheets <ssheets@...> >> Subject: Re: Gray background behind app windows? >> >> >> On Fri, Sep 18, 2009 at 11:18 AM, Duncan Champney <duncanc@...> >> wrote: >>> Does anybody know a way to do this in OS X without either going to >>> full-screen mode (and losing Cocoa's support for document windows, >>> tool >>> palettes, etc.) or turning the front document into a monster that >>> takes up >>> the whole screen, with the content placed in a resizeable view in >>> the >>> middle? That's doable, but less elegant than the gray background >>> old OS 9 >>> apps used to use, and doesn't allow the user to see more than one >>> document >>> window at a time. >> >> Create a screen-sized NSWindow and set its level using -[NSWindow >> setLevel:]. >> >> --Kyle Sluder >> >> > > > Kyle, > > What level should I use? I would want the gray window to be behind > all of my app's other windows, but in front of other apps and in > front of the desktop. I could not find a level value for setLevel > that would do what I needed. I tried most of the different available > level settings, but no luck. First of all: just think. Most windows are at NSNormalWindowLevel, and utility windows etc are at NSFloatingWindowLevel. So it should be obvious that you can't just get what you want by simply setting the window level of the gray background window. You should move both this window and all your apps window to a higher level, at least higher than NSFloatingWindowLevel. But you have to be careful about that. Certainly it's a bad idea to move anything higher than the Force Quit window (which IIRC is usually placed at NScreensaverWindowLevel, though this is buggy on 10.5.x). There is no clear cut answer, it really depends on how important it is which other windows should be covered. It is not necessarily true that it MUST cover all other app's windows. Remember, you're not a screen dictator, users may find it very rude when you completely prevent other apps from becoming visible. In most situation in fact the best is to simply use NSNormalWindowLevel, but then you probably want to make sure all your apps windows are moved to the front when your app becomes active. > > Right now I am working on creating a screen-sized window with > styleMask: NSBorderlessWindowMask, at the default level for my app, > then using -orderBack to put it behind my other app windows. > > The problem with that is that if I click on the gray window, the > system brings it in front of my other app windows. I tried > overriding NSWindow's -mouseDown method and having that method do > nothing, but the system still brings the gray window to the front. > > How would I get the system to ignore mousedowns in the window so it > does not get moved to the front? > > > Duncan You probably want to override canBecomeKeyWindow and canBecomeMainWindow to return NO, and you may also want to use setIgnoresMouseEvents:. Christiaan _______________________________________________ MacOSX-dev mailing list MacOSX-dev@... http://www.omnigroup.com/mailman/listinfo/macosx-dev |
|
|
Re: Gray background behind app windows?
by Kevin Reid-2
::
Rate this Message:
On Sep 19, 2009, at 15:57, Christiaan Hofman wrote:
>> How would I get the system to ignore mousedowns in the window so it >> does not get moved to the front? > You probably want to override canBecomeKeyWindow and > canBecomeMainWindow to return NO, and you may also want to use > setIgnoresMouseEvents:. It's been a long time since I did this, but I believe that borderless windows cannot become key or main by default -- you have to override if you want them to. I don't know the details for preventing a window from being brought to the front, but note that for the purpose, clicks should not pass *through* it but be stopped by it. Also, don't forget to think about the proper behavior in a multiple- monitor system. -- Kevin Reid <http://switchb.org/kpreid/> _______________________________________________ MacOSX-dev mailing list MacOSX-dev@... http://www.omnigroup.com/mailman/listinfo/macosx-dev |
|
|
RE: Gray background behind app windows?
by Duncan Champney
::
Rate this Message:
Begin forwarded message: > From: Christiaan Hofman <cmhofman@...> > Date: September 19, 2009 3:57:42 PM EDT > To: Duncan Champney <duncanc@...> > Cc: macosx-dev@... > Subject: Re: Gray background behind app windows? > > > On Sep 19, 2009, at 21:12, Duncan Champney wrote: > >> >> On Sep 18, 2009, at 3:00 PM, macosx-dev-request@... wrote: >> >>> From: Duncan Champney <duncanc@...> >>> Date: September 18, 2009 2:18:39 PM EDT >>> To: macosx-dev@... >>> Cc: Steve Sheets <ssheets@...> >>> Subject: Gray background behind app windows? >>> >>> >>> Folks, >>> >>> Apps like Photoshop (PS) used to have an option to blank out the >>> desktop behind their windows to a flat gray. That reduced visual >>> clutter so artists could focus on the app's windows. >>> >>> I have Photoshop CS3, not CS4 (I tend to update every other time >>> to try to save a little money) so I don't know how it works in >>> CS4, but in CS3 under Leopard, it looks like PS turns the document >>> window into a "super window" that fills the whole screen and has >>> gray borders all the way around. >>> >>> Our company is working on rewriting a legacy OS 7/8/9/ app for OS >>> X (>= 10.5), and the legacy app has the option to blank out >>> everything behind the app's windows to dull gray. >>> >>> Does anybody know a way to do this in OS X without either going to >>> full-screen mode (and losing Cocoa's support for document windows, >>> tool palettes, etc.) or turning the front document into a monster >>> that takes up the whole screen, with the content placed in a >>> resizeable view in the middle? That's doable, but less elegant >>> than the gray background old OS 9 apps used to use, and doesn't >>> allow the user to see more than one document window at a time. >>> >>> >>> >>> Thanks in advance, >>> >>> Duncan C >>> WareTo LLC >>> >>> >>> >>> >>> >>> >>> >>> From: Kyle Sluder <kyle.sluder@...> >>> Date: September 18, 2009 2:56:29 PM EDT >>> To: Duncan Champney <duncanc@...> >>> Cc: macosx-dev@..., Steve Sheets <ssheets@...> >>> Subject: Re: Gray background behind app windows? >>> >>> >>> On Fri, Sep 18, 2009 at 11:18 AM, Duncan Champney >>> <duncanc@...> wrote: >>>> Does anybody know a way to do this in OS X without either going to >>>> full-screen mode (and losing Cocoa's support for document >>>> windows, tool >>>> palettes, etc.) or turning the front document into a monster >>>> that takes up >>>> the whole screen, with the content placed in a resizeable view in >>>> the >>>> middle? That's doable, but less elegant than the gray background >>>> old OS 9 >>>> apps used to use, and doesn't allow the user to see more than one >>>> document >>>> window at a time. >>> >>> Create a screen-sized NSWindow and set its level using -[NSWindow >>> setLevel:]. >>> >>> --Kyle Sluder >>> >>> >> >> >> Kyle, >> >> What level should I use? I would want the gray window to be behind >> all of my app's other windows, but in front of other apps and in >> front of the desktop. I could not find a level value for setLevel >> that would do what I needed. I tried most of the different >> available level settings, but no luck. > > First of all: just think. Most windows are at NSNormalWindowLevel, > and utility windows etc are at NSFloatingWindowLevel. So it should > be obvious that you can't just get what you want by simply setting > the window level of the gray background window. You should move both > this window and all your apps window to a higher level, at least > higher than NSFloatingWindowLevel. > > But you have to be careful about that. Certainly it's a bad idea to > move anything higher than the Force Quit window (which IIRC is > usually placed at NScreensaverWindowLevel, though this is buggy on > 10.5.x). > > There is no clear cut answer, it really depends on how important it > is which other windows should be covered. It is not necessarily true > that it MUST cover all other app's windows. Remember, you're not a > screen dictator, users may find it very rude when you completely > prevent other apps from becoming visible. In most situation in fact > the best is to simply use NSNormalWindowLevel, but then you probably > want to make sure all your apps windows are moved to the front when > your app becomes active. > >> >> Right now I am working on creating a screen-sized window with >> styleMask: NSBorderlessWindowMask, at the default level for my app, >> then using -orderBack to put it behind my other app windows. >> >> The problem with that is that if I click on the gray window, the >> system brings it in front of my other app windows. I tried >> overriding NSWindow's -mouseDown method and having that method do >> nothing, but the system still brings the gray window to the front. >> >> How would I get the system to ignore mousedowns in the window so it >> does not get moved to the front? >> >> >> Duncan > > You probably want to override canBecomeKeyWindow and > canBecomeMainWindow to return NO, and you may also want to use > setIgnoresMouseEvents:. > > Christiaan > Christiaan, Thanks for your suggestions. I didn't know much about window levels until somebody else suggested using that approach. After reading about setLevel and experimenting with it, I concluded that it wasn't going to do what I needed without doing something like you suggested, raising the level of all my app's windows. That seems like it is too likely to cause unwanted side- effects. I really want my gray window to be at the normal window level, but always be the LAST window at that level. If I could place it using orderLast, then get it to swallow mouse events, I should get exactly the effect I am after. I am creating the window as styleMask: NSBorderlessWindowMask, which causes the window to not have a title bar. According to the documentation on canBecomeKeyWindow and canBecomeMainWindow, the default version of those methods returns false for windows that don't have a title bar. I just tried using setIgnoresMouseEvents: TRUE. It keeps the window from responding to mouse events, but it causes it to become transparent to mouse events. If I click on the gray area, the mouse click passes through my app and brings up whatever other app is hidden behind my gray window. I would have thought that implementing a do-nothing mouseDown method for my custom window sub-class would do the trick. It looks like the system is handling the click first, doing window ordering, and THEN passing the event to my window. I need some way to tell the system not to bring my window to the front when the user clicks on it. Regards, Duncan WareTo _______________________________________________ MacOSX-dev mailing list MacOSX-dev@... http://www.omnigroup.com/mailman/listinfo/macosx-dev |
|
|
|
|
|
Re: Gray background behind app windows?
by Kyle Sluder-2
::
Rate this Message:
I was under the assumption that you were doing this for the same
reason Photoshop is: to protect the user's vision from interference from other windows, without requiring the user to hide/quit those apps. Photoshop has a very gray UI because using colors while doing color correction ruins your eyes' color perception. You should be able to create a borderless window at level X, have all your document windows live at level X+1, and your panels live at the normal level. --Kyle Sluder _______________________________________________ MacOSX-dev mailing list MacOSX-dev@... http://www.omnigroup.com/mailman/listinfo/macosx-dev |
|
|
Question about Core Data Inverse Relationships
by Bennett Smith-2
::
Rate this Message:
Hello
I am stuck on a problem that I just can't figure out. I am very new to Core Data so it might just be that I am going about this wrong. I want to setup a model for something like this: The currentAttributes and oldAttributes relationships in User are configured as "to-many relationships." My problem is in figuring out how to set an inverse relationship in the Attribute class. It seems like I cannot have an inverse relationship that points back to User for all Attribute entities in this case. (At least I can't figure out how to do it in Xcode.) The purpose for this model is to allow me to track a set of attributes associated with a user and to keep track of any changes in the attribute values over time. A change is defined as replacing the value associated with the attribute or deleting an attribute. I am open to other suggestions on how to achieve this goal using Core Data. Thanks -- Bennett _______________________________________________ MacOSX-dev mailing list MacOSX-dev@... http://www.omnigroup.com/mailman/listinfo/macosx-dev |
|
|
Re: Question about Core Data Inverse Relationships
by Bennett Smith-2
::
Rate this Message:
Forgot to attach the diagram:
On Sep 19, 2009, at 9:09 PM, Bennett Smith wrote: > Hello > > I am stuck on a problem that I just can't figure out. I am very new > to Core Data so it might just be that I am going about this wrong. I > want to setup a model for something like this: > > > The currentAttributes and oldAttributes relationships in User are > configured as "to-many relationships." My problem is in figuring out > how to set an inverse relationship in the Attribute class. It seems > like I cannot have an inverse relationship that points back to User > for all Attribute entities in this case. (At least I can't figure > out how to do it in Xcode.) > > The purpose for this model is to allow me to track a set of > attributes associated with a user and to keep track of any changes > in the attribute values over time. A change is defined as replacing > the value associated with the attribute or deleting an attribute. I > am open to other suggestions on how to achieve this goal using Core > Data. > > Thanks > > -- Bennett > _______________________________________________ > MacOSX-dev mailing list > MacOSX-dev@... > http://www.omnigroup.com/mailman/listinfo/macosx-dev _______________________________________________ MacOSX-dev mailing list MacOSX-dev@... http://www.omnigroup.com/mailman/listinfo/macosx-dev |
|
|
Re: Question about Core Data Inverse Relationships
by Bennett Smith-2
::
Rate this Message:
Well, I tried to attach the diagram, but guess the mailing list strips
it out. The jist of the diagram was that I have the following entities: User name currentAttributes (to-many relationship with Attribute) oldAttributes (to-many relationship with Attribute) Attribute dateRecorded name value user (relationship with User) The problem I'm having is with setting up the inverse relationship in the Attribute entity. I would to specify an inverse relationship for both currentAttributes and oldAttributes, but can't see how to do this. Many thanks, and sorry for the confusion about posting the diagram. Cheers -- Bennett On Sep 19, 2009, at 9:14 PM, Bennett Smith wrote: > Forgot to attach the diagram: > > > > On Sep 19, 2009, at 9:09 PM, Bennett Smith wrote: > >> Hello >> >> I am stuck on a problem that I just can't figure out. I am very >> new to Core Data so it might just be that I am going about this >> wrong. I want to setup a model for something like this: >> >> >> The currentAttributes and oldAttributes relationships in User are >> configured as "to-many relationships." My problem is in figuring >> out how to set an inverse relationship in the Attribute class. It >> seems like I cannot have an inverse relationship that points back >> to User for all Attribute entities in this case. (At least I can't >> figure out how to do it in Xcode.) >> >> The purpose for this model is to allow me to track a set of >> attributes associated with a user and to keep track of any changes >> in the attribute values over time. A change is defined as replacing >> the value associated with the attribute or deleting an attribute. I >> am open to other suggestions on how to achieve this goal using Core >> Data. >> >> Thanks >> >> -- Bennett >> _______________________________________________ >> MacOSX-dev mailing list >> MacOSX-dev@... >> http://www.omnigroup.com/mailman/listinfo/macosx-dev > > _______________________________________________ > MacOSX-dev mailing list > MacOSX-dev@... > http://www.omnigroup.com/mailman/listinfo/macosx-dev _______________________________________________ MacOSX-dev mailing list MacOSX-dev@... http://www.omnigroup.com/mailman/listinfo/macosx-dev |
|
|
Re: Question about Core Data Inverse Relationships
by Christiaan Hofman-2
::
Rate this Message:
On Sep 20, 2009, at 6:18, Bennett Smith wrote: > Well, I tried to attach the diagram, but guess the mailing list > strips it out. The jist of the diagram was that I have the > following entities: > > User > name > currentAttributes (to-many relationship with Attribute) > oldAttributes (to-many relationship with Attribute) > > Attribute > dateRecorded > name > value > user (relationship with User) > > The problem I'm having is with setting up the inverse relationship > in the Attribute entity. I would to specify an inverse relationship > for both currentAttributes and oldAttributes, but can't see how to > do this. > > Many thanks, and sorry for the confusion about posting the diagram. > > Cheers > > -- Bennett Plain logic tells you this is impossible. An attribute can be both an oldAttribute and a currentAttribute,so which user should be set in the user property? You should not have to ask this. So you'll have to change your model, and add another user relationship to use as the inverse of oldAttributes. Christiaan > > On Sep 19, 2009, at 9:14 PM, Bennett Smith wrote: > >> Forgot to attach the diagram: >> >> >> >> On Sep 19, 2009, at 9:09 PM, Bennett Smith wrote: >> >>> Hello >>> >>> I am stuck on a problem that I just can't figure out. I am very >>> new to Core Data so it might just be that I am going about this >>> wrong. I want to setup a model for something like this: >>> >>> >>> The currentAttributes and oldAttributes relationships in User are >>> configured as "to-many relationships." My problem is in figuring >>> out how to set an inverse relationship in the Attribute class. It >>> seems like I cannot have an inverse relationship that points back >>> to User for all Attribute entities in this case. (At least I can't >>> figure out how to do it in Xcode.) >>> >>> The purpose for this model is to allow me to track a set of >>> attributes associated with a user and to keep track of any changes >>> in the attribute values over time. A change is defined as >>> replacing the value associated with the attribute or deleting an >>> attribute. I am open to other suggestions on how to achieve this >>> goal using Core Data. >>> >>> Thanks >>> >>> -- Bennett >>> _______________________________________________ >>> MacOSX-dev mailing list >>> MacOSX-dev@... >>> http://www.omnigroup.com/mailman/listinfo/macosx-dev >> >> _______________________________________________ >> MacOSX-dev mailing list >> MacOSX-dev@... >> http://www.omnigroup.com/mailman/listinfo/macosx-dev > > _______________________________________________ > MacOSX-dev mailing list > MacOSX-dev@... > http://www.omnigroup.com/mailman/listinfo/macosx-dev _______________________________________________ MacOSX-dev mailing list MacOSX-dev@... http://www.omnigroup.com/mailman/listinfo/macosx-dev |
|
|
Re: Question about Core Data Inverse Relationships
by Bennett Smith-2
::
Rate this Message:
Well, I'm not sure plain logic would tell me this is impossible.
Clearly it is impossible using just a single relationship, but in many OO programs I have written there are objects that will live in different collections based on their current application state. This is precisely what the Attribute is in my problem. When a new Attribute begins life the process would be as follows in a pure OO implementation sense: 1. Locate any existing Attribute in the "currentAttributes" collection that matches the attribute name. 2. If an object was found in step 1 move it to the "oldAttributes" collection so we can keep around knowledge that is once existed. 3. Insert the new Attribute into the "currentAttributes" collection and set the dateRecorded date to "now". This seems completely reasonable in an application, but clearly there is more work to do before it can be translated into something Core Data is happy with. That is why I posted the question. Since Attribute contains the same attributes whether it is in "currentAttributes" or "oldAttributes" it seems kind of silly to maintain two relationships on every Attribute. If one choose to go this route how would one represent that either the relationship for "currentAttributesUser" or "oldAttributesUser" must always be nil since an attribute cannot be in both relationships at the same time? I was looking at the possibility of using a Core Data abstract entity as a "base class" for two different attribute types. I would put all of the shared attributes in the abstract entity and only have the relationships in the derived entities. I tried finding more information in the Core Data book by Marcus Zarra, but nothing immediately jumped out at me. Could someone familiar with the use of Abstract Entities in Core Data please comment on whether this approach is worth considering? Many thanks. -- Bennett One possibility On Sep 20, 2009, at 3:07 AM, Christiaan Hofman wrote: > > On Sep 20, 2009, at 6:18, Bennett Smith wrote: > >> Well, I tried to attach the diagram, but guess the mailing list >> strips it out. The jist of the diagram was that I have the >> following entities: >> >> User >> name >> currentAttributes (to-many relationship with Attribute) >> oldAttributes (to-many relationship with Attribute) >> >> Attribute >> dateRecorded >> name >> value >> user (relationship with User) >> >> The problem I'm having is with setting up the inverse relationship >> in the Attribute entity. I would to specify an inverse relationship >> for both currentAttributes and oldAttributes, but can't see how to >> do this. >> >> Many thanks, and sorry for the confusion about posting the diagram. >> >> Cheers >> >> -- Bennett > > Plain logic tells you this is impossible. An attribute can be both > an oldAttribute and a currentAttribute,so which user should be set > in the user property? You should not have to ask this. So you'll > have to change your model, and add another user relationship to use > as the inverse of oldAttributes. > > Christiaan > >> >> On Sep 19, 2009, at 9:14 PM, Bennett Smith wrote: >> >>> Forgot to attach the diagram: >>> >>> >>> >>> On Sep 19, 2009, at 9:09 PM, Bennett Smith wrote: >>> >>>> Hello >>>> >>>> I am stuck on a problem that I just can't figure out. I am very >>>> new to Core Data so it might just be that I am going about this >>>> wrong. I want to setup a model for something like this: >>>> >>>> >>>> The currentAttributes and oldAttributes relationships in User are >>>> configured as "to-many relationships." My problem is in figuring >>>> out how to set an inverse relationship in the Attribute class. It >>>> seems like I cannot have an inverse relationship that points back >>>> to User for all Attribute entities in this case. (At least I >>>> can't figure out how to do it in Xcode.) >>>> >>>> The purpose for this model is to allow me to track a set of >>>> attributes associated with a user and to keep track of any >>>> changes in the attribute values over time. A change is defined as >>>> replacing the value associated with the attribute or deleting an >>>> attribute. I am open to other suggestions on how to achieve this >>>> goal using Core Data. >>>> >>>> Thanks >>>> >>>> -- Bennett >>>> _______________________________________________ >>>> MacOSX-dev mailing list >>>> MacOSX-dev@... >>>> http://www.omnigroup.com/mailman/listinfo/macosx-dev >>> >>> _______________________________________________ >>> MacOSX-dev mailing list >>> MacOSX-dev@... >>> http://www.omnigroup.com/mailman/listinfo/macosx-dev >> >> _______________________________________________ >> MacOSX-dev mailing list >> MacOSX-dev@... >> http://www.omnigroup.com/mailman/listinfo/macosx-dev > _______________________________________________ MacOSX-dev mailing list MacOSX-dev@... http://www.omnigroup.com/mailman/listinfo/macosx-dev |
|
|
Re: Question about Core Data Inverse Relationships
by Christiaan Hofman-2
::
Rate this Message:
On Sep 20, 2009, at 16:58, Bennett Smith wrote: > Well, I'm not sure plain logic would tell me this is impossible. > Clearly it is impossible using just a single relationship, but in > many OO programs I have written there are objects that will live in > different collections based on their current application state. This > is precisely what the Attribute is in my problem. When a new > Attribute begins life the process would be as follows in a pure OO > implementation sense: > > 1. Locate any existing Attribute in the "currentAttributes" > collection that matches the attribute name. > 2. If an object was found in step 1 move it to the "oldAttributes" > collection so we can keep around knowledge that is once existed. > 3. Insert the new Attribute into the "currentAttributes" collection > and set the dateRecorded date to "now". > > This seems completely reasonable in an application, but clearly > there is more work to do before it can be translated into something > Core Data is happy with. That is why I posted the question. Reasonable? I really don't think so. This is a complex procedure, and I even had to read it twice to understand what you are saying. You sure should not expect CD to do that stuff for you automatically. I think that should be perfectly clear and logical. CD is not AI, it does not interpret any "old" or "current", let alone what that may mean in English. A relationship is just that: it's a relationship, and it's set or not. All CD can do is keep track of a PAIR of inverse relationships and set one when you set the other. If you want something like you say, you'll have to do it yourself in code. > Since Attribute contains the same attributes whether it is in > "currentAttributes" or "oldAttributes" it seems kind of silly to > maintain two relationships on every Attribute. If one choose to go > this route how would one represent that either the relationship for > "currentAttributesUser" or "oldAttributesUser" must always be nil > since an attribute cannot be in both relationships at the same time? When you remove an entity from a relationship, CD can remove it automatically from the reverse relationship. However what you want is apparently something very different: you want to remove an item from currentAttributes and add it to oldAttributes, based on some OTHER item being added to currentAttributes. That's something CD cannot do for you. That has nothing to do with inverse relationships, because currentAttributes and oldAttributes are in no way inverse. There's no relationship CD can know of between these relationships. > I was looking at the possibility of using a Core Data abstract > entity as a "base class" for two different attribute types. I would > put all of the shared attributes in the abstract entity and only > have the relationships in the derived entities. I tried finding more > information in the Core Data book by Marcus Zarra, but nothing > immediately jumped out at me. So what's the question here? You can just do that in the entity editor, just set the parent entity in the subentities and add the non- shared relationships and attributes. Christiaan > > Could someone familiar with the use of Abstract Entities in Core > Data please comment on whether this approach is worth considering? > > Many thanks. > > -- Bennett > > One possibility > On Sep 20, 2009, at 3:07 AM, Christiaan Hofman wrote: > >> >> On Sep 20, 2009, at 6:18, Bennett Smith wrote: >> >>> Well, I tried to attach the diagram, but guess the mailing list >>> strips it out. The jist of the diagram was that I have the >>> following entities: >>> >>> User >>> name >>> currentAttributes (to-many relationship with Attribute) >>> oldAttributes (to-many relationship with Attribute) >>> >>> Attribute >>> dateRecorded >>> name >>> value >>> user (relationship with User) >>> >>> The problem I'm having is with setting up the inverse relationship >>> in the Attribute entity. I would to specify an inverse >>> relationship for both currentAttributes and oldAttributes, but >>> can't see how to do this. >>> >>> Many thanks, and sorry for the confusion about posting the diagram. >>> >>> Cheers >>> >>> -- Bennett >> >> Plain logic tells you this is impossible. An attribute can be both >> an oldAttribute and a currentAttribute,so which user should be set >> in the user property? You should not have to ask this. So you'll >> have to change your model, and add another user relationship to use >> as the inverse of oldAttributes. >> >> Christiaan >> >>> >>> On Sep 19, 2009, at 9:14 PM, Bennett Smith wrote: >>> >>>> Forgot to attach the diagram: >>>> >>>> >>>> >>>> On Sep 19, 2009, at 9:09 PM, Bennett Smith wrote: >>>> >>>>> Hello >>>>> >>>>> I am stuck on a problem that I just can't figure out. I am very >>>>> new to Core Data so it might just be that I am going about this >>>>> wrong. I want to setup a model for something like this: >>>>> >>>>> >>>>> The currentAttributes and oldAttributes relationships in User >>>>> are configured as "to-many relationships." My problem is in >>>>> figuring out how to set an inverse relationship in the Attribute >>>>> class. It seems like I cannot have an inverse relationship that >>>>> points back to User for all Attribute entities in this case. (At >>>>> least I can't figure out how to do it in Xcode.) >>>>> >>>>> The purpose for this model is to allow me to track a set of >>>>> attributes associated with a user and to keep track of any >>>>> changes in the attribute values over time. A change is defined >>>>> as replacing the value associated with the attribute or deleting >>>>> an attribute. I am open to other suggestions on how to achieve >>>>> this goal using Core Data. >>>>> >>>>> Thanks >>>>> >>>>> -- Bennett >>>>> _______________________________________________ >>>>> MacOSX-dev mailing list >>>>> MacOSX-dev@... >>>>> http://www.omnigroup.com/mailman/listinfo/macosx-dev >>>> >>>> _______________________________________________ >>>> MacOSX-dev mailing list >>>> MacOSX-dev@... >>>> http://www.omnigroup.com/mailman/listinfo/macosx-dev >>> >>> _______________________________________________ >>> MacOSX-dev mailing list >>> MacOSX-dev@... >>> http://www.omnigroup.com/mailman/listinfo/macosx-dev >> > _______________________________________________ MacOSX-dev mailing list MacOSX-dev@... http://www.omnigroup.com/mailman/listinfo/macosx-dev |
| Free embeddable forum powered by Nabble | Forum Help |
