I can confirm this behavior - and it happens in Pro 2018 as well.
First, a couple of digressions:
I changed the category of this post to Technical Problems → Sketchup (was Technical Problems → Sketchup Free). The Sketchup Free forum category is not for any free version of Sketchup (which includes Make and Free). It is specific to the web version of Sketchup: “Sketchup Free”
I removed the comma from the filename - not sure if I needed to, but I’ve heard that commas can cause problems on some systems.
I think the origin of the problem is that the label “vruty” is attached to one of the two faces which are combined when you delete the indicated line. I don’t know the internals of SketchUp, but I’ve heard there are problems when deleting labeled items - the label becomes dissociated with any model geometry and SketchUp becomes buggy. Evidence for this? When you delete the indicated line, the “vruty” label disappears - but I’m betting it still exists internally and SketchUp just doesn’t know where it’s supposed to be displayed!
Yes, you can reproduce this behavior by drawing a rectangle, add a label text on the face, draw a line to divide the face and then erase that line. The attached label sometimes disappears, sometimes it will 'fall 'just next to the face. Applying a zoom extends will expose difficulties in navigating.
Congratulations!! So far as I know, this is the first reproducible example of the singular text bug that has been reported off and on recently. When you delete the dividing edge, the text moves off to the outer reaches of the solar system and destroys the ability to zoom correctly. Hopefully with a test case in hand the Trimble team can fix the bug.
This relates to the reported issue with text randomly located miles from the rest of the geometry.
It seems that if you delete some entity - like a face or edge or vertex - which has a text entity linked to it, then that text gets relocated randomly - miles away.
This then causes the model to appear to zoom erratically.
It looks like the model has disappeared, but actually it’s still there.
Unfortunately the far away text now messes with the zoom…
The ‘Team’ need to address the issue and make these ‘orphaned’ text entities’ locations default to their former ‘anchor points’ in their current context.
Since each point ‘attribute’ relates to a specific face, edge or vertex - and that no longer exist, it might be difficult to realize ?
So perhaps text entities need to have a ‘point’ property separately assigned [used] as an attribute when they are first added or edited, which can be used during the ‘bereavement’.
Since a text entity already has a position ‘point’ property, then perhaps using that should fix things ?
That could then be used to reorient the text entity should it’s ‘parent’ entity cease to exist !
This does not seem difficult ?
Drew a 10x10 rectangle at the origin on the z=0 plane
Drew a diagonal from the midpoint of one side to the midpoint of the adjacent side, dividing the rectangle into a triangle and a 5-sided polygon.
Attached a leader text to the approximate center of each of the two faces
Examining the model’s entities, as expected there is a face with 5 edges in its outer loop, another face with 3 edges in its outer loop, and the two text entities.
Then I deleted the diagonal edge drawn in the second step above, leaving just a rectangle again.
The label attached to the triangular Face blew up. The label attached to the 5-sided Face shifted over a bit but stayed present, evidently attached to the restored rectangle, but not updated for its new area. I could see no rationale for the new anchor point of the text. It seemed to swap the x coordinate into the y position and create a new arbitrary x value.
At this point I re-examined the model’s entities and found that the 5-sided face had been reused (same id) but converted to 4 edges again, the triangular face no longer existed, and the two texts were still present.
The results say to me that, as @TIG speculated, the Text contains some link to the original Face - though this is not exposed in the Ruby API and not accessible via its #point method - and goes singular when that Face is deleted.
Edit: evidence that the Text does contain a link to the Face: if you select and move the face, the text moves along with it!
When the label text is used to display the area of a face, it seems logical that when you erase the dividing line, the label attached to the former area is no longer needed and should be erased or recalculated.
Every text entity that is ‘attached’ to some other entity in the model has a ‘point’ - which is simply got from its position.
When its associated entity - face/edge/vertex - ceases to exist, then surely that text’s ‘anchor’ should revert to its ‘point’ - in 3d-space in the current context.
At the moment it seems random.
I disagree that this kind of text should be deleted along with its ‘parent’.
If you add text pointing at a face and decide not to use its default ‘area’ string, then you add a custom string - “Kitchen Floor”.
You’d probably be disappointed should the text vanish with the floor face.
You could easily recreate that face, and reattach the temporarily ‘orphaned’ text…
I was suggesting that, when used as area-tool, erasing the label together with the lines is ‘wanted’ as behavior, for the area changes. (Perhaps its use, also)
Label tool in action with that other, longstanding bug
You’re conflating the “delete-face-zoom-off-to-infinity-with-text-tag” with the other separate issue, where dividing a face sometimes returns the wrong area. due to incorrect splitting.
In you example, what does the incorrectly tagged 4m² corner show in Entity Info when it’s selected.?
Here’s another example of how leader text is mismanaged when it was anchored to a face and you edit that face. Watch how the anchor point jumps across to the other half of the face when I draw a dividing edge. And, of course, when I delete the edge and then zoom, the camera flies off to never-never land.
My weird logic would require that when you erase an entity with a text leader attached, the text ought to be deleted as well (as happens, for instance, in Archicad and Revit). The same with associated dimensions. Or then the text ought to be transformed into screen text.
