What is the best way to enable/disable individual cells (not rows or columns) in an edit-table? The documentation about STYLE is rather cryptic and has led me nowhere. I need to, under certain conditions, programmatically protect/unprotect individual cells (not rows or columns) so that user cannot change their contents.

Any help would be appreciated.

Godfrey,

I didn't know one could disable or protect individual edit table cells. But e.g Don Bakke will soon tell me wrong if I am.

If I needed to protect individual edit table cells programmatically, I'd try the following. (I'm assuming here you don't need more than one cell protected at a time):

- When you want to protect a cell set a user defined property of the edit table, e.g, @PROT_POS, to the col:@FM:row position of the cell. Unprotect the cell by setting @PROT_POS to null.

- Have a CHANGED handler that checks if the current cell is the protected cell. In case redo each change immediately by setting the value back to its original value. (And make sure you don't get into an eternal CHANGED loop. Don't change back unless NewData is different from the original value.)

- With original value I here mean the value at the time the cell was protected. Store this value in another user defined property of the edit table, e.g, @PROT_VALUE. I.e, at the same time you protect a cell by setting @PROT_POS to the cell's position you must also save the current value in @PROT_VALUE.

- Oystein -

Oystein,

You are both right and wrong. You cannot protect cells all by themselves, however, you can simulate this by using the method for protecting columns. Since Godfrey needs to do this "programmatically" I assume then that he is already using GOTFOCUS and POSCHANGED events. Then all that is needed is to use the Send_Message(CtrlEntId, "COLSTYLE", ColumnNo, NewStyle) command to dynamically protect or unprotect columns. This will appear to the end user as if the cells were protected or unprotected accordingly.

[email protected]

SRP Computer Solutions, Inc.

The way we do this is to protect the table and use a dialog box to capture data / changes. Buttons handle inserting / deleting rows in the table. Based on the contents of the row, it's easy to handle protect / unprotect edit-line controls, radio buttons, etc. in the dialog box (usually in the create event). We have a button that allows a highlighted row to call the dialog box. We also use a double-click event on the row to do the same thing. Altogether we find it to be quite powerful and relatively easy to use.

Don Miller

C3 Inc.

Don,

Of course. That was my first thought really. But then I got confused. I thought of the user leaving the protected cell for an unprotected one - in the same column. Which of course would be protected too, being in the protected column. But of course it's not too late to unprotect it.

Now did I say "of course" already?

- Oystein -

Hi Don,

Easy…yes, quick entry…not really. We generally find that our users like to input in a flowing pattern which can't be done easily when one has to stop and either double-click the row or click on a button. (I suppose an accelerator key that launches the dialog box might blur the distinction a little. At least it eliminates the need to use the mouse.)

[email protected]

SRP Computer Solutions, Inc.

Dons,

I think having an accelerator key is a good solution. In my current app I use the same accelerator key for both popups and collectors, so the user has only one key to remember. A control seldom has both popups and a collector.

- Oystein -

I haven't tried this, but if an edit-table is a requirement, could it be done such that a list of restricted cells is held as a property of the table and if one of those cells was selected, the poschanged/gotfocus event automatically returned it back where it came from, whether it be on the edit table of another control.

Simon Wilmot

RebusHR

Simon,

I believe that is how Oystein is doing it right now. That works but it seems to me to be lacking some elegance from and end-user point of view.

[email protected]

SRP Computer Solutions, Inc.

Don ..

The general problem I have with edit-tables is that if you need to incorporate a lot of conditional logic which controls where the user can and cannot go, some cells required or not, depending on data in other cells, etc., different defaults depending … then the commuter module becomes really hairy since it needs to be aware of POSCHANGED, sometimes the CHAR or CHANGED event, etc. In addition, if the logic is different for a new row than for changes to an existing row, then it's doubly confusing (for the user, I think). Tatty old AREV was much simpler since the cursor couldn't go anywhere but where I wanted it to. Windows is quite different since the user can move completely out of an edittable .. so the lost-focus event needs to be trapped too. A better control would help a lot, IMHO.

Don

Don,

A better control would help a lot, IMHO.

Amen to that!

Tatty old AREV was much simpler since the cursor couldn't go anywhere but where I wanted it to. Windows is quite different since the user can move completely out of an edittable .. so the lost-focus event needs to be trapped too.

AREV made it simpler because each associated multi-valued field could still be treated the same as any single-valued field for the sake of pre and post-prompt processes. In other words, they worked independently and as a group when necessary.

Consequently, due to the number of AREV conversions we've worked on we developed a logical framework that we hooked to our edittable's GOTFOCUS, LOSTFOCUS, and POSCHANGED events that would simulate the pre and post-prompt behavior of AREV's AMV fields. We can now take the logic in AREV and practically dump it directly into OI and have all the pieces working.

[email protected]

SRP Computer Solutions, Inc.

Many thanks for all your helpful suggestions. I have managed to achieve the protection of individual cells by using a combination of POSCHANGED and COLSTYLE logic as you suggested … thanks once again.

Is there some reason why column/row attributes cannot be made available to individual cells as well? I think this would allow a higher degree of functionality in edit-tables.

A general revision regarding edit-tables (the foremost control for multi-values, a distinctive advantage of OI) in terms of handling, presentation and so on is probably highly recommendable, or an alternative superior control. Do you agree?

Godfrey,

Everybody, including Revelation, agrees with you. Note that the limitations to the edittable are based on the underlying third-party control. AFAIK, there are no plans to upgrade this control for 16-bit OpenInsight. However, with 32-bit OpenInsight there will eventually be support for any third-party control, including alternate grid controls.

[email protected]

SRP Computer Solutions, Inc.

Don,

My suggestion was not to throw the user out of the "protected" cell and back to where he came from. I let him stay in the cell, but immediately reset any changes he does to the content of the cell.

- Oystein -

Don .. are you willing to a) share it or b) sell it?

Don M.

Don,

Please email me about this. I don't have your address on file.

Thanks,

[email protected]

SRP Computer Solutions, Inc.

View this thread on the forum...