You also may want to add in a note that you have to pass in the contract ID
in as both the name and value of the category or it will not work. So, in
the calls to AddCategory entry, where it says "WebLock" it actually needs to
be WebLock_ContractID or it will not work. I'm not sure if this is a bug or
if it was intended to work that way, but if you use the code in the book,
you will end up with a component that does not do anything.

-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jeff Walden
Sent: Monday, October 10, 2005 3:10 AM
To: [email protected]
Subject: Two questions on nsICategoryManager::AddCategoryEntry

I've been working on moving the book Creating XPCOM Components[1] from
mozilla.org over to developer.mozilla.org[2].  The migration is in essence
complete -- all the text (sans an XPCOM API Reference which is separately
maintained) has been copied, formatted, surface-edited, and cross-linked,
and it is ready for use as long as you can successfully read between the
lines to decide what parts may be less relevant now than when the book was
written (mostly due to the suite->Firefox transition).  I'm now slowly
working through the remaining problems I know exist (with occasional
supplements from people who make questions or post comments in the wiki).

First question: the book contains two separate code snippets related to
AddCategoryEntry (one's explanatory while the other's part of an overall
code exhibit, so they *should* both be the same):

Exhibit A:
>nsEmbedCString previous;
>rv = catman->AddCategoryEntry("xpcom-startup",
>                              "WebLock",
>                              WebLock_ContractID,
>                              PR_TRUE,  // persist category
>                              PR_TRUE,  // replace existing
>                              previous);

Exhibit B:
>char* previous = nsnull;
>rv = catman->AddCategoryEntry("xpcom-startup",
>                              "WebLock",
>                              WebLock_ContractID,
>                              PR_TRUE,
>                              PR_TRUE,
>                              &previous);

Which of these is the preferred way?  (We'll ignore the fact that in this
instance it doesn't matter as |previous| is immediately nsMemory::Free'd.)
>From my reading of the source code I don't think there's a substantive
difference between the two, but there's no reason to be inconsistent.

Second: while investigating the previous question, I did some source
browsing of AddCategoryEntry[3] to see how the sixth parameter (which
returns the "previous entry, if any" according to IDL) is set.  From my
reading of the code it looks like the parameter isn't even used, which would
mean the IDL comments are out-of-date.  AddCategoryEntry doesn't itself
touch the parameter (and hasn't since 2003), and the only place it's passed
(CategoryNode::AddLeaf[4]) seems to not touch it either.  Am I horribly
misreading this code, or do the IDL comments need to be updated?

Thanks in advance for any help I can get here!

Jeff Walden

P.S. -- Any other comments on the migrated version of Creating XPCOM
Components are more than welcome. :-)

1. http://www.mozilla.org/projects/xpcom/book/cxc/html/
2. http://developer.mozilla.org/en/docs/Creating_XPCOM_Components
3.
http://lxr.mozilla.org/mozilla/source/xpcom/components/nsCategoryManager.cpp
#583
4.
http://lxr.mozilla.org/mozilla/source/xpcom/components/nsCategoryManager.cpp
#286
_______________________________________________
Mozilla-xpcom mailing list
[email protected]
http://mail.mozilla.org/listinfo/mozilla-xpcom


_______________________________________________
Mozilla-xpcom mailing list
[email protected]
http://mail.mozilla.org/listinfo/mozilla-xpcom

Reply via email to