yes, no, depends. If you're trying to pass more variables to a postprocesor; 1) You can try adding extra 'stuff' in the ncfilename when you call run_post_exe_dll and then access that via snamenc variable in the post. file.nc becomes file123.nc in the post. Then the 123 can be left alone or removed. do this in the post pprep$ function before the nc file is open. 2) A chook could write 'stuff' to a plain text file. Then access it via the post functions rbuf and wbuf. 3) Modify and existing operation or add a 'dummy' one like a manual entry. Then you could access the comment or other variables of the operation from withing the post. If you're creating your own postprocessor dll, a mp.dll replacement. Variations of above work just as well. 1) chook.dll calls run_post_exe_dll and 'stuff's the nci, post, nc filename which is then accessed/modified by your_mp.dll via the post_args variable. 2) chook.dll write to a file or database or something and your_mp.dll reads the file. 3) Stuff info in various places withing mastercam that both dlls can access; an operation, operation comments, group names, machine group comment, level names and levelset, various prefix and suffix variables, a dummy note on an empty level or blanked/hidden. And so on. Bryan

Roger, I've always wondered, is this a bug or feature? (crickets) It's been a while since I played with this but I seem to remember the logic didn't follow through when posting via Mastercam vs via a chook. With fastmode on or off: 1) bug1 (edit) + mc (no edit): no editor 2) bug1 (no edit) + mc (no edit): no editor 3) bug1 (no edit) + mc (edit): editor 4) bug1 (edit) + mc (edit): editor 5) bug1 (edit) + chook (no edit): editor 6) bug1 (edit) + chook (edit): editor called twice 7) bug1 (no edit) + chook (no edit): no editor 8) bug1 (no edit ) + chook (edit): editor in 1-4 above mc handles any discrepancies or overides bug1. Shouldn't bug1 (like the other bus#s) be honored when fastmode is turned off (#1 above) ? in 5-8 bug1 and the chook act independently of each other. Shouldn't bug1 be ignored when fastmode is turned on (5 and 6 above)? Bryan

I would like a pony and full access to Mastercam's source code. That's a very big request. Here's a very abbreviated list of functions to look at to get you started. get_ent To search through MC geometry select_ent and related functions: get user selected entity or entities. operation_manager create, add, delete modify operations. postOps and/or run_post_exe_dll generate nci and post nc code through post processors. Bryan

pma, check that bug1$ in the post is set to 0. Mastercam will still try to open the nc file if it's set to 2. code: bug1$ : 0 #0=No display, 1=Generic list box, 2=Editor Bryan

Based on the way the levels move back to under level 255, striate to different levels not just to one level. It looks like Mastercam is probably casting (accidentally) the level, an int variable in mcx, as a byte, mc 9 variable type Hey Mastercam, update your function prototypes for the drag function. Bryan teh had the same thing happen to his own chook.

Assuming MCX SDK: Make sure you have #include "m_mill.h" in your source file and add MCMill.lib to the linker Additional dependencies. Project -> properties-> Linker -> input -> Additional dependencies. Bryan

Bye-the-way if you want to recreate the crash manually: 1. copy a line of text with 200 character 2. open level manager 3. paste the text in name 4. paste the text in levelset 5. hit ok. Works in v9 and mcx Bryan

from LevNames_CH.h DllImpExp MC_BOOL set_levname ( int lvl_no, char *new_level_name); and from CGUI_ch.h extern DllImpExp MC_BOOL get_levname(int leveln, short maxLen, char* ptr); also watch out the limit for a [level name text] + [levelset text] is #define NAME_LENGTH_MAX 301 MCX crashes real pretty it you feed it more than that. Bryan

code: DllImpExp void OMinitOpManTree( char collapse_op, char collapse_group); This function call does work. But it seems to be a bit 'nuke' option to reinitialize the entire tree.

MasterShake, Does OMrefreshOpManTree work for you? One of the MC guys had me try it last week and it only works every other time my chook is called. OMrefreshOpManTree (supposedly) only works when it sees a change in the operation list and for some reason reorder_operations doesn't mark the list as changed until my chook exits. So OMrefreshOpManTree fails. When the chook is run the 2nd time, the list is marked as changed (from the previous run), and it works. They seems to be doing much better with the MCX SDK headers and documentation than they did with 9. So here's hoping stuff like this is added to the next release.

Try code: opl->op.db.select_flag == TRUE From the op_list structure code: boolean selected; // not used - see ent.u.op.db.select_flag Bryan

I think reorder_operations might be working, sort of. Last night, I ran the function, and then manually saved and reopened the file. The ops were in the new order. Mastercam doesn't seem to be updating the operation manager. Anyone know the function to force update/refresh/regen the ops manager display? Or am I supposed to set some variable so that it refreshes when the function is called? Thanks for any help. Bryan

Anybody know how to reorder operations in X. Back in 9 I'd just call list_op_reorder but this function has disappeared. I found reorder_operations in the docs but when I feed it a list of op idns in the order I want nothing happens. Bryan

Thanks Roger. I figured it was something like that. Bryan

The biggest problem I've seen is a change in X where if the n (n$) varible isn't formated correctly it leads to a lot of blank lines being output. It's easily fixed. relavent emastercam thread

Thanks Roger. I was afraid of that. I've been playing around with posts, chooks, and whatnot all day and I think I have a solution that lets me have the best of both worlds. So the lack of an internal switch isn't too big a deal. As a matter of curiosity? When mp.dll loads and parses the post does it read/set those variables and then supersedes them with the control def values? Or does the dll just set them off the control def and ignores the initial assignment statements in the post altogether? Bryan

Currently I'm running a single NCI file thru multiple posts with run_post_exe_dll for a custom multipost chook. This worked just dandy in 9 but the way X works by overriding the post values with the Machine Def/Ctrl Def values is causing me problems. Is there a way to tell the post processor to ignore the Machine/Ctrl defs values and only initialize the values from the Post when calling run_post_exe_dll? The only solution I've found is to re-reset the values in psof$ of the post processor. Which basically neuters the users ability tweak setting when posting via the ops manager. Something I don't really want to do. Bryan

oops nci_manager with NCIMGR_POST_ALL or NCIMGR_POST_ONE should do it also.

For chooks postOps function will generate an nci file. It'd look something like this: code: post_dlg_settings ps; /* create and save nci */ ps.save_nci_file = TRUE; ps.overwrite_nci = TRUE; ps.editNCI = FALSE; /* don't create nc */ ps.save_nc_file = FALSE; ps.overwrite_nc = FALSE; ps.editNC = FALSE; ps.send_to_machine = FALSE; ps.export_oplist = TRUE; ps.export_prm = TRUE; ps.wcs_1014 = FALSE; ps.descriptor = FALSE; /* generate nci files */ postOps( &ps, postprocessor, destinationdir, FALSE, /* CALL POST DIALOG */ FALSE); /* DISABLE POST BUTTON */ You can later call the run_post_exe_dll function to run it through a post processor.

I'd contact you dealer about getting a v9 post proc cd. (Searchable pdfs, yeah) They're probably giving them away now that X is out. As for parsing you could probably fake it with: strstr -> is basically instring. brksps -> will break a string into two strings at a position. Bryan

2 billion levels Bryan

gl_dynamic_shade probably isn't the right variable. There seems to be a hidden variable gl_shading_on that does work. try adding code: extern DllImpExp MC_BOOL gl_shading_on; to your code and check against it. Bryan

You can install it off any v9 installation disk.

I'm guessing unless you're selecting your point off another entity when you select a point off 'in space' Mastercam will interpret your point to be in a plane defined by the Z construction Level. Also as a side note; in select_ent above you can force it too select only lines by changing ALL_ENTITIES_MASK to L_ID. That is, unless you're trying to get splines and stuff too, then my bad. sorry.

Try changing your return to: return MC_UNLOADAPP; That should unload the dll. Having the MC_RETURN in your return is probably confusing MC. Also MC won't unload a dll if you're using loading it via a function table. If you don't know what that means then you're probably not using one.