Is it possible to embed an Action Macro into a Dynamic Block?

[Anonymous]

Hello, I have an interesting situation on my hands.

I'm currently working on a series of dynamic blocks for my company and have found a block to be giving me quite the hard time.

The block I'm working with has two attributes for text information (its an elevation block) and when I flip the block's direction using a flip parameter/action the text is properly anchored, however the justification does not change (as I expect it wouldn't). I have found a solution to the initial issue, using the ATTSYNC command after the block is inserted and flipped, the justification will change properly and the block as a whole continues to work perfectly.

HOWEVER, I will not be the only one at this firm using this block and I would really love to solve the problem by embedding an Action Macro into the block tied to the flip parameter so that when a user 'clicks' the flip point, the ATTSYNC command will run immediately without the user realizing it even happened.

If anyone has experience with this or any solution let me know. I've never used Action Macros before and I'm not sure if its even possible to have the macro as a part of the block's file.

Thanks!

[dbroad · Accepted solution]

No. Action macros cannot be embedded in dynamic blocks.  I would suggest you experiment with different justifications such as middle.  The best place to post questions about dynamic blocks though is the dynamic block forum.

[gotphish001]

I have a similar elevation block that gave me headaches ;when I made it. I'm not sure my solution is the best but it works ok for me. Instead of using flip, I made 2 visibility states. Left and right both with the justification I need for that orientation. The only thing that doesn't make it perfect is that if you fill in the info in left state and then change to the right visibility the info resets back to the default. That and if someone tries to mirror it then the justification gets messed up too. 

I did just think of maybe a way to fix the way I have it set up. If you made it fields in the left/default visibility state and then had it add those fields into the right state instead of having attributes that you needed to enter that might solve it. However I guess that you'd need to input everything into left state and then flip it. If you changed to the right state first I'm not sure what would happen as I only used fields once. Could you make both states take input and make that a field that inserts into the other state or would that cause some circle of doom problem? Hmm now I have something to play with!

[Anonymous]

I do appreciate the input, but the visibility states are already being utilized for three different iterations of the block. While ultimately the solution could be to just have six states instead of three (one for left, one for right across three blocks) I don't believe that's the solution my firm wants to resolve to.

Thank you again though!

-Max