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.

 

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 :

InputBSTR) 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...

Hope this helps!

-h-

 

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.

 

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...

Interesting, is there a reason which prevents you from implementing the
add-in in VB?

-h-

 

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.

 

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 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.

 

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.