Developer forums (C::B DEVELOPMENT STRICTLY!) > Development

read only

<< < (3/3)

MortenMacFly:

--- Quote from: MortenMacFly on December 18, 2010, 01:52:11 pm ---an I am aware that I still have the task to create the patch.

--- End quote ---
Here it comes (finally).

Not 100% working, but at least better than the current state.

Notice the following things in general (which makes things complicated btw):

* You need to differ between a file and an editor. While a file might be writable, an editor can be set to read-only. In that case, the editor state supersedes.
* Checking the file system for a file being read-only should only be done when really needed. This is time consuming. Thus we may fail some cases if e.g. a user sets a file read-only in the background (not using C::B). This should be handled if e.g. the file is opened (or used in any other way) and thus it's state is checked anyways.
* I am not sure how we handle if e.g. a file is read-only and under version control. I could imagine blending two icons here...?!
* Keep in mind that files can be changed in its state in many ways. Using the file explorer, the file properties or any plugin via SDK (e.g. setting an editor state to read-only). So there should be a common API (e.g. SDK event?!).
* Updating the project tree's icons is time consuming (especially for large projects / workspaces). I'd prefer only to update the visual part if possible...
Patch is attached... not implementing the above. ;-)

daniloz:

--- Quote from: MortenMacFly on December 27, 2010, 05:06:33 pm ---Here it comes (finally).

--- End quote ---
Ok, thank you!!! I've downloaded it and will have a look... I let you know...

daniloz:

--- Quote from: daniloz on December 16, 2010, 03:26:17 pm ---@jens:

I am aware of that one and like it very much. However, the point is, if a file is already open and is read-only, then even after you go there and uncheck the Read-only attribute, you cannot edit the file. You have the close it and open again...

So, my first though was that the file status should be refresh after a change in the read-only checkbox... and all diverged to a more general discussion...

Thank you for taking me back to my initial point. Maybe this should be the first step in the implementation, a callback to whatever-is-needed-to-refresh-the-editor-read-only-attribute, so after the file properties dialog is closed, you can edit the file...

--- End quote ---

I finally manage to get some time to look into this issue and, actually, there's a very simple way to do the refreshing, by using the CheckForExternallyModifiedFiles() from the EditorManager... The patch is attached, please feel free to test it... :-)

Expected behavior: when you right-click on a tab or file, go to "Properties..." and then change the "File is Read-Only" flag, the editor is refreshed automatically to reflect the new flag.

Old (actual trunk) behavior: The editor is only refreshed and reflect the new Read-Only state after you trigger a CheckForExternallyModifiedFiles(), either by closing it and opening again or by clicking outside C::B and coming back, so it regains the focus (on Windows)

Navigation

[0] Message Index

[*] Previous page