Weird behaviour checking LaunchServices

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

David Oberst - 31 Jan 2004 07:20 GMT

I coded a little check for the availability of LaunchServices in a
standard Carbon app, as per Apple's TN2017 (there doesn't seem to be a
Gestalt check for this). The following is from a freshly created
CodeWarrior 9 C Carbon Toolbox stationery project. The only thing
added is the CarbonFrameworkLib stub library, and the code following
Initialize() replaces the original call to NoteAlert().

void main(void)
{
    Initialize();

    if ( (UInt32)LSGetApplicationForInfo !=
(UInt32)kUnresolvedCFragSymbolAddress )
        SysBeep(30);
    else {
    SysBeep(30);    SysBeep(30);    SysBeep(30);
    }

//Delay(60, NULL);
}

Run on OSX, if finds the LS routine and beeps once, as expected.
However, on OS9, I still only get a single beep, as if
LSGetApplicationForInfo existed, which isn't the case (at least, I
crash on any LS call). The weird thing is that if I uncomment the
Delay() call, all of a sudden things work right on OS9, and I get the
three beeps indicating that LaunchServices isn't available.

The same thing happens if I leave in the original NoteAlert() call -
it seems that without these further calls, the entries for the LS
routines don't get properly zeroed out. If I just put in a simple
non-Toolbox line of code, like "n = 7", it doesn't seem to fix the
problem. Is the linker doing something funny, or something not
happening properly when the program is launched on OS9?

------
David Oberst
Yellowknife, NWT, Canada

Reply to this Message

Miro Jurisic - 31 Jan 2004 08:28 GMT

> void main(void)
> {
[quoted text clipped - 16 lines]
> Delay() call, all of a sudden things work right on OS9, and I get the
> three beeps indicating that LaunchServices isn't available.

The problem is that SysBeep is asynchronous -- the call returns immediately, and
the beep continues in the background. Imagine, if you will, a beep sound that
lasts 10 seconds. If you call SysBeep, it does not take 10 seconds to return. It
returns immediately, and your program keep executing while the computer beeps.
Now, if you call SysBeep again while it's already beeping, it queues the new
beep, and returns right away. So, if you call SysBeep twice in rapid succession,
and the beep is 10 seconds long, the first beep will start right away and last
10 seconds, and the second will start ~10 seconds _after SysBeep returns_ and
last for 10 seconds.

However, if your app exists, all the pending and current beeps are flushed, and
this is what you are seeing.

hth

meeroh

Signature

If this message helped you, consider buying an item
from my wish list: <http://web.meeroh.org/wishlist>

Reply to this Message

David Oberst - 31 Jan 2004 22:47 GMT

> > if ( (UInt32)LSGetApplicationForInfo !=
> > (UInt32)kUnresolvedCFragSymbolAddress )
[quoted text clipped - 7 lines]
> However, if your app exists, all the pending and current beeps are flushed, and
> this is what you are seeing.

Yup, when put an empty statement in the OSX branch, I still get the
one beep on the OS9 path, and the other two are flushed on exit. I
could have sworn that in a larger code fragment I was working on the
LSGetGapplicatioForInfo vector-check was erroneously succeeding on
OS9, which was why I created this little test. But now when I go
back, I can't get it to do that anymore. Perhaps just midnight
gremlins. Thanks...

Reply to this Message

Mac Forum / Programming / CodeWarrior / January 2004

Weird behaviour checking LaunchServices