Professional Web Applications Themes

send event to next responder? - Mac Programming

Michael Ash wrote:  well, DANG. that was my first instinct, since beos' event handling works the exact same way, even similar method names. beos's equivalent to NSView is BView. in your derived view's SomeView::KeyDown() implementation, if you don't want the event, you call BView::KeyDown() to hand it up the chain. this is one of the reasons i chuckle at some people's assertions that cocoa simply couldn't be done in any other language but obj-c. at least two of the cocoa books i've read have made that assertion. that's funny, because it already HAS been done, in other languages. i haven't ...

  1. #1

    Default Re: send event to next responder?

    Michael Ash wrote: 

    well, DANG. that was my first instinct, since beos' event handling
    works the exact same way, even similar method names. beos's equivalent
    to NSView is BView. in your derived view's SomeView::KeyDown()
    implementation, if you don't want the event, you call BView::KeyDown()
    to hand it up the chain.

    this is one of the reasons i chuckle at some people's assertions that
    cocoa simply couldn't be done in any other language but obj-c. at least
    two of the cocoa books i've read have made that assertion. that's
    funny, because it already HAS been done, in other languages.

    i haven't gotten back to this problem, since i didn't have enough
    information to work on it at the time, so i am now hip-deep in another
    problem. otherwise i'd be reporting whether it worked or not. i've got
    a feeling i'll have to override [NSWindow sendEvent:], as michael
    suggested.
    Jhnny Guest

  2. #2

    Default Re: send event to next responder?

    On Wed, 31 Mar 2004, =?ISO-8859-1?Q?J=F8hnny_F=E4v=F2r=EDt=EA_=28it_means_=22halo= 2C_then_resonate=22=29?= wrote:
     

    That doesn't make any sense. I don't think they're referring to something
    like forwarding keyDown messages when they talk about stuff that can't be
    done in other languages. Have a look at the notification system, undo
    manager, or distributed objects if you want to see something you can't do
    in C++. I say C++ because "other languages" most certainly *can* do
    everything Cocoa does; there are bridges available for pretty much every
    language that can handle it. There is no C++ bridge, and the obvious
    conclusion is that there must be things it can't do, given how many people
    seem to want such a thing.
     

    Just a correction on the attributions; matt suggested it, I just seconded.
    Michael Guest

  3. #3

    Default Re: send event to next responder?

    In article <nashville.comcast.net>,
    Jhnny Fvrt (it means "halo, then resonate") <com>
    wrote:
     
    >
    > well, DANG. that was my first instinct, since beos' event handling
    > works the exact same way, even similar method names. beos's equivalent
    > to NSView is BView. in your derived view's SomeView::KeyDown()
    > implementation, if you don't want the event, you call BView::KeyDown()
    > to hand it up the chain.
    >
    > this is one of the reasons i chuckle at some people's assertions that
    > cocoa simply couldn't be done in any other language but obj-c. at least
    > two of the cocoa books i've read have made that assertion. that's
    > funny, because it already HAS been done, in other languages.[/ref]

    Not the gestalt. Certainly certain idioms are achievable in other
    languages and similar mechanisms have been used in other APIs. Some
    vendors have even gone out of their way to mimic or approximate
    OPENStep. And it all ends up as a stream of machine instructions. But
    there are some aspects of Cocoa that are not reasonably or reliably
    achievable in other extant languages.

    G

    --
    Standard output is like your butt. Everyone has one. When using a bathroom,
    they all default to going into a toilet. However, a person can redirect his
    "standard output" to somewhere else, if he so chooses. - Jeremy Nixon
    Gregory Guest

  4. #4

    Default Re: send event to next responder?

    Michael Ash wrote: 
    >
    > Thanks JCR, you're right, of course. I didn't think about NSResponder's
    > implementation. And actually, since the docs say that NSResponder's
    > implementation just forwards it to the next responder, you could make it
    > even *shorter* (heh, heh) and just call [super keyDown:event].[/ref]

    You could, if you are *sure* that your superclass won't just consume the
    event. Sending it to the next responder explicitly may or may not be
    appropriate in a given case.

    -jcr
    John Guest

  5. #5

    Default Re: send event to next responder?

    Jhnny Fvrt (it means "halo, then resonate") wrote: 
    >
    > well, DANG. that was my first instinct, since beos' event handling
    > works the exact same way, even similar method names. beos's equivalent
    > to NSView is BView. in your derived view's SomeView::KeyDown()
    > implementation, if you don't want the event, you call BView::KeyDown()
    > to hand it up the chain.
    >
    > this is one of the reasons i chuckle at some people's assertions that
    > cocoa simply couldn't be done in any other language but obj-c.[/ref]

    Well, I'm sure Cocoa could have been done in Smalltalk, CLOS, Dylan, or
    any other message-passing language, but doing it in C++ would have been
    exceedingly difficult. Consider, for example, how Cocoa implements NSUndoManager:

    http://tinyurl.com/2kjwo
     

    Not quite.

    -jcr
    John Guest

  6. #6

    Default Re: send event to next responder?

    Michael Ash wrote: 
    >
    > That doesn't make any sense. I don't think they're referring to something
    > like forwarding keyDown messages when they talk about stuff that can't be
    > done in other languages. Have a look at the notification system, undo
    > manager, or distributed objects if you want to see something you can't do
    > in C++. I say C++ because "other languages" most certainly *can* do
    > everything Cocoa does; there are bridges available for pretty much every
    > language that can handle it. There is no C++ bridge, and the obvious
    > conclusion is that there must be things it can't do, given how many people
    > seem to want such a thing.[/ref]

    Well to do Cocoa in Obj-C, you'd pretty much have to re-implement an
    Obj-C runtime. The long and short of it is, in C++, you call a method.
    In Objective-C, you send a message.

    -jcr
    John Guest

  7. #7

    Default Re: send event to next responder?

    Michael Ash wrote: 

    okay, an oversimplification, perhaps. but ...
     

    oh, man. i *so* do not agree with that. there is *always* a way.
     

    if they could write a java bridge, they could write a C++ bridge. i'm
    not saying they should do it -- i'm not even convinced the java bridge
    was a good idea -- but it's possible, certainly.
    Jhnny Guest

  8. #8

    Default Re: send event to next responder?

    Jhnny Fvrt (it means "halo, then resonate") wrote:
     
    >
    > oh, man. i *so* do not agree with that. there is *always* a way.[/ref]

    Sure, you can write an Obj-C runtime in C++.
     
    >
    > if they could write a java bridge, they could write a C++ bridge.[/ref]

    Nope. Compare the Java and Objective-C runtimes, and you'll find far
    greater similarity than Objective-C and C++.

    -jcr
    John Guest

  9. #9

    Default Re: send event to next responder?

    On Thu, 1 Apr 2004, =?ISO-8859-1?Q?J=F8hnny_F=E4v=F2r=EDt=EA_=28it_means_=22halo= 2C_then_resonate=22=29?= wrote:
     
    >
    > oh, man. i *so* do not agree with that. there is *always* a way.[/ref]

    DO is always my favorite example. If you have a local object 'obj', you
    can send a message to it like this: [obj messageWithArg:arg count:3]. If
    you have a remote object 'remoteObj' via DO, you can send a message to it
    like this: [remoteObj messageWithArg:arg count:3]. Can you really do
    something like that in C++, where remote messaging has the *exact same
    syntax* as local messaging? If so, why haven't I ever heard of anybody
    making one? It's really useful.
     
    >
    > if they could write a java bridge, they could write a C++ bridge. i'm
    > not saying they should do it -- i'm not even convinced the java bridge
    > was a good idea -- but it's possible, certainly.[/ref]

    According to <http://osx.hyperjeff.net/Reference/cocoa.php>, there are at
    least 10 languages that have transparent bridges with ObjC, including
    Python, Lisp, Java, etc. Other than the Java bridge, none of these bridges
    were written by the ever-mysterious 'they'; they were written by small
    open-source groups. Surely there's a good number of people out there who
    would like to see a C++ bridge, so why hasn't anybody done one?
    Michael Guest

  10. #10

    Default Re: send event to next responder?

    Is replying to myself a sign of dementia?

    On Fri, 2 Apr 2004, Michael Ash wrote:
     

    My bad; the AppleScript bridge is also, as far as I know, an Apple
    product, not done by an open-source group.
    Michael Guest

  11. #11

    Default Re: send event to next responder?

    >>> There is no C++ bridge, and the obvious conclusion is that there must 
    >>
    >> if they could write a java bridge, they could write a C++ bridge. i'm
    >> not saying they should do it -- i'm not even convinced the java bridge
    >> was a good idea -- but it's possible, certainly.[/ref]
    >
    > According to <http://osx.hyperjeff.net/Reference/cocoa.php>, there are at
    > least 10 languages that have transparent bridges with ObjC, including
    > Python, Lisp, Java, etc. Other than the Java bridge, none of these bridges
    > were written by the ever-mysterious 'they'; they were written by small
    > open-source groups. Surely there's a good number of people out there who
    > would like to see a C++ bridge, so why hasn't anybody done one?[/ref]

    Well I have. But it's not open source -yet-. The main reason for that, is
    it's been constantly evolving to fit my needs and solve early stage
    mistakes. This includes changes in the API, and I do not wish to maintain
    backwards compatibility for it. The other reason is I do not have the
    resources to doent it.

    By the way it's a C bridge, designed for C++. I use it in connection with a
    C++ cross-platform framework which I also wrote.

    You can download an app written with it from www.fototrafix.com. The windows
    version is in beta stage.

    It's true that there are some things you can't do with it, but they are ObjC
    features, not Cocoa features.

    Now if there are some people around who are willing to write the docs and
    accept the risk of -meaningful- changes in the API, I'm not totally opposed
    to the idea of sharing that code.

    This is also true for the C++ framework which works with it.

    Eric

    Eric Guest

  12. #12

    Default Re: send event to next responder?

    i was going to stay out of this, because we're moving from technology to
    religion, but here's an interesting contribution:

    Eric VERGNAUD wrote: 
    >
    > Well I have. But it's not open source -yet-. The main reason for that,
    > is it's been constantly evolving to fit my needs and solve early stage
    > mistakes.[/ref]

    yeah, i'm in the same boat. i'm writing cross-platform c++ objects for
    views, files, windows, controls, menus, scrollviews, fonts, rects,
    points, you name it. in my mac port, they are written in terms of obj-c
    objects. but obviously not *all* cocoa objects, which would be a job
    for about 50 programmers with a few years to burn, not just one.

    the reason there's no general-purpose cocoa-to-c++ bridge is simply that
    to date, nobody has wanted it bad enough.
    Jhnny Guest

  13. #13

    Default Re: send event to next responder?

    On Sat, 3 Apr 2004, Eric VERGNAUD wrote:
     
    >
    > Well I have. But it's not open source -yet-. The main reason for that, is
    > it's been constantly evolving to fit my needs and solve early stage
    > mistakes. This includes changes in the API, and I do not wish to maintain
    > backwards compatibility for it. The other reason is I do not have the
    > resources to doent it.[/ref]

    I don't think this is a bridge, it's a wrapper.

    If you look at PyObjC, you see that it's not a Cocoa bridge, it's an
    Objective-C bridge. You don't end up with a bunch of classes that wrap
    Cocoa classes; the Cocoa classes are directly exposed as Python classes.
    Python classes can subclass Cocoa classes. Objective-C classes can
    subclass Python classes.

    I don't doubt that it's possible to make a pretty decent C or C++
    *wrapper* for Cocoa, but there will always be things you miss. Can you
    subclass ObjC clasess with your wrapper? If for some reason I want to make
    a custom scroll view, can I subclass it and override -tile? I don't mean
    to belittle your accomplishment and it sounds like a very useful thing,
    but it's not the same *kind* of thing as what I was talking about.
    Michael Guest

  14. #14

    Default Re: send event to next responder?

    dans l'article twistedsys.net, Michael Ash
    com a crit le 3/04/04 14:45:
     
    >>
    >> Well I have. But it's not open source -yet-. The main reason for that, is
    >> it's been constantly evolving to fit my needs and solve early stage
    >> mistakes. This includes changes in the API, and I do not wish to maintain
    >> backwards compatibility for it. The other reason is I do not have the
    >> resources to doent it.[/ref]
    >
    > I don't think this is a bridge, it's a wrapper.
    >
    > If you look at PyObjC, you see that it's not a Cocoa bridge, it's an
    > Objective-C bridge. You don't end up with a bunch of classes that wrap
    > Cocoa classes; the Cocoa classes are directly exposed as Python classes.
    > Python classes can subclass Cocoa classes. Objective-C classes can
    > subclass Python classes.
    >
    > I don't doubt that it's possible to make a pretty decent C or C++
    > *wrapper* for Cocoa, but there will always be things you miss. Can you
    > subclass ObjC clasess with your wrapper? If for some reason I want to make
    > a custom scroll view, can I subclass it and override -tile? I don't mean
    > to belittle your accomplishment and it sounds like a very useful thing,
    > but it's not the same *kind* of thing as what I was talking about.[/ref]

    Yes you can make a custom scroll view. You can override anything, if you
    need by providing the appropriate C++ subclass.

    If you happen to miss something, you can just add the connector (typically
    through a static class callback, which in return calls a virtual method). So
    in the end you don't miss anything.

    It's really a cross-platform framework, which wraps GDI on Windows and
    Cocoa/Quartz on MacOS, plus obviously all the non GUI classes.

    I agree it's quite different from a bridge that would connect languages in a
    way you would benefit from any Obj-C class with no effort. But it's very
    easy to use, and that was my main goal.

    Cocoa for Java is a wrapper too IMHO. You can't write poseAsClass in Java,
    can you ? And since Java reflection only inspects compiled classes, I doubt
    you can inspect features in the Obj-C underlying classes, can you ?

    Maybe I could have gone the opposite way, that is write an Obj-C framework
    to wrap Windows GDI. But I couldn't find a decent IDE on Windows, and I have
    so much C++ code that I thought it would be more efficient to go that way.

    Eric


    Eric Guest

  15. #15

    Default Re: send event to next responder?

    On Sat, 3 Apr 2004, Eric VERGNAUD wrote:

    [wrappers and bridges] 

    But you had to write all of the appropriate methods yourself, right?
     

    Sure. If your goal is cross-platform compatibility, you most certainly
    *don't* want a bridge. A bridge just lets you use the same APIs from a
    different language, which doesn't help platform portability at all, unless
    it's a cross-platform API.
     

    The Java bridge is kind of halfway. Java isn't quite dynamic enough to
    handle everything, so there are some kludges, and I think some (mostly
    automatic) preprocessing of the ObjC interfaces is required. But if Apple
    were to create a new class, call it NSWidgetView, I think it would be a
    fairly simple matter to preprocess it correctly and have it work in Java.
    With your framework, it would require writing some more code in your
    wrapper, right? With something like PyObjC, as long as NSWidgetView
    doesn't have something extremely C-specific like varargs methods or struct
    ivars, the new class is made available with no effort.

    Again, this isn't a criticism at all, your approach sounds like the right
    thing to do given your goals.
     

    Makes sense to me. Either way, you'll end up wrapping something. ObjC is
    available practically everywhere, but it's not always that well-supported.
    (Also, is ObjC++ still only in the Apple version of gcc? That could make
    things painful if so.)
    Michael Guest

Similar Threads

  1. How to send Remote controller key event
    By shihchung in forum Macromedia Flex General Discussion
    Replies: 0
    Last Post: May 15th, 11:52 PM
  2. Creating email auto-responder
    By superbullet in forum Coldfusion - Advanced Techniques
    Replies: 6
    Last Post: June 9th, 02:38 PM
  3. Send Admin Alert when Event Log Full
    By Bill Scherer in forum Windows Server
    Replies: 0
    Last Post: June 23rd, 05:49 PM
  4. help changing first responder
    By Jamal Bernhard in forum Mac Programming
    Replies: 2
    Last Post: August 18th, 10:16 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

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 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139