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