BUG BlockAttributeText

VisualARQ
, ,
1

Hello again,

OK… I have this super annoying bug. It’s been difficult to document, but I finally managed to capture a glimpse of it on video.

The issue is as follows: I have several blocks in my document, each of which has some defined Attribute User Text. That value is then referenced inside the block using a BlockAttributeText text field.

The problem is that it randomly changes back to regular text. The occurrence is extremely unpredictable: sometimes it happens several times a day, while other times it may not happen for weeks.

As you can see in the file and the video, the “grid” mark has an attribute text of 00 (in the example layout, although each instance is individually assigned). At one point, when I selected the block containing the grid marks, they all changed to 06 (you’ll need to pause the video at 0:12). Oddly, they then changed back to their corresponding individual values. However, the most common behavior is that they all get stuck on B, which makes me think that somehow the system is overriding the formula inside the block and replacing the text field with the literal value like 06 or B.

Every time this happens, I have to edit the block and replace the regular text with a BlockAttributeText text field again.

This happens with all of my blocks, and it’s extremely frustrating because I often don’t notice it until after I’ve printed all of my layouts. As a result, all of my grid lines or section marks are incorrect in the issued drawings—usually all showing 06, B, or, very frequently, all section marks showing CL1.

It is worth mentioning that these blocks originally contained regular text. Later, I edited them to use Attribute User Text together with BlockAttributeText. The annoying part is that they keep resetting, which makes me think there is some persistent data being stored somewhere that is overriding the text field.

At the moment, all I have is this video and a few PDFs showing the incorrect grid marks. As you’ve hopefully understood, this is a very difficult bug to reproduce consistently. I hope you can help identify the cause or provide a solution.

My system info at the end of this message (but this bug has been happening though many rhino service releases)

PROBLEMAS DE EJES.3dm (924.4 KB)

Rhino 8 SR33 2026-7-7 (Rhino 8, 8.33.26188.13001, Git hash:master @ 482f88a83547c62cde64d78ea8a8690b7349f289)
License type: Educational, build 2026-07-07
License details: Cloud Zoo

Windows 11 (10.0.26200 SR0.0) or greater (Physical RAM: 31GB)
.NET 8.0.14

Computer platform: LAPTOP - Plugged in [80% battery remaining]

Hybrid graphics configuration.
Primary display: AMD Radeon™ 780M (AMD) Memory: 1GB, Driver date: 6-27-2023 (M-D-Y).

Integrated accelerated graphics device with 4 adapter port(s)

  • Windows Main Display is laptop’s integrated screen or built-in port
    Primary OpenGL: NVIDIA GeForce RTX 4060 Laptop GPU (NVidia) Memory: 8GB, Driver date: 7-22-2026 (M-D-Y). OpenGL Ver: 4.6.0 NVIDIA 610.88

Integrated accelerated graphics device with 4 adapter port(s)

  • Video pass-through to primary display device

OpenGL Settings
Safe mode: Off
Use accelerated hardware modes: On
GPU Tessellation is: On
Redraw scene when viewports are exposed: On
Graphics level being used: OpenGL 4.6 (primary GPU’s maximum)

Anti-alias mode: 4x
Mip Map Filtering: Linear
Anisotropic Filtering Mode: High

Vendor Name: NVIDIA Corporation
Render version: 4.6
Shading Language: 4.60 NVIDIA
Driver Date: 7-22-2026
Driver Version: 32.0.16.1088
Maximum Texture size: 32768 x 32768
Z-Buffer depth: 24 bits
Maximum Viewport size: 32768 x 32768
Total Video Memory: 8188 MB

Rhino plugins that do not ship with Rhino
C:\ProgramData\D5 Lite for Rhino\engine\D5Conv.Rhino8.rhp “D5 Live Sync for Rhino”
C:\Program Files\Rhino 8\Plug-ins\Tibidabo\Lands.rhp “Lands Design”
C:\Program Files\Rhino 8\Plug-ins\Tibidabo\VisualARQ.rhp “VisualARQ”
C:\Program Files\Common Files\McNeel\Rhinoceros\8.0\Plug-ins\Bella (813de3fb-18eb-405f-bfcd-b0b4d3da91fb)\25.3.0.0\bella_rhino.rhp “Bella” 25.3.0.0
C:\Program Files\Rhino 8\Plug-ins\Tibidabo\Tibidabo.rhp “Tibidabo”

