1. Home
  2. Solidworks CAD Design software
  3. API documentation has me where it wants me.

API documentation has me where it wants me.

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.

Reply to
Jim Sculley
Loading thread data ...

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-

Reply to
Heikki Leivo

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.

Reply to
Jim Sculley

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-

Reply to
Heikki Leivo

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.

Reply to
TheTick

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.

Reply to
Jim Sculley

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.

Reply to
Jim Sculley

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.

Reply to
TheTick

PolyTech Forum website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.