[cells-devel] Celtk: mk-entry: How to set initial value?

[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