Back in the version 9 sdk the documentation files were in a sub folder of the sdk Chdocs9. You can find them there. In version X the files were rewritten and they are now in one chm file.

job_setup no longer seems to work in X. Stock is setup individually for each machine group. Look at the definition for the file Groups_CH.h specifically: group_list->op_group_info->group_pg3 Bryan

if you use the Disk Management solution thoskins outlined XP will remember the drive letter. I've done it with my mp3 player and thumbdrive.

Bryan

try using insert pattern instead. It uses the current view. If that doesn't work merge your part then xform it between views.

If you want the finished chook dll for this code send me your email and I can send it to you. Bryan

Here's some code for a function for a v9 chook that should get you started. It only works for mill not design. For some reason the named_view_manager function is disabled in design. It prompts the user to selects a named view icon. I don't know how to get to do a list. sorry. When I call named_view_manager with VWMGR_MENU it doesn't return a view. Sets the tool, construction, and graphic views. Then looks for and parses a list of levels in the comment section of the view. comment example: 231, 240, 250 code: void my_wcs(void) { view_ent v; boolean succf = FALSE; byte new_level = 0; char comment_copy[256]; char * comment_ptr; int i; memset (&v, 0, sizeof (view_ent)); /* draw named view icons and select */ named_view_manager (&v, VWMGR_SELECT, "", &succf); if (succf == TRUE) { /* set system views to selected view */ named_view_manager (&v, VWMGR_CPLANE, "", &succf); if (!succf) return; named_view_manager (&v, VWMGR_TPLANE, "", &succf); if (!succf) return; named_view_manager (&v, VWMGR_GVIEW, "", &succf); if (!succf) return; /* turn off all levels */ for (i=1;i<255;i++) vis_level = FALSE; /* does comment have levels? */ if (strlen(v.comment) > 0) { strcpy(comment_copy, v.comment); /* parse comment */ comment_ptr = strtok(comment_copy, ","); if (comment_ptr != NULL) { /* set first number as main level */ new_level = atoi(comment_ptr); if (new_level >= 1 && new_level <= 255) main_level = new_level; /* turn on other levels */ comment_ptr = strtok(NULL, ","); while(comment_ptr) { new_level = atoi(comment_ptr); if (new_level >= 1 && new_level <= 255) vis_level[new_level] = TRUE; comment_ptr = strtok(NULL, ","); } } } /* make sure main level is always visible */ vis_level[main_level] = TRUE; rebuild_graphics(); fit(); } }

Add code: extern DllImpExp group_list * group_list_ptr; and you can access the pointer directly. Bryan

It should be possible. I've done something similar in the past. Mine prompted for a level and looked for an associated view. A simple way for your chook to associate the view with a level either by naming the view the same as the level. Or sticking the level(s) in the views comment. Is this for V9 or X? Bryan

from the what's new file in mr1 quote: Surfaces Extensive work has gone into rewriting and improving surface trimming, creation of edge curves on surfaces, surface flowline creation, and creation of curves at surface intersections. All of these changes should make it easier for you to create, edit, and manipulate models as needed for machining. Future releases will contain even more improvements to surface modeling. Guess rewrite didn't work

For adding tools in v9 chooks look at tool_manager function in m_assoc.h. The example file testassc.c has some limited examples on how to use this function. Bryan

Hey Roger, Thanks for what help you can give me. Thats my problem. Back in 9 calling it with VWMGR_SELECT would display the view icons and return the v. Now it does that dialog box and you have to press the arrow to get to the icon selection. My assumption is there supposed to be a difference between SELECT and GET. One would goto the selection dialog box and the other to the icons. Especially since you can go straight to the icon selection from the named view manager dialog box. In the docs they're both described as going to the icons which I assume is a mistake. Also when called with VWMGR_GET and VWMGR_MENU the function never returns. It just hangs the chook. Well thats not totally true, it will return, without setting v, if you close mastercam. Bryan

frustration ... level ... a .. 9.5 ... Can someone at MC answer what's up with named_view_manager? In 9 NVM with the VWMGR_SELECT displayed the view icon, you selected the one you want and it returned the view #. Straight and simple. In X it displays some named view list select crap. To select by icon you have 2 or 3 more mouse clicks. Also VWMGR_GET, which is described as working the same as VWMGR_SELECT does NOTHING. doesn't display, doesn't return, it just hangs. Same with VWMGR_MENU, after exiting the named view dialog box it just hangs, doesn't return a value, doesn't return at all. Bryan

