Community Tip - If community subscription notifications are filling up your inbox you can set up a daily digest and get all your notifications in a single email. X
My program intent tis to create a Shrinkwrap of the current assembly.
I am using ProSolidShrinkwrapMdlnameCreate to create the SW. And setting options prior to the function call as shown in the examples. Export is working, but I need the Shrinkwrap to include a specific Csys. The csys is a specific name.
So to my actual issue - there are functions to set the options of the Shrinkwrap, and one is for including datum references - perfect!
ProShrinkwrapoptionsDatumrefsSet takes for the second argument a ProSelection * an array of Proselections.
Does anyone have an example where they have generated an array of ProSelection, using a selection in which they generated from a geomitem? (there are utilities in the Protk folder to find the csys by name and convert to sel) I have that.
Thanks for any Help!
Solved! Go to Solution.
This is pseudo code not compiled and tested, but should help
ProSelection selection;
ProModelitem modelitem;
ProSelection *p_sel_arr;
ProMdl model;
iint id,type;
ProCsys csyshandle;
// alloc array
tk_status = ProArrayAlloc (0, sizeof (ProSelection), 1, (ProArray*)&p_sel_arr);
// this is a model item as well
tk_status = ProCsysInit(model,geom_id,&csyshandle);
or
// by geom id most of the time feat id +1
tk_status = ProModelitemInit (model, geom_id, PRO_CSYS,&modelitem);
or
// if a feature was selected
tk_status = ProModelitemInit (model, feat_id, PRO_FEATURE,&modelitem);
// get the valid selection
tk_status = ProSelectionAlloc(NULL,&modelitem,&selection);
// add to array
tk_status = ProArrayObjectAdd((ProArray*)&p_sel_arr, PRO_VALUE_UNUSED, 1,&selection);
extern ProError ProGeomitemToCsys ( ProGeomitem *p_geom_item,
ProCsys *r_csys_handle);
/*
Purpose: Converts a coordinate system <I>ProGeomitem</I> handle to a
<I>ProCsys</I> handle.
Input Arguments:
p_geom_item - The coordinate system geometry item handle
Output Arguments:
r_csys_handle - The coordinate system handle initialized, based on the
input geometry item handle
Return Values:
PRO_TK_NO_ERROR - The function successfully converted the
geometry item handle to a coordinate system handle.
PRO_TK_BAD_INPUTS - The input geometry item handle is invalid, or does not
refer to a coordinate system.
*/
with this you can build the model item used in the selection, in an assembly you may need to add the comp path as well.
Thanks Aquamarine. You last statement, "with this you can build the model item used in the selection, in an assembly you may need to add the comp path as well." This is what I am looking for an example to do this, to create an array of ProSelection. The csys I am finding is a feature in an assembly. So does that mean I need to do the component path?
The selection is allocated with ProSelectionAlloc, here you specify the modelten as an input. If you create a SW from a Part, no comp path, if this (the csys) is at top level in an assy, no comp path. is the csys at member level you need the comp path.
If you have only one csys, then as far I know the array is also not needed, just the pointer to the selection object. Else you need to deal with ProArray.
good luck 🍀
The csys is is at top level in the assy, im hoping no comp path..
and I only have ovne csys- I have tried both - it just wont go. The functions all return 0 no error, still I get no csys.
a reasonably close example is : protk_appls\pt_userguide\ptu_mfg\UgMfgMillSeqCreate.c
ProSelectionAlloc after ProFeatereGeomItemVisit - lines 176-185.
ProSelection in ProArray and ProSelectionAlloc - line 314 - 339.
HIH.
God clues I worked hard with this code you pointed out. I was doing 95% of it so it was goiod confirmation. Whats getting me is that the definition has p_sel_array as a double pointer. ProSelection ** p_sel_array.
I dont understand why it has to be a **.
This is pseudo code not compiled and tested, but should help
ProSelection selection;
ProModelitem modelitem;
ProSelection *p_sel_arr;
ProMdl model;
iint id,type;
ProCsys csyshandle;
// alloc array
tk_status = ProArrayAlloc (0, sizeof (ProSelection), 1, (ProArray*)&p_sel_arr);
// this is a model item as well
tk_status = ProCsysInit(model,geom_id,&csyshandle);
or
// by geom id most of the time feat id +1
tk_status = ProModelitemInit (model, geom_id, PRO_CSYS,&modelitem);
or
// if a feature was selected
tk_status = ProModelitemInit (model, feat_id, PRO_FEATURE,&modelitem);
// get the valid selection
tk_status = ProSelectionAlloc(NULL,&modelitem,&selection);
// add to array
tk_status = ProArrayObjectAdd((ProArray*)&p_sel_arr, PRO_VALUE_UNUSED, 1,&selection);
Oh man - you made my day. My Coord system is finally appearing!!
I think it was the (ProArray*)&p_sel_arr, portion of the line, The rest I was already doing verbatim. Basically lost in pointer land.
tk_status = ProArrayObjectAdd((ProArray*)&p_sel_arr, PRO_VALUE_UNUSED, 1,&selection);
I thank you for your suggestion and also everyone else who has responded in this post, I was stuck for several days with NO progress.
Sample Script
# Get the current model FOO.ASM
set cur [ps_model cur]
# Create ShrinkWrap Obj
ps_shrinkwrap swObj
# Create 2 modelitems Objs
ps_modelitem CsysMiObj
ps_modelitem PlanMiObj
# Config 2 modelitems by name, one is a csys, one is a datum plane
CsysMiObj byname $cur csys acs0
PlanMiObj byname $cur surface a-top
# use this modelitems to create 2 Selection Objs
ps_sel CsysSelObj -modelitem CsysMiObj
ps_sel PlanSelObj -modelitem PlanMiObj
# Create a random output filename (sec by sec)
set outfile swrapout[clock sec].prt
# Create this model in session
ps_file create $outfile
# config the shrinkwrap Output, Method, Target Solid
swObj config -output_filename shrink_test_out -creationmethod merged -target_solid $outfile
# Add the 2 Datum Selections
swObj config -datumrefs [list CsysSelObj PlanSelObj]
# Create the ShrinkWrap
swObj export
# Save it to disk
ps_file save $outfile
# clean all created objs
ps_obj destroy *
@msteffke wrote:
God clues I worked hard with this code you pointed out. I was doing 95% of it so it was goiod confirmation. Whats getting me is that the definition has p_sel_array as a double pointer. ProSelection ** p_sel_array.
I dont understand why it has to be a **.
The reason for **p_sel_array is that ProArray is in essence a contiguous area of heap allocated memory holding some/any data. This memory has to be reserved somehow and this is where ProArrayAlloc is coming to play. As usual C language 'pass-a-pointer-by-value' approach - the last argument of ProArrayAlloc has to be a pointer to something - therefore '(void*) last_arg'. Now, what is hidden by (void*) construct - the answer is a pointer to an array of ProSelection things. What is an array of ProSelection ( or char for that matter) ? The answer is
ProSelection *pro_sel_arr;
combine that with (void*) from ProArrayAlloc and you would get 'void* ProSelection*' which is (ProSelection**). 'pro_sel_arr' variable has to be pointed-to in order to match (ProSelection**) and will become '&pro_sel_arr' in the function call: ProArrayAlloc( ...., (ProSelection**) &pro_sel_arr) or it could be rewritten step by step:
ProSelection* pro_sel_arr = NULL; // will hold an address of heap memory in the future...
ProSelection** pointer_to_pro_sel_arr_variable = &pro_sel_arr; //address of pro_sel_arr variable
ProArrayAlloc( ...., (ProSelection**) pointer_to_pro_sel_arr_variable);
//the same as calling
ProArrayAlloc( ..., (ProSelection**) &pro_sel_arr);
Thanks for this explanation- this is helpful!