Shoot an email to [email protected] with all your company contact info. Also, if you send a message to sdk inbox, I can reply to that with the "How to figure out which lib file is missing!" document.

https://my.mastercam.com/communities/3rd-party-developers/c-hook-downloads/ Under "Mastercam C-Hook documents", see the "How to figure out which lib file is missing!" document.

JKLINE, You are looking to create a Draft surface with a NET-Hook add-in?

Also... It does not appear to make a different in the output in "this" case, but... // Be careful doing '=' or '!=' comparisons of floating point values. //if (chain.Area != t.Area) // No if (Math.Abs(chain.Area - t.Area) < Mastercam.IO.SettingsManager.SystemTolerance) // Yes, check against some tolerance

Don’t know “why” at this point, but it makes a difference. In -> offsetCutChain80() Original: GraphicsManager.Repaint(true); int createdUpperLevel = 500; int createdLowerLevel = 501; Altered: GraphicsManager.Repaint(false); // or remove this call int createdUpperLevel = 500; int createdLowerLevel = 501; Result -> Yes, you can share the ChainDataInterop project.

Below is an image of the end-result Level Manager I get. I see 49 entities on Level #80 and 49 entities on Level #81. So where is “geometry on level 81 gets moved” ? -------------------------------- After you have done an XForm operation the resulting entities are marked by Mastercam as a “result” group. You should be able to retrieve those entities that are a “result of the last Xform” doing this. var resultGeom = SearchManager.GetResultGeometry(); ------------------------- Get rid of the lines setting an array = null e.g. The last 4 lines of the translate method - // NOT needed tempSelectedGeometry1Result = null tempSelectedGeometry1 = null; tempSelectedGeometry2Result = null; tempSelectedGeometry2 = null; And other locations in the code - selectedGeometry = null; // NOT needed //ask to reclaim the memory from the list System.GC.Collect(); // NOT needed Will these cause problems? Probably not, but the are not needed and just add "noise" to the code.

Break it down... Create a method that does just the "move" of the geometry. Work out that process out in isolation of all the 'other' code. Once you know that it works and how it works, you can concentrate your efforts on the other code in your add-in. This is "Clear Color" that clears the Group/Result markings on geometry. Probably not going to help and maybe *not* want you want. See NOTE below. No. Just no. Is this what is happening? I am restating basically what x4g said here. -> "If you translate something make sure you call retrieve on the entity if you are holding a list of pointers to the entities," Your add-in has selected geometry, then is translates/rotates/moves that geometry using some XForm method. After the XForm operation are you then still "looking" at the original geometry your add-in holds in a list? Looking at the docs for: GeometryManipulationManager.TranslateGeometry Method GeometryManipulationManager.CopySelectedGeometryToLevel Method Etc. -> NOTE! Any Geometry objects that get altered will NOT be reflected in that entity's data "on the NET-Hook side" if that entity's data is being held in a NET-Hook Geometry object! You can use GetResultGeometry() to retrieve the result of the XForm operation.

Corrupt in what way? If you do Statistics on the file after the run, are the missing entities included in the count? If you remove the shortenChain### calls, does that make a difference? If you do a rebuild graphics after the run, does that make a difference? Since I have almost nothing to go on there, I'm reduced to guessing.

In the NET-Hook API there is a Area property on a Chain Chain.Area Property Gets the area within the chain, assuming it's closed. Namespace: Mastercam.Database public double Area { get; }

A "chain nested inside of another chain" should not make any difference. I would suggest "breaking down your process" and then building it back step-by-step. To start forget about doing the level manipulations, etc. ? -> Starting with level 80, it creates level 500 which should match level 200 and it creates level 501 which should match level 300 First, nail down just the first step you want to do with the chains. (e.g. Offsetting the Chains) Once you have that figured out, then you can add back in the other processes your add-in is supposed to do.

In the NET-Hook API [https://nethookdocs.mastercam.com] Version History - Mastercam 2023 -> Added: FilletChain method to the GeometryManipulationManager class. Mastercam.GeometryUtility.Types.FilletChainsParams Mastercam.GeometryUtility.Types.BreakManyPiecesParameters Mastercam.GeometryUtility.Types -> FilletStyle Enumeration Mastercam.GeometryUtility.Types -> ReFilletOption Enumeration We do have a sample 2023 NET-Hook project that demos this "new in 2023" functionality.

So.... It appears al the chains should now be going Clockwise. Can we verify that? The only other thin here is the OffsetChain2D that we assume worked proper for each chain, so that's probably not the issue. With a clockwise Chain and OffsetSidedType.Right it looks like you are wanting to new offset chain to be "inside" the original chain. If you cannot get the OffsetChain2D result to be "correct", lease send us the geometry file and the offsetting code you are using.

I do not know what is meant by this. -> You have geometry on a level. You chain all “this level”. I think this would work to get all the chains going the same direction: CW or CCW Loop through the chains and set the Direction of each chain to the desired ChainDirectionType Now are not all the chains going the same direction? Now that you know the chain’s direction you can know which “side” to use in the OffsetChains2D call.

chain.OffsetChain2D in the NET-Hook API is doing what you can via Mastercam’s UI with (Wireframe) Offset Chains. If there is something you can do via the Offset Chains UI that cannot be done with a NET-Hook, let us know and we will investigate.

Something file in your memory about the NET-Hook API - Whenever you are doing Commit on an Operation. If you have not altered the geometry (chains, drill points, etc.) assigned to that operation. In other words, you are just updating "parameters" of the operation. Use the Commit overload that takes a boolean parameter and pass "false" -> op.Commit(false); "false" here tells it not to look at (or touch) the geometry in the operation when doing the Commit (update).