Frank Goenninger wrote:

Ok - so here goes the use case:

1. A user is present a list of devices (PowerMasters, "pm") (in listbox

:pm-list).

2. The entry field :call-sign entry is empty.

3. The user selects an item in the listbox. This sets a slot in the

parent model (named :pmutil-gui) with the value of the corresponding element of the listbox's item-factory.

4. *** Now the entry field - as it does a c?n on that "selected-pm" -

should get the callsign of that selected pm. The user is then able to change that value to a new one by overtyping it.

5. The user selects a button that reads the value of :callsign-entry

and sends that value to the pm device (this works already).

6. After programming the device with the new callsign the listbox has

to refresh,it is re-reading the items such that no item is selected. The :callsign-entry should be set to "" (= cleared) because no pm is selected.

7. Goto step 3

That's it. Does this make it more clear.

Yes. Your original spec off a bit, I think: If perchance the listbox got created populated and with some value initially selected, you would want its callsign prefilling the entry widget, so in fact the rule /always/ applies. So:

(defmacro c?+n (&body body) `(make-c-dependent :inputp t :code ',body :value-state :unevaluated :rule (c-lambda ,@body)))

That is the same configuration as for c?, but it specifies that inputp is t, meaning one can also setf the critter.

This should Just Work with the same rule you had. The edit code will be setfing away until the selection changes and then, wham, in comes the new callsign as a prefill for ongoing editing.

kt

ps. c?n is like the above but has without-c-dependency around the rule, so it runs only once and then, without any dependencies to talk to, gets optimized away. k

Meanhwile I am chewing on your details below ... Thx!!!

Frank

Am 22.11.2007 um 14:42 schrieb Ken Tilton:

...

Frank Goenninger wrote:

...

Hi Kenny, hi all (would be interesting to see who actually monitors this ?) I have an entry widget like this: (mk-entry :id :callsign-entry :value (c?n (let ((pm (selected-pm (fm^ :pmutil-gui)))) (if pm (callsign pm)))) :enabled (c? (pm-selected-p (fm^ :pmutil-gui))) :width 17 :tk-justify 'left :relief 'sunken :borderwidth 1 :parent-x 424 :parent-y 321 :background (c_? (required-field-color .parent)) :tile? nil) Intention is to be able to set the value initially and afterwards have the rule kick-in and setting the value automagically. Alas, neither the initial setting of the value really works nor does the cell rule fire ...

You do not show nor can I guess what you mean by "set the value initially". If you are supplying a value initarg, then none of the above applies. If you are making the instance and then in the next line of code setf'ing the value that is still not "initially". Please elucidate.

Meanwhile, c?n goes the other way: the rule runs once to come up with an initial value and then becomes a classic input cell.

As for what you want, it seems a little ugly in that callsign-entry is somewhat a slave to pmutil-gui and somewhat not, and this confusion is making the cells code hard to write. this may be clearer, btw, when we understand better how you meant to supply a value "initially".

There is/was something called c-drifter and c-drifter-absolute is close to what you want, but a quick look suggests they are broken precisely at the initialization point, and any fix makes no sense: does this thing depend on its rule or not?

If you really need to do this...

(c? (let ((x <rule>)) (if .cache-bound-p <initial-value> x)))

You need the rule to run even if not cache-bound-p (ie, initially) to set up the dependencies.

That too is ugly, again I think because of the original confusion over whether the one widget really is a slave to the other. I would resolve that and not get caught up with clever cells tricks.

kt