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.