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

[Ken Tilton]

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 , at 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
> 
> 
>