Randy, Here's a few things to double-check before moving forward. First, make sure your .[Mastercam Install Directory]Apps directory contains both the MCVBScript.dll and McDef.VBB files. These will need to be in that particular directory in order for the VBScript to run correctly. Second, check to make sure you're passing in the correct path for your script and that the file is in the correct place. The NetHook 1.0 API won't throw an error if the script path is wrong, it will just return without executing. I haven't tried it with the NetHook 1.0 API yet, but I was able to successfully run a VBScript from the NetHook 2.0 API via a test app. If it's still failing after checking the things I mentioned above, we can see about trying to recreate it with a NetHook 1.0 app too.

Thad, I'll run a few tests in house to see if we can come up with the same results here. In the meantime, could you tell me what version you're running? We've spent a lot of time trying to fix operation-related bugs in the past version or so, and knowing which version you're currently running might help us narrow down if you're seeing a new bug or if you're seeing a bug we might have already fixed. Thanks,

dialogdude, 1) The TranslationMode enum no longer exists, because there are different methods to take care of the different modes. So instead of writing the following code, like you might have been inclinced to do in X2... code: Dim TransMode As TranslationMode = TranslationMode.MoveExisting Dim GraphicsViewNumber As Short = ViewManager.GraphicsView Dim TranslateFromPoint As Point3D = New Point3D(0.0, 0.0, 0.0) Dim TranslateToPoint As Point3D = New Point3D(0.0, -0.5, 0.0) SecondNewLine.Translate(TransMode, TranslateFromPoint, TranslateToPoint, GraphicsViewNumber, GraphicsViewNumber) ... you would write this instead... code: Dim GraphicsViewNumber As Short = ViewManager.GraphicsView Dim TranslateFromPoint As Point3D = New Point3D(0.0, 0.0, 0.0) Dim TranslateToPoint As Point3D = New Point3D(0.0, -0.5, 0.0) SecondNewLine.Translate(TranslateFromPoint, TranslateToPoint, GraphicsViewNumber, GraphicsViewNumber) There's also a sibling method for the old TranslationMode of copying, called 'CopyAndTranslate()'. 2) If you want it, there's new versions of both the Samples & Examples project and the Reference Guide for X3 up on Mastercam.com in the Support -> Downloads -> Misc section. You've already stumbled across one of the only things that actually changed between X2 and X3 in these Geometry manipulation methods, but if you want the latest and greatest it's up there for you.

Max, Could you share with us which version of Mastercam you're using? That certainly sounds like an issue, but it would help if we knew which version you were able to recreate this issue in. Thanks,

Srinu, I'm afraid the CHook API is too big, too fluid, and too complicated to really make that reasonable right now. In a perfect world we'd love too, but the CHook API changes so much from version to version that we'd have to spend weeks every release just making sure the examples were up to date and working. The NetHook API is easier to provide examples for because it's much smaller and changes to it are much more infrequent. That's not to say it isn't something we haven't considered and that we definitely won't do it, but I don't think you'll see anything like that in the short term. Hope that explains things a bit,

Third Party Developers, As of this morning, we have uploaded a short survey that we would like to invite you all to participate in. It’s only a few questions, but your responses will go a long way towards helping us plan a few API changes in upcoming releases of Mastercam. So please, if you have the time, we would encourage all of our third-party developers to participate. The survey will run until Friday, 11/16/07, at 5:00 PM EST. Here’s the link: http://vovici.com/wsb.dll/s/a667g2e6e6 Thank you for time & participation,

Ekke, The good news (depending on how you look at it) is that there will not be a NetHook 3.0 for X3. The different versions of the NetHook APIs correspond to updates of Microsoft's .NET environment, not versions of Mastercam X. That said, there will be some incremental enhancements to the NetHook API for X3. I can't go into specifics because we're not far enough along in the development cycle that I can say for sure what will make it in and what won't. But in a general sense I would certainly expect some enhancements for X3 and continued bug fixes. Thanks for the interest - hopefully we'll have more to share at a later date.

