Forcing a redisplay?


Joe_Carrick
 Share

Recommended Posts

58 minutes ago, Joe_Carrick said:

Is there any way to cause that to happen automatically from within a user macro?

 

This sounds like a nice idea on the surface Joe, but even if we could do that with a macro, the macro wouldn't execute till that screen redraw so we would be right back at square one. 

Link to comment
Share on other sites

2 hours ago, Alaskan_Son said:

 

This sounds like a nice idea on the surface Joe, but even if we could do that with a macro, the macro wouldn't execute till that screen redraw so we would be right back at square one. 

So, if there was a <F5> special key that could be placed in a Label wouldn't that force the redraw?

  • Upvote 1
Link to comment
Share on other sites

Quote

So, if there was a <F5> special key that could be placed in a Label wouldn't that force the redraw?

 

So every time the label was drawn, it would execute the macro which would then force a redraw which would draw the label again.  This is what we call an endless loop.

 

I'm not sure what problem you are trying to solve but I don't think this is the solution you want.

Link to comment
Share on other sites

Dermot, here's the situation I'm trying to solve.

  •  Macro_1 sets a $Global variable.  $LayerSet  (get's the layer_set_name from a text object - generally the view name text)
  •  $LayerSet is used in other macros to control the result.
  •  Macro_1 may not have executed before the other macros so $LayerSet might not be correct if I've just switched from a Plan view to an Elevation view.
  •  <F5> or pan/zoom is currently the only way to force the redisplay 

The layer_set_name attribute is only reliable for CAD objects in any view other than a Plan View.  It's not reliable in Camera Views (Elevations, Sections or Interior Elevations).

Maybe that just needs to be fixed.  Then I could just use the object's layer_set_name from within the Label macro.

 

  • Upvote 1
Link to comment
Share on other sites

I agree with the problem and is a good argument against using Macros. The problem has been around since X3 and is basically because it is impossible the control or know the order of the object updates. The order will always change with every insert/delete.

 

A easy solution, which i also sent in, is to add a feature to define within a macro, modes of which that macro will  executed -- as in: start of update, with object update, at end of update and opening/closing plan only. This again might force the re-execution of some objects which would than be made without macro execution-- which chief does a lot of right now. There is little chance of Chief doing anything -- IMNOHO.

Link to comment
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share