Topic: Point Label Styles

[bdough15]

We are editing a point style for Elevation and Description to make it appear correct in the dragged state, we have something that we are able to work with now but we have noticed that in the dragged state the elevation and description swap spots to have the description above the elevation.  Is there a setting that we are missing that would dictate why it would swap like that?

[mjfarrell]

We are editing a point style for Elevation and Description to make it appear correct in the dragged state, we have something that we are able to work with now but we have noticed that in the dragged state the elevation and description swap spots to have the description above the elevation.  Is there a setting that we are missing that would dictate why it would swap like that?

Make sure you set the label style's DRAGGED state to be AS Composed, and they will not rearrange themselves on you.

[sinc]

This has been a long-standing irk for me...

When using "As Composed", how do you get the leader to flip automatically to the other side when the label is dragged to the other side?  I tend to avoid that option, because I've never been able to figure out a way to make the leaders behave properly.

[bdough15]

This has been a long-standing irk for me...

When using "As Composed", how do you get the leader to flip automatically to the other side when the label is dragged to the other side?  I tend to avoid that option, because I've never been able to figure out a way to make the leaders behave properly.

That is exactly our delimna, we were figuring that we had to give a little but thought maybe we were just too stupid to find the right setting, we have done the "As Composed" but that is a worse result because the arrow ends up through the text.

[mjfarrell]

It isn't 'the best' however one may use the extra grip in the point to Toggle Sub item grips, and then move the point point label to the Left side of the point. 

Then AFTER you have moved the labels to the Left side should you grab the Drag Label Grip the leader then Right Justifies itself.  Weird but true, see attached.   Try it you will like it, although it would be better if it were automatic, instead of a three step country line dance.

This is some of the fun stuff we get to cover in class these days. 

[sinc]

Try it you will like it,

You're exaggerating again.   

[mjfarrell]

Try it you will like it,

You're exaggerating again.   

Did you try it?  Did your leader NOT go through your label?

Who ME?   

[Jeff_M]

Is there a setting that we are missing that would dictate why it would swap like that?

Create the text components in the same order that you wish them to appear in the dragged state.

[sinc]

Is there a setting that we are missing that would dictate why it would swap like that?

Create the text components in the same order that you wish them to appear in the dragged state.

That's what we typically do.  It can throw your desired Parent/Child relationships, though, since components can only be added/deleted in the parent style.  You can't create a Child of an existing style, and flip the two components; instead, you must create a new top-level style.  But that's a minor annoyance, especially compared to the leader behavior for "As Composed", which (in my mind) is broken and unusable.

[mjfarrell]

True it would be optimal should the dragged mode of ALL labels incorporate a leader justification grip in the dragged state.  Using the sub-component toggle for point labels will allow one to get the leader to not go through the text.

One can then further move the various text components around the point marker as well, although it is a bit kludgey.

See attach, the little blue dots are the sub component grips one will see once toggle on.


I agree however that for ALL other labels the 'as composed' function leaves a lot to be desired in terms of controlling the leader, one gets when the label is dragged.

[bdough15]

Did you try it?  Did your leader NOT go through your label?

Who ME?   

[/quote]

It worked like sleeves on a vest...but it is going around your head to get to your arse!  I can accept the fact that the program is faulty and deal with it in that sense rather than spending extra time doing something that in the end gives you the same information.

[mjfarrell]

Did you try it?  Did your leader NOT go through your label?

Who ME?   

It worked like sleeves on a vest...but it is going around your head to get to your arse!  I can accept the fact that the program is faulty and deal with it in that sense rather than spending extra time doing something that in the end gives you the same information.
[/quote]

I understand completely; however many of these issues, I have tried vigilantly to get autodesk to admit are an issue with this program.  I either get one of two reactions; an email denying that the problem exists, or no response at all.
It is very frustrating, however I just keep pushing on.

Thankfully I do not work for autodesk, or one of their vendors, so I am free to admit when things don't work as they should.

[Dent Cermak]

My, how this site has changed!! In the beginning, the strength of this site was that we all realised that AutoCad NEVER did things we wanted it to do the way we wanted it done, so multiple LISP routines were offered up to alleviate the problem. Not now? Now we have to learn to live with it? Yo mama!!
Many moons ago , I think it was Keith, posted a LISP routine called "LP" that can be modified by a lisp guru to solve this problem.(DON'T even begin to look at me to be able to do it!!) The routine lists the X,Y,Z values at the end of a leader that it draws from the point and when you move the text the leader lines adjusts to fit without changing the order or the text. Surely this lisp can be modified to Pt.No., Elev., Desc. , or what ever order you desire, without a whole lot of trouble.
Isn't the idea still, if AutoCad won't do what you want, you get a Guru to write a LISP routine by envoking the WHINE MODE?? 

[mjfarrell]

My, how this site has changed!! In the beginning, the strength of this site was that we all realised that AutoCad NEVER did things we wanted it to do the way we wanted it done, so multiple LISP routines were offered up to alleviate the problem. Not now? Now we have to learn to live with it? Yo mama!!
Many moons ago , I think it was Keith, posted a LISP routine called "LP" that can be modified by a lisp guru to solve this problem.(DON'T even begin to look at me to be able to do it!!) The routine lists the X,Y,Z values at the end of a leader that it draws from the point and when you move the text the leader lines adjusts to fit without changing the order or the text. Surely this lisp can be modified to Pt.No., Elev., Desc. , or what ever order you desire, without a whole lot of trouble.
Isn't the idea still, if AutoCad won't do what you want, you get a Guru to write a LISP routine by envoking the WHINE MODE?? 

Well, Dent the bad news is that some of the stuff we want C3D to do, can not be accomplished with lisp, if at all.
That is the major reason that SINC has created the SINCPAC for C3D, the vast majority of the functions he has created are far removed from 'simple' lisp expressions.

However; yes I would like some cheese with my whine.   

[sinc]

Yeah, back in the "old days", when Autocad was basically just a bunch of primitive drawing objects, it was very easy to write Lisp routines to customize the primitive drawing objects.

But these days, there are all these "intelligent" objects that have a rather large number of features and capabilities.  And while we can get to quite a bit of stuff via the API, there are still huge gaping holes, and large numbers of things we can't do via automation.

Unfortunately, one of those things we can't do via automation is "fix" the behavior of C3D labels.  We could write a system of annotation that completely replaces C3D labels, but if we want to mimic all the other functionality of C3D labels, that is a rather extensive task.

I actually already have a routine in the Sincpac-C3D that will extract the contents of Point Labels into MLEADERs, which do not suffer this problem.  But the MLEADER contents are not dynamic, and are lacking some of the other functionality of C3D labels.