Jure, Let me see if I can tackle some of those questions for you... 1) The reason you don't see the Excel window open is because the API opens it as a process, sans any sort of UI. 2) That's a good question... in theory, when you call the Close method it SHOULD kill the process. There may be a problem there worth investigating... 3) I'm not sure if we've exposed enough functionality for you to be able to create a New file as opposed to opening an existing one. I can look into this for you. I suppose a good work-around in the interimn would be to save off a blank excel file and use it as a template for starting up Excel. 4) That is another case of functionality we simply haven't exposed through the API. That's a little more advanced, and I can't say for sure one way or another if that's ever something we would expose. However, if that's a must-have for you I'm sure .NET exposes a way for you to get more out of Excel from within your own app instead of accessing it via our API. Perhaps that would be a better solution for you in the interimn... ? Hope that helps,

Jure, Roger was dead on with the rest of it in his post above. Thanks Roger.

Jure, I think I may have an idea as to why this is happening for you. The 'name' field in a COperationRef class is a bit of a misnomer... what's displayed in the Operations Manager as the 'name' of an operation is actually a dynamically built string based upon the the operation's parameters and / or creation number. In that sense, what you see there isn't really a name so much as it is an identifier. The 'name' field in the COperationRef constructor is actually comparing against the operation's comments field, which used to be used as a way for user's to name and identify their operations from one another. So in order to find a matching operation by name, it has to match whatever string is in the comments field of that operation. That would explain why the operation ref object you're getting back isn't what you expect. Now, that said you should still be getting back a default CToolRef object, so I'll take a look at that as well. I'll get back to you...

Jure, I'll take a look at it and see if I can come up with something for you. In the meantime, if you can answer this question for me it may help to shorten the debug time... is the 'operationTool' member null at the point where you reference the 'operationTool.toolComment'? Do you do any checking for it? Can you access anything else in the 'operationTool' member (slot, diameter values, etc.)? I'll get back to you as soon as I can scrounge something up,

Jure, That should definitely work, so long as there is actually a tool loaded into the operation. It's entirely possible that an operation may not have a tool associated with it yet or may have been just created and wouldn't have a tool loaded into it yet. If either of those things happen to be the case, then what you'll get when you access "opRef.operationTool" is a default tool. If you're seeing something completely different, feel free to let us know...

Pokemon, I've read (and reread) what you're going for here, and I think I'm starting to understand what you're trying to do. More importantly, I think I'm beginning to figure out why the above code isn't working for you. It looks as though the code you've written above assumes that the BasePoint is somehow changing as you loop through and increment High. However, that's not the case. Conceptually, the BasePoint is like the anchor of a solid. So it's never going to change unless you actually move the solid. In the case of a pyramid, that BasePoint is going to represent the center point of the base. Pokemon, it sounds like what you REALLY want is a way to take a 2D slice of a solid (and maybe other geometry as well) at a given Z-Depth - I assume for the purposes of creating a reference image or something? Assuming that's the case, I think trying to do it manually through the API probably isn't the easiest way to go about it. Let me know if that's really what you're looking for, and in the meantime I'll see if I can talk to some people here to try and figure out the best way to get what you're looking for. I'll get back to you in a bit...

No problem, Pokemon - glad to help. Hope it'll get you moving in the right direction again. Happy coding... !!

Pokemon, What you get back from the GetSolidGeometry() method is an array of SolidGeometry objects. The origin of a SolidGeometry object is in the BasePoint member variable. So, you could access the origin of each solid object like this... code: Dim FoundSolidGeometry() As SolidGeometry = SearchManager.GetSolidGeometry() Dim SolidItem As SolidGeometry Dim SomeValue As Integer = 2 For Each SolidItem In FoundSolidGeometry If SolidItem.BasePoint.z > SomeValue Then ' Do Some stuff... Else ' Do Some different stuff... End If Next Hope that helps...

