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.
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).
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)
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?
No,
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.
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.
2 Likes
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.
4 Likes
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.
Edit:
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.