Mailing Lists: Apple Mailing Lists

Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Progress bar will not update.



I looked up NewEventHandlerUPP in the Leopard headers, and it's similar to what you've shown below. What's odd is that it's still in the API docs (and online at ADC), and not listed or marked as deprecated.

What is also not shown anywhere is whether the same is true under earlier OSs. The definitions like you've shown are not in the old headers, so I was curious whether those calls are needed for Mach-O in Tiger.

So, as a test, I replaced all my NewEventHandlerUPP calls, using just the procedure name instead, and removed the DisposeEventHandlerUPP calls, and everything's still working fine in my Mach-O bundle app compiled and run in Tiger.

Verrrry interesting...

Seems to me this should be documented somewhere, eh?

-Howard

On Nov 28, 2007, at 9:50 AM, John Stiles wrote:

Here's a random example pulled from the Leopard Carbon headers.

#if __MACH__
#ifdef __cplusplus
inline MenuTitleDrawingUPP NewMenuTitleDrawingUPP(MenuTitleDrawingProcPtr userRoutine) { return userRoutine; }
inline MenuItemDrawingUPP NewMenuItemDrawingUPP(MenuItemDrawingProcPtr userRoutine) { return userRoutine; }
inline void DisposeMenuTitleDrawingUPP(MenuTitleDrawingUPP) { }
inline void DisposeMenuItemDrawingUPP(MenuItemDrawingUPP) { }
inline void InvokeMenuTitleDrawingUPP(const Rect * inBounds, SInt16 inDepth, Boolean inIsColorDevice, SRefCon inUserData, MenuTitleDrawingUPP userUPP) { (*userUPP)(inBounds, inDepth, inIsColorDevice, inUserData); }
inline void InvokeMenuItemDrawingUPP(const Rect * inBounds, SInt16 inDepth, Boolean inIsColorDevice, SRefCon inUserData, MenuItemDrawingUPP userUPP) { (*userUPP)(inBounds, inDepth, inIsColorDevice, inUserData); }
#else
#define NewMenuTitleDrawingUPP(userRoutine) ((MenuTitleDrawingUPP)userRoutine)
#define NewMenuItemDrawingUPP(userRoutine) ((MenuItemDrawingUPP)userRoutine)
#define DisposeMenuTitleDrawingUPP(userUPP)
#define DisposeMenuItemDrawingUPP(userUPP)
#define InvokeMenuTitleDrawingUPP(inBounds, inDepth, inIsColorDevice, inUserData, userUPP) (*userUPP)(inBounds, inDepth, inIsColorDevice, inUserData)
#define InvokeMenuItemDrawingUPP(inBounds, inDepth, inIsColorDevice, inUserData, userUPP) (*userUPP)(inBounds, inDepth, inIsColorDevice, inUserData)
#endif
#endif


So  now I guess it's verified :)


Howard Moon wrote:
Where do you get that info from? I still see NewEventHandlerUPP in their API docs, and it's not listed as deprecated, and doesn't contain any notes suggesting it's not needed. If indeed it's no longer needed, I'd sure like to see where that's stated.

-Howard

I believe that if you're building a Mach-O app, Apple has explicitly stated that the UPP calls do nothing, don't need to be used, and they even became no-ops in the Leopard headers.
I haven't verified this, it's just what I've heard.


Uli Kusterer wrote:
Am 28.11.2007 um 02:34 schrieb Julie Porter:
void RegisterForEvents(WindowRef myWindow)
{
EventTypeSpec cmdEvent; cmdEvent.eventClass = kEventClassCommand;
cmdEvent.eventKind = kEventProcessCommand;
EventHandlerUPP handlerUPP;
handlerUPP = NewEventHandlerUPP(CommandEventHandler);


  EventTargetRef target;
      target = GetWindowEventTarget(myWindow);

  void * userdata = NULL;
  InstallEventHandler(target, handlerUPP, 1,  & cmdEvent,
      userdata,NULL);
}


A UPP is a structure that wraps a function pointer. As such, you only need it once for every function. What people generally do is define a UPP as static to a function, and then they can allocate it once, re-use it, and it gets disposed with the rest of the application on shutdown.

That said, many of the UPP calls compile down to no-ops on OS X, because they were mainly invented for calling 680x0 function on PowerPC Macs, and thus in many cases you can just pass a straight ProcPtr into UPP-expecting APIs.


_______________________________________________
Do not post admin requests to the list. They will be ignored.
Carbon-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/carbon-dev/jstiles% 40blizzard.com


This email sent to email@hidden

_______________________________________________ Do not post admin requests to the list. They will be ignored. Carbon-dev mailing list (email@hidden) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/carbon-dev/email@hidden

This email sent to email@hidden
References: 
 >Progress bar will not update. (From: Julie Porter <email@hidden>)
 >Re: Progress bar will not update. (From: Eric Schlegel <email@hidden>)
 >Re: Progress bar will not update. (From: Julie Porter <email@hidden>)
 >Re: Progress bar will not update. (From: Eric Schlegel <email@hidden>)
 >Re: Progress bar will not update. (From: Julie Porter <email@hidden>)
 >Re: Progress bar will not update. (From: Uli Kusterer <email@hidden>)
 >Re: Progress bar will not update. (From: John Stiles <email@hidden>)
 >Re: Progress bar will not update. (From: Howard Moon <email@hidden>)
 >Re: Progress bar will not update. (From: John Stiles <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.