Not exactly, I am still using the workaround I mentioned in a previous post.

Jaouad, the documentation is this thread - Pete described all of its parameters. What exactly are you looking for? Marko

I have recompiled it for you, but apparently I do not have the write access to upload the file to the ftp site. Do you want me to e-mail it to you?

Why don't you create a program that spawn off the editor, and that returns immediately?

It turns out that "move" method actually does work, but the new order is not reflected in the operation manager. There is a thread here from three years ago about the same problem, and the solution was to call undeclared (but exported) function OMrefreshOpManTree. And while it did not work quite well back then, it works flawlessly for me now.

I can import the operation by calling import_all_operations function without a problem, but I want to make sure the the imported operations (actually, in my case the library I am importing from contains exactly one operation, if that matters) come ahead any already existing operations. Is there a way to do that? Alternatively, I tried calling TpMainToolMgr.m_MainOpList.move(op_idn[0], 0), where op_idn array was filled in by the previous call to import_all_operations, but that did not do anything. Furthermore, a debugger session showed that the m_MainArray vector from the parent template class TpMemList was empty after importing the operations which does not sound right. Unless I misunderstood "What'new" document, the list should have contained all of the operations. Marko

Not exactly, I am still hoping Roger would remember me In the meantime, I have come up with a workaround: convert the chain into contour with chain_to_ctour_array, and then offset it with cutter_comp_2d function.

My bad, I did not see the double pointer there! I thought the array was supposed to be provided by the caller (along with its size to limit the number of stored entities). If the function allocates the array as needed, that is a completely different story.

While I have not used the function, I would say it simply returns pointers to elements from Mastercam's own database and no explicit freeing is expected from the caller. But the function is either under-documented or dangerous. How does it know how big is your array it is supposed to fill? I think that *num_eptrs should be prefilled with the array size before the call, and the function will update it to reflect the number of elements store. That was the "under-documented" scenario from the above. The worse scenario is that it just stores as many entity pointers as needed, and you better provide a humongous array if you want to be safe!

That is strange, because it worked for yesterday, again without a problem.

I was able to load the debug version of the C-hook when I was experimenting last week. Have you tried, or are you just guessing?

I get the same error. But it turns out you do not need to use Mcamx3sdkdebugMastercam.exe. Just point to the regular non-debug application Mcamx3Mastercam.exe and start it under debugger. You may get the pop-up message about Mastercam.exe not having debug information. Just ignore it, and the execution will stop at the break point in you C-hook.

Roger, ideally I want to get a CHAIN in memory that offsets the given CHAIN. I am going perform some operation on the offset chain after that in my C-hook. Somewhat related to this is another question: can I determine the direction of a closed contour given as CHAIN, similar to find_direction function that operates on "ctour_rec"? Thanks, Marko

Is there a way a C-hook can replicate "Xform->Offset Contour" functionality? All I was able to find is "cutter_comp_2d " function which is not exactly the same - for starters, it does not deal with "CHAIN" structure. Thanks Marko

I am just guessing here, but it is enough to change a structure, by inserting another member for example. If the new (X2) layout is used to compile your C-hook, you can not make a function call with it into the old (X) Mastercam, because the function will read/write information from the offsets in the structure that do not match the new layout. There are numerous other possible causes, like changing the number of parameters of a function.

You may be missing the library specification (I am not in a position to check which one) in your project. Assuming you have got it correctly, an explanation could be that Visual Studio 2008 differently "mangles" C++ symbols. The SDK libraries were created with Visual Studio 2005.

After some additional experimentation, I found that put_surf_in_db sets the surface parameters I had missed originally, like curvatures and extents.

quote: put_surf_in_db() is simply a wrapper around store_ent() which accepts a 'surf_type' as input.Just an observation here: put_surf_in_db must be doing something else other than just being a wrapper. Like arenner noticed, surfaces created by store_ent are not selectable, while those created with put_surf_in_db are.

Thanks, I think I am all set for the project now. Marko

Thanks Pete, I am going to try it as soon as possible. I suppose the function stores the generated entities into the database. Any neat trick to figure out what newly created entities are? I have got a couple of ideas, none of them being to appealing. Marko

Takashi, I see what you mean. The function has too many arguments to be able to figure them out by trial and error. Marko

How do I do that from a C-hook? Marko

I need to find the intersection between two surfaces (resulting in a set of lines, arcs or splines), or between a surface and a line/spline/arc (resulting in a point). Is there a function in the API that would do that for me? Or a suggestion how to do it myself? Thanks Marko

This is how Windows load the DLL. You can read more in the Platform SDK documentation under "LoadLibrary", but in short it is picking the DLL from the same location where the executable file is coming from.

Are you compiling it as a C++ program? If so, try declaring it as extern "C" DllExport MC_BOOL SetActiveMachine (LPCTSTR name);