CTEXT (text leader) Problem with Validity Check

I have components that were made in previous versions of SketchUp that worked fine prior to v2019 but now when I insert them into 2019 I get messages like the attached. I need to know what is wrong so I can fix the problem in the models and upgrade them.
Untitledx Untitledx1

1 Like

Can you share an example component skp that exibits the problem (components are saved as ordinary skp files, you don’t need to provide an entire model that uses the component).

1 Like

I am trying to reproduce it and so far i can’t. it seems to happen only when I inset certain models like the attached.

33030NT.skp (73.2 KB)

1 Like

That file opens without errors for me in SketchUp 2019.2 and Model Info->Statistics->Fix Problems finds nothing to fix. So, there must be something else going on when you hit the problem. It may involve the model you are importing the component into, not just the component itself. When the validity check says it erased text(s) can you identify what text is gone?

1 Like

I don’t know what Ctext is…
I’ll keep trying to recreate the problem and post it when it pop up. I’ll have to post it outside of this forum, some of our files are 20 to 40 megs in size.

1 Like

Alas, the developers who wrote the fix problems dialog seem to have done so mainly for their own benefit. Other than telling you there were issues, the details are unintelligible to us mere mortals. I would assume that a ctext is the internal structure for a leader text such as you used in the example you posted. There are bugs involving leader texts that are severe in earlier versions and partly fixed in 2019. They may be detecting defective ones and erasing them to prevent tripping the bugs.


I sent you a PM

To anyone else following this topic: @pwharton shared an example via PM and it turns out that the issue is the SketchUp 2019 variation of the stray text bug that plagued earlier versions. This bug is triggered when you attach a leader text to an entity (especially a face) and then subsequently edit the model in a way that cause SketchUp to delete that face or merge it with another adjacent face. Before 2019 the text would fly off to an impossible distance, causing severe issues in zoom and orbit. In 2019 it stays near where it should be but can lose its attachment to the original geometry (which was deleted) and come to point at nothing. The fixup evidently detects this situation and deletes the stray text.


Thank you for looking into this and finding and helping to find an answer. I’ll have to find another solution to our problem in the meantime.

We use the Generate Report to help in quoting our jobs and some items are set up as block inside the components so that they can be quickly changed and read as a item in the quote. If they don’t explode them those items can end up being counted twice.

In AutoCAD we could set up items that need to be exploded to do so when inserted into the drawing file automatically so the user never had to think about it. I have not found a way to do this in SketchUp, so that is why I put in the note to remind the users to explode certain component so they can change them to fit the needs of the project individually (i.e. filler panels frames, etc.).

Excellent report Steve. I wonder … SU2019 added the ability to get and change what text leader objects are attached to. Could a method be coded to iterate the model, groups or components to detect leaders that return nil for #attached_to, and then use PickHelper with the leader’s #point to reattach the leader to a valid object using #attached_to= ?

EDIT: I see that there have been attempts in the past …

An interesting idea. I haven’t experimented with #attached_to to see whether it could diagnose these stray texts. I’ll give it a try.

As to reattaching them, in some samples I’ve seen the leader point isn’t over any valid object, in fact, not necessarily even close enough to anything to get a solid idea of where the text might have attached previously. The Ruby in the topic you referenced fixes the strayed to infinity case, which so far as I can tell no longer happens in 2019. But the code doesn’t do anything with #attached_to.

1 Like

This begs the question…
Why delete this wayward Text AND report that you’ve done it ?
Either you do the deletion ‘silently’, OR you report that it’s been discovered and it’s dislocated - BUT any ‘fix’ of this issue seems unlikely - so why bother ? …
So the ‘silent’ deletion seems the only logical option ?

The only answer I can offer is that the fix problems dialog always reports everything it did, regardless of whether the “fix” was to delete something or take some other action.

I tried #attached_to on the sample file from pwharton and got mixed results. One of the Texts was definitely stray, returning nil. But the other two (one of which is errant) both report an InstancePath that seems to make sense. These paths end in vertices. I need to check whether those vertices are valid.

Hmm…the vertices say they are valid, but one of them so far as I can tell isn’t used by the group the Text attaches to. Weirder and weirder…

SketchUp’s Text is not necessarily attached to anything.
e.g. Screen Text with spurious ‘screen points’.
So what SketchUp needs to do is spot after an entity is erased, check for any associated entity, and adjust that appropriately…
Off the cuff - when it’s deleted…
If it’s an edge then its associated face goes [does this already ???]
If it’s an edge or a face, then its associated text should probably go - I can’t see little logic in retaining it - or even reporting it.

Thanks for all your help,

At least i know what it is and its not something I’ve done per se. I’ll try and find another way to handle our components to group problem.

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.