You're right! As I wrote, it was the first post for me so I did this
mistake. Got a message from carbon-dev-bounce@... and supposed list
manager "bounced" my post, so I posted it again.
Sounds like you're using the same taktics as with your AppleEvents:
Just send again until it works ;-)
The application and the plugin can be loaded and unloaded
separately so
both of them
An application is not loaded or unloaded. It is launched and quit.
Plugins might be loaded or unloaded. So your description is only half
correct.
Come on Mike, I think everybody understood what I meant!
Well, after reading the sentence a couple of times I did figure out a
probable meaning which seems to have turned out to be correct. It
would have been much easier though if you had used the correct
terminology.
Sloppy descriptions like these give the impression of sloppy thinking
and/or programming. So it might be in your own best interest to
formulate as precicely as you can.
How are you addressing your non-existant target?
Both direction of my communication define targets using
typeApplSignature.
Which means that you seem to know the signature of the target
process. In the case of your app that's not surprising but how can
you be sure of the signature of the third party app loading your
plugin? What if some other app loads your plugin?
And while creator codes are supposed to be unique there is no
guarantee they actually are. "Unique" here includes the possibility
of making a copy of an application and launching the original and the
copy at the same time which comes back to the question of how you
handle multiple running apps loading your plugin or multiple copies
of your own app running at the same time?
Sending dozen of messages to a non-existing target and being
returned
procNotFound will cause memory leakage, somehow slowdown the session
or cause an app crash?
Putting your question aside for the moment, why are you continuing to
send to a non-existing target after getting back the first error?
Just set a flag and inhibit further sends.
Apart from bugs (which are always possible) I don't think the
AppleEvent Manager should leak memory in this situation. Are you
actually seeing a memory leak? Does your code dispose of all the
memory associated with each of the AEs correctly?
If the AE Manager leaks then you should file a bug with Apple.
I'm not seeing any memory leak by the Apple Event Manager, but I
wanted
to know if doing this is a suggested-practice or a completely
deprecated!
I'd say it's neither suggested practice to waste cpu cycles sending
to nonexisting targets nor will anyone specifically deprecate this
(completly or otherwise) apart from the general rule not to waste
resources. Our current computers may be fast but enough wastefulnes
like this will eventually bring them down.
So in summary you are not seeing any leaks, you shouldn't see any
leaks but you are wasting cpu cycles. What was your question again?
(this not happen running the apps for a couple of minutes, so my
question is referred to a longer session which should be stable and
reliable anyway).
Err what?
If the answer is YES, is there a way to lookup the presence of an
Apple Event target before sending the actual messages? I found
AEGetEventHandler but this works only for my app handlers (or for
sys-level ones, but I don't want to register my handlers as system
ones.).
No not really. You could check for the presence of a certain process
but there is no guarantee that the process has loaded your plugin and
actually handles your AE. In addition there is window of time between
checking and sending during which the target process might disapear.
Also if your plugin can be loaded by different apps then it might be
hard to check for all relevant apps. And have you thought about the
situation where more than one app has your plugin loaded at the same
time?
Thanks, I'll try it soon...
I hope "it" helps :-)
I get the impression that one or both of your communication partners
(app & plugin) keep sending AEs to the other regardless of whether
the target exists. Is that true?
If so, why are they doing this? Is it to signal the other "I'm here!
Talk to me."? You might want to look at CFNotificationCenter instead
of using AEs. After you get a notification of your communication
partner you can start talking using AEs. (Though there is still a
window of time where the partner might disapear. So be sure to check
for errors.)
Thank you again!
Without knowing more details about your problem I may be missing
something but thinking about this again I don't understand why both
the plugin and the app are trying to initiate the communication?
Wouldn't it be sufficient if the plugin would try to find the app,
possibly retrying periodically or using some other method of getting
notified when the app becomes available? For example:
1. A plugin loads and checks if your app is running. If so it sends
an AE to initiate communication. If not or if it gets no reply to the
AE it registers a CFNotification callback for a notification sent by
your app.
2. If the plugins notification callback is triggered it will try to
find the running app (using its PSN if possible - see below) and and
send its AE to initiate communication. If that doesn't work, wait for
another notification.
3. When your app launches and is ready for communication it sends out
a CFNotification to signal all waiting plugins that it is now
available. The notification might include its PSN in the userInfo
CFDictionary so that the plugin{s) may address the exact process not
just any process with a certain creator code.
4. When your app receives an AE from a plugin then it will start
communicating with that plugin. Depending on your application
structure this might happen for more than one plugin at the same time
or on a first come, first serve basis. (In the later case you should
probably answer the additional communication requests whith an
appropriate error response - "Sorry, but I'm busy!" - so that the
additional plugins can notify the user.)
5. Optionally your app might repost the notification periodically if
there is no ongoing communication with a plugin. This would cover
cases where bad timing might prevent successfully establishing the
communication using the above 4 steps. This would be the only sightly
wasteful step. But since it would probably solve a potential problem
and since it would only come into play in hopefully rare situations
it would be ok. Use a resend timeout as high as you can without
inconveniencing the user. Something like 10 seconds or more would
sound ok to me. Maybe even scale the timeout from short at first to
progressively longer up to a maximum.
6. Whenever a plugin in communication with your app unloads it tells
your app that it does so. The app then sends out notificatios that it
is available again (step 5).
7. Whenever your app quits while communicating with plugins, it tells
them so. The plugins then go back to waiting for a notification.
HTH
Mike
--
Mike Fischer Softwareentwicklung, EDV-Beratung
Schulung, Vertrieb
Web: <http://homepage.mac.com/mike_fischer/index.html>
Note: I read this list in digest mode!
Send me a private copy for faster responses.
_______________________________________________
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
