Macro feature and cosmetic thread

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-

Correct.

It might even crash SW.

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...

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.

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...

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.

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

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

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.

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.

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.