Jump to content

Welcome to eMastercam

Register now to participate in the forums, access the download area, buy Mastercam training materials, post processors and more. This message will be removed once you have signed in.

Use your display name or email address to sign in:

Mike Crivello CNC Software Inc.

CNC Software
  • Posts

    35
  • Joined

  • Last visited

Recent Profile Visitors

362 profile views

Mike Crivello CNC Software Inc.'s Achievements

Newbie

Newbie (1/14)

0

Reputation

  1. 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.
  2. 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,
  3. 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.
  4. 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,
  5. 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,
  6. 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,
  7. 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.
  8. 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,
  9. 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...
  10. 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,
  11. 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...
  12. 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...
  13. No problem, Pokemon - glad to help. Hope it'll get you moving in the right direction again. Happy coding... !!
  14. 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...

Join us!

eMastercam - your online source for all things Mastercam.

Together, we are the strongest Mastercam community on the web with over 56,000 members, and our online store offers a wide selection of training materials for all applications and skill levels.

Follow us

×
×
  • Create New...