Pokemon, Okay, so I threw together a little level switching application for you. It's a little bit more complicated than what you were looking for, as it always for five customized levels as opposed to the hard-coded five levels you were thinking of using, but doing it this way served as a better example. This was built to target the X2 MR1 NetHook 2.0 API, so you would need to build it against that version and run it yourself - be sure to add your references to the solution appropriately. Link to the project: Level Switching Tester App The application's Run method is fairly simple - it just creates the windows form and displays it modelessly. Here's the main application class code: code: Imports Mastercam.App Imports Mastercam.App.Types Public Class Class1 Inherits NetHook2App Public Overrides Function Run(ByVal param As Integer) As Mastercam.App.Types.MCamReturn ' Create the form object Dim MyForm As Form1 = New Form1() ' Display the form modelessly MyForm.Show() End Function End Class Now, the meat of the code is actually in the message handlers of the form itself. I set up the whole app to be button driven, so all of these methods are run by the clicking of a button. You could do it via the switching of items in a combo box or whenever the focus is lost in one of those controls, but this just seemed easier for the purposes of example. The code is pretty straightforward. code: Imports Mastercam Imports Mastercam.IO Imports Mastercam.Database Imports Mastercam.Database.Types Imports Mastercam.Support Public Class Form1 Private Sub TurnAllLevelsVisibleBtn_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles TurnAllLevelsVisibleBtn.Click ' Make all the levels visible TurnAllLevelsVisible() ' Make sure to do a regenerate of the display list when we're done ' so that we can see the changes GraphicsManager.Repaint(True) End Sub Private Sub SetVisibleLevelBtn_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) ' If the first level option is set... If ComboBox1.SelectedIndex = 0 Then ' Get the value from that level option numeric control Dim Value As Integer = NumericUpDown1.Value ' Render all of the levels invisible TurnAllLevelsInvisible() ' Then make only that level option's value visible LevelsManager.SetLevelVisible(Value, True) ' Finish it off with a regen of the display list GraphicsManager.Repaint(True) ElseIf ComboBox1.SelectedIndex = 1 Then Dim Value As Integer = NumericUpDown2.Value TurnAllLevelsInvisible() LevelsManager.SetLevelVisible(Value, True) GraphicsManager.Repaint(True) ElseIf ComboBox1.SelectedIndex = 2 Then Dim Value As Integer = NumericUpDown3.Value TurnAllLevelsInvisible() LevelsManager.SetLevelVisible(Value, True) GraphicsManager.Repaint(True) ElseIf ComboBox1.SelectedIndex = 3 Then Dim Value As Integer = NumericUpDown4.Value TurnAllLevelsInvisible() LevelsManager.SetLevelVisible(Value, True) GraphicsManager.Repaint(True) ElseIf ComboBox1.SelectedIndex = 4 Then Dim Value As Integer = NumericUpDown4.Value TurnAllLevelsInvisible() LevelsManager.SetLevelVisible(Value, True) GraphicsManager.Repaint(True) End If End Sub Private Sub TurnAllLevelsVisible() ' Get all of the active levels in the level manager Dim LevelNumbers() As Integer = LevelsManager.GetActiveLevelNumbers() Dim CurrentLevelNumber As Integer ' Make each of the active levels visible For Each CurrentLevelNumber In LevelNumbers LevelsManager.SetLevelVisible(CurrentLevelNumber, True) Next End Sub Private Sub TurnAllLevelsInvisible() ' Get all of the active levels in the level manager Dim LevelNumbers() As Integer = LevelsManager.GetActiveLevelNumbers() Dim CurrentLevelNumber As Integer ' Make each of the active levels invisible For Each CurrentLevelNumber In LevelNumbers LevelsManager.SetLevelVisible(CurrentLevelNumber, False) Next End Sub Private Sub MoveGeomToLevelBtn1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) ' Get the value of the level option #1 Dim Value As Integer = NumericUpDown1.Value ' Get all of the selected geometry in the part Dim SelectedItems As SelectionMask = New SelectionMask(True, True, False) Dim SelectedGeometry() As Geometry = SearchManager.GetGeometry(SelectedItems) Dim GeometryItem As Geometry ' Set each of the selected geometry items to the level option #1 level value For Each GeometryItem In SelectedGeometry GeometryItem.Level = Value GeometryItem.Commit() Next End Sub Private Sub MoveGeomToLevelBtn2_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Dim Value As Integer = NumericUpDown2.Value Dim SelectedItems As SelectionMask = New SelectionMask(True, True, False) Dim SelectedGeometry() As Geometry = SearchManager.GetGeometry(SelectedItems) Dim GeometryItem As Geometry For Each GeometryItem In SelectedGeometry GeometryItem.Level = Value GeometryItem.Commit() Next End Sub Private Sub MoveGeomToLevelBtn3_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Dim Value As Integer = NumericUpDown3.Value Dim SelectedItems As SelectionMask = New SelectionMask(True, True, False) Dim SelectedGeometry() As Geometry = SearchManager.GetGeometry(SelectedItems) Dim GeometryItem As Geometry For Each GeometryItem In SelectedGeometry GeometryItem.Level = Value GeometryItem.Commit() Next End Sub Private Sub MoveGeomToLevelBtn4_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Dim Value As Integer = NumericUpDown4.Value Dim SelectedItems As SelectionMask = New SelectionMask(True, True, False) Dim SelectedGeometry() As Geometry = SearchManager.GetGeometry(SelectedItems) Dim GeometryItem As Geometry For Each GeometryItem In SelectedGeometry GeometryItem.Level = Value GeometryItem.Commit() Next End Sub Private Sub MoveGeomToLevelBtn5_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Dim Value As Integer = NumericUpDown5.Value Dim SelectedItems As SelectionMask = New SelectionMask(True, True, False) Dim SelectedGeometry() As Geometry = SearchManager.GetGeometry(SelectedItems) Dim GeometryItem As Geometry For Each GeometryItem In SelectedGeometry GeometryItem.Level = Value GeometryItem.Commit() Next End Sub End Class That should just about do it!! Hope the example helps (you and anybody else who's interested), and if you need any additional help let me know.

