I created a custom widget “Notepad” in a document. I set “Select Data” from a table and then “SELECT BY” the same table.
When I select different records in the table, the content inside Notepad doesn’t change.
So, the Notepad is associated with the whole table, not individual records?
Hi @GG1.
In the right panel under the “Custom” tab and “Widget” sub-tab, there’s a section at the bottom that lets you pick a text column to use. Is it filled in?
George
No, it’s not. I wasn’t prompted.
So, I fill it in now. But the entire notepad I’ve worked on today is gone. 
I was attempting to add a notepad widget today and noticed that the selection drop-down to choose a content column is not visible. I’ve used this widget in the past without issue, although since observing this behavior today I also noticed that all my previous notepad widgets (in this same document as well as others) appear to be affected as well. The widget no longer displays the contents of the associated column, and the selector to choose a content column is missing.
Any thoughts?
Hi @Kirk_Williams.
Is this happening on a document on getgrist.com or a self-managed instance of Grist? Does it still happen in a new document?
George
Hi!
The documents with which this was observed are hosted on getgrist.com, accessed via browser as well as a desktop app wrapper [web catalog] on MacOS. Curiously, when attempting to create a new document to answer your question above I see that the custom widget appears to be completely functional once again!
Neither the “content” selector nor the text within the widget were visible yesterday in this or any other Grist document.
After noticing the anomaly yesterday I had closed and re-opened the individual documents as well as the application itself. The issue persisted and was observed using both the desktop ‘app’ and within chrome/safari with clean caches. The only remaining variable I can think of is that I am currently working from home. I work at a hospital with some notoriously restrictive network policies. While I wouldn’t imagine that affecting server-side rich text (and the documents in question were created on and previously accessed on that network), I’m curious to see how the widgets behave tomorrow when I’m back in the office.
I’ll report back with any findings. Thank you for the reply and assistance!!!
So it appears that the issue I’m experiencing is indeed related to my hospital’s network. Upon returning to the office today, I opened the same document used in my previous post and was immediately able to reproduce the erroneous widget behavior. Note the absence of any content within the widget window, as well as the content selector in the widget settings pane:
This behavior is what I was describing in my original comment. For further confirmation, I temporarily disconnected from the corporate network and established a wlan connection to a personal hotspot device. Closing and re-opening the same document while on the hotspot connection resulted in the widget text and content selector displaying correctly once again:
It may be of interest that this specific document (as well as others) was created and used frequently on my hospital’s network without issue, so I can only conclude that there was a change in policy sometime within the past week that resulted in this content not displaying correctly. While this presents a significant challenge for me, it does not appear to be an issue with Grist. In case it’s of any interest, the same behavior was also observed with the display of HTML and Markdown widgets.
I welcome any thoughts or suggestions anyone may have for understanding or circumventing my inability to propagate rich text content on this specific network but as this appears to be a “my problem, not yours” situation, I’ll once again thank you for your time and effort in troubleshooting.
Cheers!
