Hey Ron. Beat me to the punch on this one. Still, solid answer.

Ron "teh Crazy^Millman" has the right of it here. By clicking on the left side of the segment in the datagrid, you can delete it with the delete key. That works better than zeroing out the segment.

Carl, When you update a post, the old version is left around, with an extension on it's name (like .pst_vX or .psb_vX2). Check your system. The files you need might be hiding there like that.

This is addressed in the next "Tech Talk" newsletter. The crux of the problem is that the error message is incorrect. The file does not exist in X3. It isn't supposed to.

Libraries are not identical between releases. We rebuild, and this means that any change in a header file is going to change call signatures, and functions are not guaranteed to even be in the same place. Also, as markov said, the definition of basic structures and classes (like ent and operation) change between releases, often growing in size as more data is added. You need to rebuild with the SDK for the version you are aiming your chook at.

That parameter appears to be unused. I know that in highfeed we don't use it, and instead calculate all cycle times as we go. In our own source code, I find no real references to it, so it will always be 0.0 (it's initialized). It looks like the sort of thing that was put in when somebody thought we'd do that, and then a better solution appeared and we did something else, but it was never taken out. Look elsewhere for your needs.

DMG Austin, Spindle speed doesn't vary in highfeed, but please send in the request to support. It's the best way to see about getting your feature into the product.

arenner, Roger knows that you know how to make a chook. What he's pointing out is that these dll's are also chooks, which mean the only function that they have exposed is m_main, just like the ones you make. When looking for function names to call into mastercam's code with, check the header files that ship with the SDK, but when looking to call into another chook, m_main is your boy.

Expanding on what Pete said, every piece of geometry has a unique id number associated with it too. Going through the database you could check for matches that not only had the same color, level etc., but also had identical id's and modification times. A high percentage of hits here, while not conclusive, would be indicitive.

Surface, I have an interest in your highfeed illegal arc warning. When does it happen? While highfeed is running, or when you post?

Michael, This is an often requested enhancement and is definately being looked at, but I am not allowed to give a time frame on when it might appear.

mpmcnc, Please send the part to QC. We're working on cleaning out some longstanding bugs in highfeed, and something could have easily been broken in the process. Thank you,

Roger is quite correct. A second issue is that you need to run a Release version of your chook with a Release version of mastercam. In VS2005, this can be set right next to the search field in the normal setup. Look for a little text field with the word Debug in it.

arrener, You've recompiled in 2005. It occurs to me that you may have missed something. If you: compile with the XMR2 sdk in VS2003 you should: run in XMR2 If you: compile with the X2 sdk in VS2005 you should: run in X2 you should not: compile with the XMR2 sdk in VS2005 nor should you: compile with the X2 sdk in VS2003 nor: compile with the XMR2 sdk but run in X2 etc. etc. etc.

Internal testing at CNC software seems to indicate that X2 will run on Vista, though its certainly possible that we've missed something. I'm not aware of any beta testers running Vista yet, so most if not all of the testing has been in house. That being said, Vista isn't generally available until Jan 30, so any computer you purchase before then will have XP on it.

To clarify, I was referring to McamNut's spindle speed problem. Appologies to any who were confused.

This problem is caused by a bug that crept into the release. Bugs are dasterdly. CNC Software is currently working on a fix for it. I am under the impression that InHouse Solutions has a version of MpMaster which will compensate for the bug.

