You can't make UE remember the setting but you can have it change the read-only flag on a file (which will persist) when you change the setting in the editor. The option is at File Handling/Miscellaneous/Change file read-only attribute when changing menu setting.
I, too, like the concept of preserving the read only status of a file across sessions.
Why Is This Useful
While it is frequently possible to keep reference files locked against changes by marking them Read Only in the file system, this is not always practical. For example, I frequently have configuration and header files that are works in progress open primarily for reference. Changing such files, especially headers, might disrupt incremental builds, by unnecessarily causing stable code to be rebuilt solely because of a accidental change to a header, which could range from something harmless, such as replacing tabs with spaces, to something devastating, such as an accidentally typed character that changed the name of a widely used symbolic constant.
Perhaps Limited to Projects
This is a feature that might fit well into a Project configuration. Ideally, this would be a configurable setting; e. g., if a certain box is ticked, the read only status of files that belong to the project is preserved in the file list.
Another feature that would fit well into projects is to save the current location of each file that belongs to the project.
Ideally, both settings would have project scope, with options to override for each file.
Current version UE v19.00.0.1031 does still not support remembering and restoring the read-only state for a project file in the workspace (*.pui) or project (*.prj) file of a project. So it is currently still necessary to toggle read-only state manually after opening a file on which an accidental modification should be avoided even if the file has not the read-only attribute set. You should send a feature request email to IDM support.
TXWizard wrote:Another feature that would fit well into projects is to save the current location of each file that belongs to the project.
I do not understand this feature request. UltraEdit stores the names of the project files
with relative path to the *.prj file of the project or the specified project directory whenever possible, or
with an absolute path if for example one of the project files (used only for reference) is on a different drive.
You just have to add the files you want always available in a project using the Project Settings dialog or the Project tab in File Tree View (UE) respectively Workspace Manager (UES).
My explanation was poorly worded. I know that the project files include lists of files, which can be organized into groups. My idea was that, along with the read only status of a file, the project should keep a record of the top line that was visible in the window when it was last opened (with the project loaded, of course!). This can be very helpful if you are interrupted while in the midst of working on a section in the middle of a large file.
I'll be writing to IDM about both ideas. I mentioned them in this forum because the subject caught my attention, for obvious reasons.
UltraEdit remembers the position of the caret position, the bookmarks (if configured), foldings (if configured) on closing of a project (or exit of UltraEdit while a project is loaded) for all opened files in the project related workspace file (*.pui) of the user.
But it is right that all those information are not remembered for project files not currently opened on closing the project. Such an enhancement would require to remember caret position, bookmarks and foldings in the *.pui file also on every closing of a file belonging to the currently loaded project.
The *.prj file is not the right place to store information like that as there are projects used by several members of a team. This is the reason why there is a *.prj file which may be on a server and used shared by a developer team and a *.pui file which remembers the environment of the current user/developer and which is by default located in the application data directory of the user on local machine.
Having not delved too deeply into its inner workings, I wasn't aware of the division of data between project (.prj) and user (.pui) files, although such divisions make solid sense, especially for teams that share a single project.
Armed with the additional information, I'll pay closer attention when next I open a project, which will almost certainly be over the current weekend.