Rhino plugins that ship with Rhino
C:\Program Files\Rhino 8\Plug-ins\Commands.rhp “Commands” 8.33.26188.13001
C:\Program Files\Rhino 8\Plug-ins\rdk.rhp “Renderer Development Kit”
C:\Program Files\Rhino 8\Plug-ins\AnimationTools.rhp “AnimationTools”
C:\Program Files\Rhino 8\Plug-ins\RhinoRenderCycles.rhp “Rhino Render” 8.33.26188.13001
C:\Program Files\Rhino 8\Plug-ins\RhinoRender.rhp “Legacy Rhino Render”
C:\Program Files\Rhino 8\Plug-ins\rdk_etoui.rhp “RDK_EtoUI” 8.33.26188.13001
C:\Program Files\Rhino 8\Plug-ins\NamedSnapshots.rhp “Snapshots”
C:\Program Files\Rhino 8\Plug-ins\MeshCommands.rhp “MeshCommands” 8.33.26188.13001
C:\Program Files\Rhino 8\Plug-ins\IronPython\RhinoDLR_Python.rhp “IronPython” 8.33.26188.13001
C:\Program Files\Rhino 8\Plug-ins\RhinoCycles.rhp “RhinoCycles” 8.33.26188.13001
C:\Program Files\Rhino 8\Plug-ins\Grasshopper\GrasshopperPlugin.rhp “Grasshopper” 8.33.26188.13001
C:\Program Files\Rhino 8\Plug-ins\Toolbars\Toolbars.rhp “Toolbars” 8.33.26188.13001
C:\Program Files\Rhino 8\Plug-ins\3dxrhino.rhp “3Dconnexion 3D Mouse”
C:\Program Files\Rhino 8\Plug-ins\Displacement.rhp “Displacement”
C:\Program Files\Rhino 8\Plug-ins\SectionTools.rhp “SectionTools”

2

Hi @mutarq,

I checked the file you attached. Both tag definitions still contain their BlockAttributeText fields, and each instance still has its own distinct value — so this copy is in the working state and doesn’t show the failure. To get anywhere I need to see it broken.

The most useful thing you can do: next time it happens, SaveAs a copy before you repair anything, and post that file.

Along with it, please tell me what you observe when it’s in the bad state:

  1. Does panning or zooming the view change what the marks show?
  2. Does saving, closing, and reopening the file change what they show?
  3. If you BlockEdit one of the bad tags, is the fx field still in the text, or is it now plain typed text?
  4. Does the instance’s value in Properties → Attribute User Text still read correctly, or has it changed to 06 / B / CL1?

Two more questions:

  • Your grid tags are nested — the TAG_EJES blocks sit inside CBP_EJES. Does this ever happen to a tag that isn’t nested inside another block?
  • Have you seen it in a session with VisualARQ and Lands Design not loaded?

Thanks,

– Dale

3

Hi Dale,

Answering your questions:

  1. Panning and zooming show the tag values correctly, but in some situations, like the one I showed in the video, the values are incorrect for a moment, until the permanent change happens, as I show in this new video.
  2. Saving, closing, and reopening the file: once the change has happened, the value is permanently wrong.
  3. As you can see now, when I open the block with Block Edit, the “fx” is no longer active. It has been replaced with a permanent value. Strangely, a completely random User Defined Text has also been added to the properties of each instance.
  4. The Attribute Text still reads correctly (fortunately, at least for now). What I do then is open Block Edit and add the “fx” again. But after doing this 100 times, I’m getting tired of it.
  5. I can’t say anything about other blocks that are not nested. However, you will see that in the layout I have one instance that is not nested, and it was affected too.
  6. I always load VisualARQ (it’s now part of my workflow). And actually, I now think this might be related to VisualARQ. Just today I realized that the permanent change happens when I update VisualARQ Section Views and Plan Views. I’m not sure about the temporary glitch when panning and zooming, though. @fsalla and @MCosta may want to look at this too

CBP_mutarQ_VERSION C_ERROR BLOQIES.3dm (830.0 KB)