Generally this sort of error occurs when one of the .dll files associated with mastercam (there's a bunch of them) is from a different version than another of the files. They can't communicate with each other then, because they're speaking a different language. (Linguistic drift happens quickly with computers, Latin->Spanish is more like X->Xmr1). The most likely cause is that IT installed something from a cdrom, and you're running something downloaded, or vice versa. Go to your mcamx directory in Windows Explorer, and click on the little grey bar that says type. This will seperate out the .dll files from the others. Look at the "Date Modified" column. If some of the dates are radically different than the others, this would tend to confirm the problem. In this case, you would probably be best served by either reinstalling that one component, or reinstalling mastercam. How long have you had this problem?

That's a common style of error for developers to get under certain circumstances, but highly unusual for an end user? Are you building a chook?

arenner, I haven't had a chance to try this, so I'll just fly some things for you to try. 1. Programming tip: code: (*arc).r is bad form. It's technically correct, just "bad" as in somewhat naughty. Better would be to see code: arc->r it's cleaner. This is especially true when you have something like (*(*(*a)..c).d, where it would be better to write a->b->c->d. It means the same thing. 2. As markov said: quote: You probably want to change the first line to a_2d arc; and call the funnction with like this constr_circle(end_pt, c, cw, min_radius, &arc, &succf); He's spot on about the memory corruption also. Pointers have to point somewhere! Whenever you decalare a pointer, make it point, even if you're just setting it to null, as in: a_2d * arc = NULL; or allocate the memory right then and there with: a_2d * arc = new a_2d; Remember to free any memory you allocate: code: delete arc; Anyways, the reason the function takes a pointer is that it is using an older C-style method of passing called "pass by pointer" where you pass the address of the variable who will hold the value. This is probably one of the older functions in the system. Tutorial here: Pass by pointer Ignore the author's comments about preceding the name with a "p." It's not universally accepted, though I know some people do do that. It isn't bad form, just not necessarily best practice.

We at CNC are using VS2005 to compile our X2 chooks. This is the plan going forward as well. MR2 was compiled with 2003, but we made the switch a couple of months ago. Substantial work has been done behind the scenes on the interface since then, and no effort is being made to be backwards compatible with VS2003 (it would be pointless). I would not be surprised if MCDialog was giving you trouble in VS2003. Personally, I would suggest moving to VS2005, and the X2 SDK, before releasing any chooks for X2. It'll save you a number of headaches. Best of luck,

Sonny has the right of it. Generally speaking, you want to change which fs the fmt for your variable points to, and not to touch the fs directly. If you do touch the fs, you edit every variable that uses it. For those following along in their post reference guide, we're in Volume 1, Chapter 9, pages 4 to 10. I'm using the Feb 2004 v9.1 guide myself, but this stuff hasn't changed since then. Oh, and welcome to the forum.

Here's a decent primer on the std::string class, which is what you want to end up using. It's far more powerfull than a simple character array: String Class Pay particular attention to these two entries: /*Character array to string*/ s = ch; //Converts character array ch into string s. /*String to character array*/ cp = s.c_str(); //Pointer cp points to a character array with the same characters as s. Conversion comes up a lot, and typecasting isn't always the best idea when using these what you'd end up with is code like this: code: #include <string> using namespace std; //... skipping stuff... string filen = "C:mcamxdirfile.mcx"; DoFileOpen(filen.c_str(), /*args*/);

You didn't allocate memory for your string. LPCTSTR refers to a string on the heap (dynamically allocated memory), so such assignment/allocation isn't going to work. The string type you've chosen isn't the best for what you're doing. There's quite a few ways to allocate a string, for instance: code: char s[] = "yadayadayada"; //simple ASCII TCHAR s1[] = _T("string"); //handles UNICODE too char * st = new char[10]; strcpy(st, "yelp!"); //deprecated string tempString; //stl::string tempString = "temp"; //allows assignment CString mfcString = "Microsoft uses these"; try something more like: char filen[] = "C:yadayadayada.mcx"[/indent]or [indent]code: TCHAR filen[] = _T("c:...");[/indent]which would put it on the stack instead (handling allocation for you) or even (cutting a step) [indent]code: DoFileOpen("C:yadafile.txt", /*more arguments*/);[/indent]cutting the entire allocation problem altogether. Remember also, you may need to double up on the char, because it's used as an escape character. E.g. "C:mcamxchooksmychook.dll" Here's a link to a more complete tutorial on the subject: Tutorial

Function prototypes are technically unnecessary in this example, but explode in usefulness the bigger your project gets, and it's best to get it out of the way, and the right habbits working from the get go. Here's why: You can't use a function before it is declared, and a prototype declares a function without defining it (writing it all out). Let's say you have a main, and then functions A and B. Under some control paths, A will call into B, and under others, B will call into A. Which do you put first? Without a prototype, there isn't a correct answer. With prototypes, the answer is that it doesn't matter. The variable in could have been named anything, I gave it a different name than myfile mostly to show you that it was local to the function readtext. One of the biggest newbie mistakes is to look at 2 different variables with the same name, and wonder why the data in them is different. It's because one of them lives inside one fuction, and one lives in another, and never the twain shall meet. The unsophisticated user assumes they are the same, but they're just given the same name. To move data around, we use function calls (arguments) and return the new data. As for how in is being used, the >> operator, also known as the stream extraction operator, pulls data from a stream, and sticks it into a variable (or another stream). Think of it as being a flow, much like you'd see 1+2+3 = 6, you can have in >> firstDouble >> secondDouble; to read two doubles from a stream. The assertion errors you're getting aren't supposed to occur, and aren't the couts. Try hitting "Retry" on the dialog that pops up, and seeing what it shows you. A bit hard to say what's wrong with you're setup for sure without more info.