API documentation has me where it wants me.

Discussion in 'SolidWorks' started by Jim Sculley, Feb 6, 2004.

  1. Jim Sculley

    Jim Sculley Guest

    The documentation for SldWorks::AddMenuItem2 states the following:

    ================================
    Syntax (COM)

    status = SldWorks->AddMenuItem2 ( DocumentType, Cookie, MenuItem,
    Position, MenuCallback, MenuEnableMethod, HintString, &IsMenuItemAdded )

    Input:
    (long) DocumentType
    Document type to which to add the menu item

    Input:
    (long) Cookie
    Identifier of the menu as defined in swMenuIdentifiers_e; this is the
    same Cookie that you specified in SwAddin::ConnectToSW

    Input:
    (BSTR) MenuItem
    Menu string ("menuItem@subMenuString@menuString"); SolidWorks creates
    menus and submenus only if they do not already exist

    ===================================

    Note the description for the 'cookie' parameter. First it says that it
    should be a value from the swMenuIdentifiers_e enumeration, and then
    goes on to say that it should be the same cookie *I* specified in
    ConnectToSW. The problem is, *I* don't specify a cookie in ConnectToSW.
    The cookie is handed to me by SW. In any event, the point is moot,
    because if I use the cookie, the addin crashes. I suspect that this a
    another in a long list of cut and paste errors in the API docs.

    If I call the above like this:

    hr = sldWorks->AddMenuItem2 (
    swDocNONE,
    swToolsMenu,
    menuItemInfo,
    0,
    menuFunction,
    empty,
    empty,
    &added);

    where:

    menuItemInfo = a BSTR containing "Item@Addin"
    menuFunction = a BSTR containing "helloWorldFromMenu "
    empty = a BSTR containing ""

    I expect this to add a submenu named 'Addin' to the 'Tools' menu, with a
    single menu item named 'Item'.

    What I get is a new menu named 'Addin', with no items under it. Upon
    checking the eroror status, the 'added' variable is FALSE, which means
    that the item was not added. Howevr the menu is, so clearly SW is not
    doing what it should. If the call to add an item fails, all of its
    parent should not be created.

    It seems as though the 'cookie' parameter does nothing.

    Why the call is returning FALSE for 'added' is a separate issue most
    likely related to IDispatch, but if someone has made sense of this
    horrible bit of API documentation, I would appreciate a snippet of code
    showing the 'proper' way to do this.

    Jim S.
     
    Jim Sculley, Feb 6, 2004
    #1
  2. Jim Sculley

    Heikki Leivo Guest

    Hello Jim,
    This weird piece of "documentation" has confused me, too. From SW api help
    it is indeed very hard to conclude what one should do with the cookie
    parameter. IMO you should use the "cookie" which is passed by SW to your
    add-in. At least this is how we have used the cookie. I believe that the
    cookie is used internally to distinquish beetween menus created by different
    add-ins.
    I believe your menuitem string should be "Item@Addin@&Tools", if you want to
    insert the item into tools menu. From SW api help :

    Input:(BSTR) MenuItemMenu string (menuItem@subMenuString@menuString);

    At least I have been able to create submenus this way, but I use VB instead
    of C++. Maybe you should create the "Addin" submenu before creating "Item"
    under it.
    Well, hmm, maybe you should not take it granted that the return value
    actually means something... :p

    Hope this helps!

    -h-
     
    Heikki Leivo, Feb 6, 2004
    #2
  3. Jim Sculley

    Jim Sculley Guest


    It is actually *more* confusing than the documentation for the now
    obsolete AddMenuItem, and I didn't think that was possible. The
    GetTesselationXXX functions still hold the crown though.
    Doing so crashed Solidworks. :(

    I'll take a closer look to make sure my cookie is being stored as it should.
    Yes, that is how I interpreted it, but the crashing made me lean toward
    the first description of 'cookie'. Its almost as if they intended to
    have two different functions. One to add to existing menus, and one to
    create new menus. Then later on, they decided to combine them into one,
    but messed up the documentation in the process.
    I tried that. I got a second 'Tools' menu. :)

    Granted I didn't include the '&' so SW may have not recognized it as the
    same 'Tools' menu. I'll try that and see what happens.
    Yes. This of course conflicts with the first description of the
    'cookie' parameter though. If there is an enumeration for the various
    existing menus, it seems redundant for me to include 'Tools' in the menu
    string.
    The documentation states that ConnectToSW can only call AddMenuItem2
    (and the associated AddToolbar function). On a whim, I tried adding the
    menu via AddMenu but the results were the same. The menu is there, but
    the call fails to add the menu item, which is a different problem.

    Another confusing aspect is the 'SetAddinCallbackInfo' function. I
    interpret it as a function that allows me to specify a specific handler
    for callbacks, such as those performed by SW when custom menu items are
    clicked. It doesn't seem to work, but that may just be a problem in my
    code.
    I hate C++.

    The only thing that keeps me going is the thought that I may have a
    'killer' addin idea.

    Jim S.
     
    Jim Sculley, Feb 6, 2004
    #3
  4. Jim Sculley

    Heikki Leivo Guest

    It is actually *more* confusing than the documentation for the now
    I love the tessellation functions; I was able to create a screensaver which
    steals the 3d model from SW session. It requires LOTS of guessing to use the
    functions, indeed... :p
    Interesting, is there a reason which prevents you from implementing the
    add-in in VB?

    -h-
     
    Heikki Leivo, Feb 6, 2004
    #4
  5. Jim Sculley

    TheTick Guest

    Something is not right with the help. The cookie parameter is the one
    specified by the addin.

    The swMenuIdentifiers_e enumeration is used by
    SldWorks::GetLocalizedMenuName to get the string value names of the SW
    menus like "File", "Insert", "Tools", etc. If you want to add a
    submenu under tools, you need this string.


    Time for me to go home now. I'll post more later. Sorry, I'm just VB
    literate, so any examples I have will be in VB.
     
    TheTick, Feb 6, 2004
    #5
  6. Jim Sculley

    Jim Sculley Guest

    Other than my deep seeded hatred for it as well? No.

    ;)

    If I get this working in C++, I will most likely dust off my old Java-SW
    bindings and see if I can get that to work. I know a fair bit more now
    thn I did then, so I may be able to accomplish the task.


    Jim S.
     
    Jim Sculley, Feb 6, 2004
    #6
  7. Jim Sculley

    Jim Sculley Guest

    Jim Sculley wrote:


    <snip>

    I seem to have it sorted out now. COM is evil. But I defeated it.

    I've created a test addin that adds menu items and makes the appropriate
    callbacks in response to menu item selections.

    I've also got it responding to SW events.

    A little bit of cleanup work and I'll actually be able to start on the
    guts of the addin itself.


    Jim S.
     
    Jim Sculley, Feb 9, 2004
    #7
  8. Jim Sculley

    TheTick Guest

    Since most of my addins originated as macros, I am in the habit of
    writing programs as .exe's, and then tossing in the addin class and
    converting to .dll when I'm darn good and ready. Sometimes I
    substitute a temporary form if I need to make menu picks available.

    I find this helpful because it is easier to run .exe code on-the-fly
    without compiling and make sure the program innards are in good
    working order.
     
    TheTick, Feb 9, 2004
    #8
Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.