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
_______________________________________________
cells-devel site list
cells-devel@common-lisp.net
http://common-lisp.net/mailman/listinfo/cells-devel
