Macro feature and cosmetic thread

Hello VBA geniuses...
I'm working on a macro feature that creates a body in a part document. I will eventually need to apply a cometic thread to this body. What is the
best way to approach this? I'll need to drive the dimensions of the cosmetic thread somehow from the macro feature.
I can add geometry to the macro feature's body, then use equations attached to driven dimensions to drive the thread dimensions. That leaves the cometic thread one rebuild behind. That's not acceptable.
I see that the macro feature can have display dimensions, but I don't see any documentation on how to use those. If I knew how to do that, I could connect the thread to those with an equation, and the thread should stay current (I think).
Also, how can I make sure that the cosmetic thread stays attached to the correct edge on the macro feature's body? The body generated by the macro feature may change shape, and I'm afraid the cosmetic thread might become attached to the wrong end of the body or go dangling.
If I can't guarantee an edge for the cosmetic thread to attach to, I suppose I could create another macro feature body which would never change shape. Therefore, the edge should never change, and the cosmetic thread should stay put (I think).
Thanks in advance for any advice or redirection.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

I might be wrong, but if I remember correctly, macro features are not allowed to create another features (and cosmetic thread is a feature). Creating new features and altering model dimensions during model rebuild is a bit unethical, since rebuilding should should update the model. If the dimensions are altered during rebuild, the model is not up-to-date after rebuild and subsequent rebuilds are needed to clear the green lights from FM tree.
-h-
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
"Heikki Leivo" wrote:

Correct.
is
It might even crash SW.

after
FM
The trick is : 1) to abort the rebuild when it occurs by trapping the "RegenNotify" event and return S_FALSE (see apihelp) 2) use the PostMessage Windows API to queue a custom event (tricky in VB, e-mail me if you need help) 3) handle your custom event (will happen once the rebuild is over) to do everything you need 4) call Rebuild or EditRebuild, but don't abort it this time.
Would be simpler if MacroFeature had BeforeRebuild and AfterRebuild methods... Maybe people would even start using MacroFeatures...
--
Philippe Guglielmetti - www.dynabits.com



Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Hmm. I hope that's not the only route I can take to get this done.
I wasn't planning on having the macro feature insert the cosmetic thread. I was going to add it myself after the macro feature is created. My problem is to somehow expose some data so that the cosmetic thread dimensions can be driven either by an equation or by dimension linking. In such a way that only one rebuild (by the user) is needed. Also, I need to make sure that the cosmetic thread stays correctly attached to the macro feature.
As for the number of people using macro features... At first I was ignorant of the limitations of the macro feature. If I think of it as a user-defined feature, it makes sense to me that it can't cause a new feature to be built, or modify another feature. What discourages me about macro features is how to implement them. It feels like you have to jump through a lot of hoops to get it all working. Again, most of this seems justifiable, after I understand more of the structure of what's going on.
What is terribly frustrating is the documentation of some of the features of the API. I can't find it. Specifically, the documentation makes it clear that a macro feature can have display dimensions. There is no explanation of how to actually do this. Maybe I'm just ignorant. This is particularly frustrating, because a display dimension on the macro feature could be used to drive the dimensions of the cosmetic thread.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
"Dale Dunn" wrote:

ignorant
user-defined
ok
here I don't get it. There is nothing wrong in letting a feature modify things in child features (listed afterwards in feature tree) : Equations, Design Tables or Sheetmetal functions do exactly this. I'd love to made my own "Equations" feature with full VBA support...

I
clear
No you're not ;-) MacroFeatureData::GetDisplayDimensions was just implemented (SW2004). If you look at the MacroFeature API, you'll see it changed a lot since SW2003, and it will probably (hopefully) evolve further. Ask apisupport for specific help, they're very helpful.
What I feel frustrating is that SW Corp isn't clear about their intent. The first time I heard about macro features was in a survey for partners where they asked "do you plan to use macro features?" They never explained what they want to make possible with MFs, what's the strategy, or at least the intent behind them.
--
Philippe Guglielmetti - www.dynabits.com



Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Ok, I'll pester apisupprt for an explanation of that. I was thinking I should only use them for "problems". Thanks for the pointer. I'll make sure to ask how to use these.
WRT surveys, I agree that they're often dificult to interpret. I quite often get through one, then wonder if they questions were asking something other than what I thought. Part of the survey becomes trying to puzzle out what's being asked.
I often fill out the comment at the end to try to explain what it is that *I* am thinking. Just to try to close the communication gap.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Would it be possible to do more with a macro feature if you had it make a call to a separate macro. Then you wouldn't be as constrained, in theory. I haven't tried it I haven't played with them yet, but have had some ideas on how they could be useful but was turned off by the fact that you couldn't edit the tree or what have you.
BTW. I once caused an error in the equations that caused the VBA editor to come up with the code that the equation created. Wouldn't it be possible to do funny things if you got back in there too.
Just thinking a bit randomly.
Corey
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
I remember what I wanted to do. I wanted to create a user defined feature that would rebuild if the driving sketch was edited. Is that possible it would be good info to know for the future.
Corey

couldn't
to
to
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
"Corey Scheich" wrote:

couldn't
I tried. It doesn't work as long as the call is synchronous, meaning that the macro code is directly called from the macro feature code. You have to wait till the rebuild is completely over, hence the PostMessage strategy I explained above. Another suggestion would be to start a Timer on Post_Regen event (because the rebuild is not over when the event is fired :-( ) and do your modifying code on the Timer even, a fraction of a second later. Anyway, you'll have to start another rebuild after you've changed the model, so it's basically the same strategy I explained.
Logically, a macro feature should be allowed to modify features located after it in the feature tree, as they are not yet processed while rebuilding. This is the behaviour of several SW features, MFs should behave the same.
--
Philippe Guglielmetti - www.dynabits.com



Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

That is why equations dont work when people install SW with AntiVirus running: the VBA doesnt install properly. If you use equations, SW dynamically creates "one liner" macros and executes them. Once I realized this, if I was going to be using VBA, I would get rid of the equations and do them myself in VBA.
Virtually all VBA supports some form of dynamic code generation.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Polytechforum.com is a website by engineers for engineers. It is not affiliated with any of manufacturers or vendors discussed here. All logos and trade names are the property of their respective owners.