[Q] NSObject's poseAsClass - Replacement?

  • I have a need to use poseAsClass, but I see that it has been
    deprecated in 10.5 and won't be available for 64-bit applications.

    So, is there a replacement?
  • On Mar 5, 2009, at 2:33 PM, Eric Gorr wrote:

    > I have a need to use poseAsClass, but I see that it has been
    > deprecated in 10.5 and won't be available for 64-bit applications.
    >
    > So, is there a replacement?

    Well, with a bit of searching I came up with what might be an option:

    http://theocacao.com/document.page/266
    http://www.cocoadev.com/index.pl?MethodSwizzling

    (I believe both sites describe the same technique.)

    Are there any other alternatives?
  • > I have a need to use poseAsClass, but I see that it has been deprecated
    > in 10.5 and won't be available for 64-bit applications.
    >
    > So, is there a replacement?

    WAYTTD: What are you trying to do? Maybe you don’t need to pose.

    -Ben
  • On Mar 5, 2009, at 2:47 PM, Benjamin Stiglitz wrote:

    >> I have a need to use poseAsClass, but I see that it has been
    >> deprecated
    >> in 10.5 and won't be available for 64-bit applications.
    >>
    >> So, is there a replacement?
    >
    > WAYTTD: What are you trying to do? Maybe you don’t need to pose.

    Well, sadly, I am pretty sure I do...at least for now.

    Although, this bug is not quite confirmed yet, but I suspect I know
    what the problem is.

    I am working on a Carbon -> Cocoa conversion. In the carbon part, the
    cursor is being set to a 64x64 cursor constantly - via NSCursor set.
    The problem comes when I move the cursor over a cocoa view which I
    believe, by default, changing the cursor to what it wants - which I
    believe is a 32x32 cursor.

    So, in the constantly fighting over what the cursor should be, there
    is some weird cursor behavior...it flickers - moves quickly to a
    nearby location and then back again.

    I figure I could write my own NSCursor subclass, pose it as the normal
    NSCursor class and make sure that it is always trying to set cursor in
    the same way in every situation.

    Yes, I know, this isn't a good situation any way you slice it...but I
    need a quick fix and poseAsClass: seems to be the best option -
    assuming the bug is what I think it is.
  • On Thu, Mar 5, 2009 at 3:00 PM, Eric Gorr <mailist...> wrote:
    >
    > On Mar 5, 2009, at 2:47 PM, Benjamin Stiglitz wrote:
    >
    >>> I have a need to use poseAsClass, but I see that it has been deprecated
    >>> in 10.5 and won't be available for 64-bit applications.
    >>>
    >>> So, is there a replacement?
    >>
    >> WAYTTD: What are you trying to do? Maybe you don’t need to pose.
    >
    > Well, sadly, I am pretty sure I do...at least for now.
    >
    > Although, this bug is not quite confirmed yet, but I suspect I know what the
    > problem is.
    >
    > I am working on a Carbon -> Cocoa conversion. In the carbon part, the cursor
    > is being set to a 64x64 cursor constantly - via NSCursor set. The problem
    > comes when I move the cursor over a cocoa view which I believe, by default,
    > changing the cursor to what it wants - which I believe is a 32x32 cursor.
    >
    > So, in the constantly fighting over what the cursor should be, there is some
    > weird cursor behavior...it flickers - moves quickly to a nearby location and
    > then back again.
    >
    > I figure I could write my own NSCursor subclass, pose it as the normal
    > NSCursor class and make sure that it is always trying to set cursor in the
    > same way in every situation.
    >
    > Yes, I know, this isn't a good situation any way you slice it...but I need a
    > quick fix and poseAsClass: seems to be the best option - assuming the bug is
    > what I think it is.

    Sounds to me like what you actually need is for your views to stop
    fighting over the cursor. At most, a subclass of whatever Cocoa view
    is screwing with your cursor might be called for. Posing as NSCursor
    for this is like swatting a fly with a grenade.

    Mike
  • On Mar 5, 2009, at 12:00 PM, Eric Gorr wrote:

    >
    > On Mar 5, 2009, at 2:47 PM, Benjamin Stiglitz wrote:
    >
    >>> I have a need to use poseAsClass, but I see that it has been
    >>> deprecated
    >>> in 10.5 and won't be available for 64-bit applications.
    >>>
    >>> So, is there a replacement?
    >>
    >> WAYTTD: What are you trying to do? Maybe you don’t need to pose.
    >
    > Well, sadly, I am pretty sure I do...at least for now.
    >
    > Although, this bug is not quite confirmed yet, but I suspect I know
    > what the problem is.
    >
    > I am working on a Carbon -> Cocoa conversion. In the carbon part,
    > the cursor is being set to a 64x64 cursor constantly - via NSCursor
    > set. The problem comes when I move the cursor over a cocoa view
    > which I believe, by default, changing the cursor to what it wants -
    > which I believe is a 32x32 cursor.
    >
    > So, in the constantly fighting over what the cursor should be, there
    > is some weird cursor behavior...it flickers - moves quickly to a
    > nearby location and then back again.
    >
    > I figure I could write my own NSCursor subclass, pose it as the
    > normal NSCursor class and make sure that it is always trying to set
    > cursor in the same way in every situation.
    >
    > Yes, I know, this isn't a good situation any way you slice it...but
    > I need a quick fix and poseAsClass: seems to be the best option -
    > assuming the bug is what I think it is.

    That's a band-aid, not a solution.  Figure out why the carbon code is
    constantly trying to change the cursor, and fix it.

    -jcr
  • On Mar 5, 2009, at 21:17, John C. Randolph wrote:

    > On Mar 5, 2009, at 12:00 PM, Eric Gorr wrote:
    >
    >>
    >> On Mar 5, 2009, at 2:47 PM, Benjamin Stiglitz wrote:
    >>
    >> Although, this bug is not quite confirmed yet, but I suspect I know
    >> what the problem is.
    >>
    >> I am working on a Carbon -> Cocoa conversion. In the carbon part,
    >> the cursor is being set to a 64x64 cursor constantly - via NSCursor
    >> set. The problem comes when I move the cursor over a cocoa view
    >> which I believe, by default, changing the cursor to what it wants -
    >> which I believe is a 32x32 cursor.
    >>
    >> So, in the constantly fighting over what the cursor should be,
    >> there is some weird cursor behavior...it flickers - moves quickly
    >> to a nearby location and then back again.
    >>
    > That's a band-aid, not a solution.  Figure out why the carbon code
    > is constantly trying to change the cursor, and fix it.

    Or, go back one more step and try to figure out why it flickers.

    FWIW, I ran into a bug (this was in an earlier version of Leopard, and
    I haven't tried to check whether it still exists) where setting a
    custom image via [NSCursor set] caused the cursor to jump around and
    display some trash pixels (in a flickery sort of way) when the custom
    image had blocks of transparent pixels at its edges. (For example, if
    the actual cursor was 24 x 24 placed within a transparent 32 x 32
    image.) The workaround was to trim the transparent pixels from the
    image (make it 24 x 24, for example).

    So, it may be that the flickering has nothing to do with how often the
    cursor is being set. If the 64 x 64 cursor in this case is a custom
    image, and if the actual, non-transparent pixel bounds are smaller
    than 64 x 64, and if the bug is still there, you may avoid the problem
    by using a smaller image.

    As I said, FWIW.
  • On 5 Mar 2009, at 21:00, Eric Gorr wrote:

    >>> I have a need to use poseAsClass, but I see that it has been
    >>> deprecated
    >>> in 10.5 and won't be available for 64-bit applications.
    >>>
    >
    and then you said:
    > I am working on a Carbon -> Cocoa conversion. In the carbon part,
    > the cursor is being set to a 64x64 cursor constantly - via NSCursor
    > set. The problem comes when I move the cursor over a cocoa view
    > which I believe, by default, changing the cursor to what it wants -
    > which I believe is a 32x32 cursor.

    Well, if you are worried about 64-bit then your Carbon UI code won't
    work anyway so you'd have to be all Cocoa, at which point the normal
    NSCursor handling should suffice. The fact that it is deprecated in
    10.5 is just a heads-up to not use it if possible, but if you still do
    need to use it in your Carbon-Cocoa hybrid, then use it. I imagine
    that 32-built Carbon UI will disappear from the OS before 32-bit Cocoa
    support.

    Matt
  • On Mar 6, 2009, at 12:03 AM, Michael Ash wrote:

    > On Thu, Mar 5, 2009 at 3:00 PM, Eric Gorr <mailist...>
    > wrote:
    >>
    >> On Mar 5, 2009, at 2:47 PM, Benjamin Stiglitz wrote:
    >>
    >>>> I have a need to use poseAsClass, but I see that it has been
    >>>> deprecated
    >>>> in 10.5 and won't be available for 64-bit applications.
    >>>>
    >>>> So, is there a replacement?
    >>>
    >>> WAYTTD: What are you trying to do? Maybe you don’t need to pose.
    >>
    >> Well, sadly, I am pretty sure I do...at least for now.
    >>
    >> Although, this bug is not quite confirmed yet, but I suspect I know
    >> what the
    >> problem is.
    >>
    >> I am working on a Carbon -> Cocoa conversion. In the carbon part,
    >> the cursor
    >> is being set to a 64x64 cursor constantly - via NSCursor set. The
    >> problem
    >> comes when I move the cursor over a cocoa view which I believe, by
    >> default,
    >> changing the cursor to what it wants - which I believe is a 32x32
    >> cursor.
    >>
    >> So, in the constantly fighting over what the cursor should be,
    >> there is some
    >> weird cursor behavior...it flickers - moves quickly to a nearby
    >> location and
    >> then back again.
    >>
    >> I figure I could write my own NSCursor subclass, pose it as the
    >> normal
    >> NSCursor class and make sure that it is always trying to set cursor
    >> in the
    >> same way in every situation.
    >>
    >> Yes, I know, this isn't a good situation any way you slice it...but
    >> I need a
    >> quick fix and poseAsClass: seems to be the best option - assuming
    >> the bug is
    >> what I think it is.
    >
    > Sounds to me like what you actually need is for your views to stop
    > fighting over the cursor. At most, a subclass of whatever Cocoa view
    > is screwing with your cursor might be called for. Posing as NSCursor
    > for this is like swatting a fly with a grenade.

    Ultimately, yes. At the moment, it may actually be possible...still
    looking into it.

    But, I am still curious what alternatives there are to poseAsClass: ...
  • On Mar 6, 2009, at 2:05 AM, Quincey Morris wrote:

    > On Mar 5, 2009, at 21:17, John C. Randolph wrote:
    >
    >> On Mar 5, 2009, at 12:00 PM, Eric Gorr wrote:
    >>
    >>>
    >>> On Mar 5, 2009, at 2:47 PM, Benjamin Stiglitz wrote:
    >>>
    >>> Although, this bug is not quite confirmed yet, but I suspect I
    >>> know what the problem is.
    >>>
    >>> I am working on a Carbon -> Cocoa conversion. In the carbon part,
    >>> the cursor is being set to a 64x64 cursor constantly - via
    >>> NSCursor set. The problem comes when I move the cursor over a
    >>> cocoa view which I believe, by default, changing the cursor to
    >>> what it wants - which I believe is a 32x32 cursor.
    >>>
    >>> So, in the constantly fighting over what the cursor should be,
    >>> there is some weird cursor behavior...it flickers - moves quickly
    >>> to a nearby location and then back again.
    >>>
    >> That's a band-aid, not a solution.  Figure out why the carbon code
    >> is constantly trying to change the cursor, and fix it.
    >
    > Or, go back one more step and try to figure out why it flickers.

    It flickers because of the switch between using a standard NSCursor
    and a cursor based on a 64x64 NSImage. I believe this is a known bug
    or at least behavior that has been seen before by others. In any case,
    it is fairly easy to reproduce and I do plan to write a simple test
    app and submit a bug report.
previous month march 2009 next month
MTWTFSS
            1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31          
Go to today