Re: the 'locked' property on cells

On Thu, Jun 13, 2002 at 04:36:22PM +0200, Floris Kraak wrote:

Furthermore, it also seems to depend on having the ability to
'protect' a worksheet which isn't possible using the current user
interface. (at least, in the stable gnumeric version)
There is no support for implementing protection in the stable
series, the patch was too large to go in.  This work can only be
done in the development tree.
So I have a few questions which basically boil down to:
'How hard is it to implement'
The implementation comes in layers.  The basic bits are very doable
as starter projects, the remaining elements will require more
knowledge of the application (not the code, but the app) to see
where to look.

'where do I start'.
There are 2 main aspects to things
1) Catching all the different ways that a region can get changed
    - edit a cell
    - edit a region
    - autofill
    - format a region
    - solver
    - analysis tools 

2) Enable/Disable protection
    - per sheet
    - per workbook
    - password protected ?

We currently support per sheet protection that disabled editing the
current cell.  This leaves lots of room to work in.

There should be an user-generated event somewhere going off when a
user tries to access a cell I suppose but where and how do I catch
Edits are not event driven.  The ui calls a 'wbcg_edit_start' which
does the necessary setup and validation.  However, that is already
supported.  The next step is to support region fills, for that
you can't really check until the user makes the request
        select A1:B2
        type 'foo
        press Ctrl-Enter to fill the entire region with foo.

This calls cmd_area_set_text -> cmd_area_set_text_redo 
near the sheet_ranges_split_region you'll need to add a convenience
routine to check for contained cells that are locked.  Actually
looking around for calls to sheet_ranges_split_region would be a
good idea.  Most places that we check for splitting arrays, will
also want to check for protection.

What tools should I use to change things (do I need glade to
add ui stuff? or is vi sufficient?) 
glade is only necessary if you want to create dialogs, even then you
can just edit the xml directly (although I don't reccomend that for
most uses)

Finally, I'd like to add this stuff to the stable version (or at
least, have a patch that applies against that) but I'm not sure
if that is entirely possible.
You could produce a patch, but it could not go into the stable tree
so I do not reccomend this.

However, given the fact that 1.0.7
compiles and the CVS version doesn't even have a configure script
let alone satisfied build dependencies I'd still like to try using
CVS should always compile.  You need to run the script
rather than configure.  The same as the other cvs packages.  Or you
could use the 1.1.5 tarball which has all the usual configure

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]