Pokemon, Are you still having trouble with this? I'll throw together a little sample app that may be of some help if you are... let me know. Sorry for not being able to get back to you sooner,

Pokemon, I'm happy to try and help - let's see if we can't figure out what's going on here. First off, I'm a little confused by what you're trying to do here. The first chunk of code you've got there is going to set all of the level names for levels 1 through 5 to an empty string and make them all invisible, correct? But then the second chunk of code goes through the items in a Combo Box (I think... ?) looking for the string "Level 1", and if found makes levels 1-5 invisible and level 1 visible again. The two bits of code don't quite seem to make sense together... could you maybe explain what you're trying to do in greater detail? If we could better see the end goal, we might be able to see where the code's gone wrong for you.

Pokemon, I assume your "Line" variable is some sort of an Array or ArrayList (let's just call it a collection)? Working from that assumption, what's probably happening is the compiler doesn't realize that the items in your collection are all LineGeometry objects. Try casting your objects like so: code: while m < a LineGeometry CurrentLine = Line(m) CurrentLine.Commit m += 1 End while See if you have better luck with that. Feel free to come back if you have any further questions.

Titus, I think the question comes down to what you're trying to do. Obviously now we're more in the realm of CHooks than NetHooks, but I think I can probably swing that too. Could you be a little more specific? Are you having trouble getting Mastercam to launch your CHook wrapper from a different directory? Or are you having trouble getting your CHook wrapper to load the .NET library from a different directory? Either way we should be able to help you out. Let me know,

Titus, Managing versions is tough, and I feel your pain. But I'm afraid the NetHook API doesn't quite work like that. See, each build of the NetHook API is tied to a specific release of Mastercam. The December 2006 build of the NH API is the X2 SP1 build, which will only work properly with Mastercam X2 SP1. The September 2006 build is probably the right date for Mastercam X2. The changes in the API you cited would seem to echo that. What that means is you're not going to be able to ship an updated version of the API with your app. You're either going to have to not use aspects of the API that are specific to, say, X2 SP1 and beyond, or you're going to have to tell all of your users that your app will only run with Mastercam X2 SP1 or later installed. (The API's are always backwards compatible between major versions - so if you build an app for X2 SP1, you're guaranteed it will work for X2 MR1, X2 MR2, etc.) Good rule of thumb? You'll generally want to set up your build environment to use whatever API is in the Mastercam directory you'll be testing with. That way you never need to worry about the problem you're having. Also, it sounds like your Mastercam installation doesn't have the X2 Service Pack 1 installed - you should go out and get it!! Let me know if you need any more help,

Hi Kelly, It sounds like you may have a couple of problems there. As for the first one, why you're having trouble debugging through Visual C# Express, I'm not entirely sure. I'm not aware of any specific reason why VC# Express wouldn't work - we did some limited in-house testing with it, and it seemed to work and debug in Mastercam fine. It might just be a bug in the API you've stumbled across, so if you haven't already you may want to try downloading and installing the Mastercam X2 SP1 off the main page's download site: http://updates.mastercam.com/x2/sp1/master...vicepack001.exe As for the second problem, being able to pick and choose between all the different examples, the 'switch' lies in the code and not in the DLLs you reference. You have to add a reference to the NETHook2_0.dll and you have to have your main Mastercam directory setup as your project's Working Directory. In order to switch examples, the first thing you're going to need to do is decide which example you want to run. Open that example's file in Visual Studio (for example, section 2's "2.2 - The FileManager Class.cs"). Take note of the name of that example's class (in this case, it's "FileManagerExample"). Now, in the "1 - Basics" section of the solution manager, open up the only file in there - "1.1 - Intro and The App Classes.cs". This file is the driver for the application. It actually has all the hooks for a NetHook app, and it just calls any of the examples and runs them. So, in that same file, scroll down to the Run() method (should be line 77), and replace the line that runs the Dialog Manager example with whichever one you've chosen (for the purposes of our example, "FileManagerExample"). In other words, this little chunk of code... code: public override MCamReturn Run(int param) { ... return DialogManagerExample.RunExample(); } ... should now look more like this chunk of code... code: public override MCamReturn Run(int param) { ... return FileManagerExample.RunExample(); } Hope that helps clear a few things up for you - let me know if that helps or not. Happy coding!!

Hi again Keta, quote: Does NetHook API also support lathe tools? Not in the current version of the API. It's on the list of things that would be nice to add in the future, though, and we're hoping down the road this is something we might be able to add. quote: How is it possible to set feed and speeds to a tool if I want import a new tool object? Surprisingly enough, it isn't possible as of right now - although it should be. This is something that must have slipped under the radar for the first 2.0 version of the API. It'd be a useful addition, though, so I put it on the list of things to add. Look for feeds and speeds parameters in the tools base class in a future version. Hope that answers your questions, and thanks for the feedback.

Keta, You can absolutely import tool data through the NetHook API, although you won't get the same level of customization and detail that you would through the CHook API, however, and it works very differently. I'll assume you already know how to set up and get a NetHook app running (if you don't, no worries - I've included some links that should be able to help you get started below), so I'll just cut straight to working with tool objects in the NetHook API. Everything in the API is represented by objects, and tools are no exception. Say you wanted to import a new Drill? You'd probably want to do something like this (C# pseudo-code): code: { ... if (!MachineDefManager.IsCurrentMachineGroupMill()) MachineDefManager.CreateMillMachineGroup(); DrillTool MyTool = new DrillTool(); MyTool.Diameter = 1.0; MyTool.CornerRadius = 1.5; MyTool.Name = "My 1-inch Drill Tool"; ... MyTool.Commit(); ... } It's as simple as creating a new tool object, filling in the parameters, and calling the 'Commit()' method on it to submit it to the database. It should be noted however, like I said above, you won't get the same level of detail. The editable parameters in a NetHook tool object include: Diameter Corner Radius Number Length Offset Diameter Offset Length Flute Length Shoulder Length Name If you need to be able to edit and import more data than that, then the NetHook API won't be able to support your needs just yet. In case you need any more additional help, or you want some tips / pointers on how to start your own NetHook app, check out the NetHook Samples & Examples project up on the main Mastercam site: http://www.mastercam.com/Support/Downloads....0_Examples.zip Hopefully that's enough to get you started and answer your questions - if you have any more questions, feel free to post them.

Jure & co., Why don't we try this one more time... ? The NetHook 2.0 Samples and Examples project can now be found on both the Extranet developer's page and in the main downloads section of Mastercam.com. Here's the link for the main Mastercam site's downloads page - you're looking for the "NetHook 2.0 API Samples & Examples Project" download. Mastercam.com Downloads Page: http://www.mastercam.com/Support/Downloads/Misc/ If you had trouble getting it the first time, by all means try again - I've tried downloading it and setting it up myself, and can verify it works. Sorry for the inconvenience everybody. Happy coding!!