On Sat, 15 Jan 2005 15:39:35 +0100, Timothy Moore moore@bricoworks.com wrote:
On Jan 15, 2005, at 7:35 AM, Anthony Juckel wrote:
[...snip...]
The way that I've tried to accomplish this is that I've created a presentation type for each slot in the object (I know there must be a more general solution...). Then I've defined an accept method for these presentation types. Now, in my accept method, I'm trying to use menu-choose as follows:
There are a couple of ways you can go here, depending on how much flexibility you need in accepting the values. CLIM has useful presentation types for accepting one of several values, MEMBER and COMPLETION. The accept method for COMPLETION doesn't directly present a menu; it's a text field in which one can use tab completion and get a menu by right clicking. I'll return to just using a menu in a second.
This is actually the way that I started out (using MEMBER), so perhaps I'll settle with that for now. One thing about the usability though, it would be nice if you could navigate the dialog completely without using the mouse. Currently, I have to (at least, I believe I have to) click on the first field, then I can type in my value and hit enter to move to the next, but I have to again use the mouse to click the exit button.
You can define presentation types that inherit from completion or directly use the COMPLETION type to accept values (either within ACCEPTING-VALUES) or elsewhere:
(setf (slot-value obj 'slot-a) (accept `(completion ,(allowed-values 'slot-a)) stream))
This is nice because it can be abstracted in a function in the obvious way.
You could also define a presentation type that uses the slot name as an argument:
(define-presentation-type slot-val (slot-name) :inherit-from t) (define-presentation-method accept (type slot-val) stream view &key) (accept `(completion ,(allowed-values ,slot-name)) stream view))
(clim:define-presentation-method clim:accept ((type slot-a) stream view &key &allow-other-keys) (declare (ignore view)) (clim:menu-choose (allowed-values 'slot-a)))
I then create a dialog using accepting-values, which in turn calls this accept method. This isn't giving me the desired behavior though.
I believe that's because the control flow within accepting-values is very strange. I'm a bit surprised that this works at all. Are you looking for a pop-up menu, or a list of choices embedded in the dialog? The right way to do this is probably with gadgets and gadget views. Gadget views are not implemented yet in McCLIM, but they are certainly on our list. In an ideal world the view in a dialog for the completion type would present a pop-up menu.
I was looking for a pop-up menu, which is what I get with the above. When I click on the field to edit, a popup menu is drawn with the allowed values for that field.
If you do implement a custom accept method like this, you should probably define your own view and specialize this method on the view so that you can textually input values in other input contexts.
When I click on the input field for slot-a, I do get the proper menu displayed, but when I first choose an option, it doesn't appear to have any effect, but does redisplay the menu again. After choosing a menu option a second time, the choice does indeed seem to stick.
What do you mean by "choose an option;" another option in the dialog box? It's possible that a recent update to the dialog code would fix your problem. Otherwise I'd need to see your code to figure out what's going on as I certainly haven't considered yet doing things like calling menu-choose within accepting values.
By "choose an option" I was referring to clicking on a particular menu item in the popup menu. I use the term field to refer to the different elements that I'm editing within accepting-values. So I would click on a field, select an item from the menu, select an item from the new menu to get the value to stick.
Thank you for your ideas.
Anthony W. Juckel