Heads up to programmers. I don't know if this is a bug or how it supposed to work but the variable h_inst_chook will give different values depending on how the chook is run. If run straight and normal from alt-c you get the hinst for the dll. If it's run off a function table, ie the toolbar, you get the inst of mastercam.exe. Either a bug or my own stupidity it kinda bit me in the xxxx today. Bryan

For heavy database stuff I've just used a database or csv/text file with a same filename (as I mentioned above) as the mc9 file. For simple stuff I just stick it in a note. This is usually data I don't need to read back out or manipulate too much. These are usually simple notes from the designers or such. But... I don't see why you couldn't stick it on a separate layer that isn't normally used. Then just loop through the entity database an look at any notes. Stick some kind of unique identifier at the beginning of the text ("file list:" or "fl3rev2" or whatever ) so that it can be distinguished from the user created notes. And if you really want to hide it, blank it out. But if it is blanked it can't be saved out with File->save some. And here's a real secret I haven't told many people. If you have data that needs to be associated to a level, and be saveable with 'save some', and not on the actual level itself. Shove it into the 'level set' field of the level manager. The Level name and Level set together have a text limit about 280 to 300 character depending on the version of MC. But formated right 200 characters can represent ALOT of data. The nice thing is when a 'save some' is done the Level Name and Level Set (and your data) are saved with it. Bryan

quote: 3) Is there a way of saving data with the mastercam part so that the next time the user loads the same part I can retrieve the data? What kind of data? One trick I've used is to create a data file in the same directory with the same name but different extension. Then the chook only needs to replace the extension and look for the data file. part file: c:jobssomedirectorypart132.mc9 Data file: c:jobssomedirectorypart132.dat If you need to data to move with the file I've been known to hide it in the mc9 file at times. Bryan

Had a 20g usb hardrive/mp3 player 'brick' ( still have, don't use) worked ok for many years. Tried a 1gig thumb drive liked it a lot. Eventually gave it to my wife. Just bought a 1gig thumb drive / mp3 player /fm radio a few months ago. Absolutely love it. I can transfer files between work and home, listen to music, and don't have to carry a 'brick' around to do it. Its a Creative MuVo TX FM 1 GB MP3 Player if your interested. Bryan

We quite regularly use all levels in our die designs. We do something similar to Thad with each detail being on its own level. The 2 billion levels in X are going to eliminate a lot of headaches for our engineers. Bryan

HAPPY DANCE. Thanks Pete it worked. Bryan

BUG!! die die die

release

Do any of the chook guys know why when I call translate_silent McX crashes. Here's the code. I'm trying to move all selected entities from point a to point b. Similiar code works fine in v9. Any help would be appreciated. Bryan code: MC_BOOL succf = TRUE; DB_LIST_ENT_PTR *eptrs; int num_eptrs; char pt_option; p_3d from_point; p_3d to_point; select_ents ("Select entities to copy. ", ALL_ENTITIES_MASK, &succf, PRESEL_ON, &eptrs, &num_eptrs); if(!succf){return;} /*GET FROM POINT */ point_proc( "Enter the point to translate from.", &pt_option, from_point, &succf); if(!succf){return;} /* GET TO POINT */ point_proc( "Enter the point to translate to." , &pt_option, to_point, &succf); if(!succf){return;} translate_silent( null_eptr, TRUE, 1, from_point, to_point, constr_view_n, constr_view_n, &succf); repaint_graphics();

I heard bug fixes will be released for non maintenance for X. Which I'm all for. BUT if you look at the release history for 9 I don't have high hopes. For non maintenance sp2 was released 2 years ago. And a post processor and vb update about a year and half ago. In that same time there were 8 maintenance releases. Which, fair enough, is what people pay maintenance for; regular feature upgrades. I'll even allow some room for X being worked on in the last year or so. BUT in the last two years we haven't see ANY non maintenance related bug fixes that would have been rolled up in maintenance. Bryan

quote: You don't want any bugs fixed in an MR release? Bug fixes for maintenance items in a MR make sense. Bug fixes for non-maintenance items that affect maintenance modules in a MR make sense. Bug fixes for non-maintenance items rolled up into a MR so there aren't a ton of update files for maintenance people make sense. Bug fixes for non-maintenance items only being release for maintenance doesn't and goes back to quote: It's not our policy to try to force a customer into purchaing a maintenance contract by withholding bug fixes. Since a bug fix for a non-maintenance item has to be applied to both code bases (m and non-m) I don't see a problem with it included in a MR. But at every MR release shouldn't there be at least a bug fix release for non-m? quote: Testing is much more time consuming than most people realize. Smaller release cycles make for easier beta testing. Bryan

Thanks doug. Bryan