with-output-as-gadget (was Re: [mcclim-devel] Missing realizer in call to MAKE-PANE-1)
I wrote:
I now cannot get a radio-box to appear at all, even at the frame definition eg
(:panes (rb (with-radio-box () :a :b :c)))
so maybe something has regressed in that area?
No, it seems that radio/check boxes want only strings in the :choices list. I'm not sure the spec limits the items to strings - at least Lispworks CLIM is more inclusive. Anyhow, there still seems to be a problem in the with-output-as-gadget setup. I end up in the debugger with some layout function calling sheet-native-transformation on the parent of the check-box-pane which is NIL at this time. Anyone got a clue as who is responsible for providing a parent for this thing? Paul
Good evening, On Fri, Dec 23, 2005 at 12:25:31PM -0500, Paul Werkowski wrote:
Anyhow, there still seems to be a problem in the with-output-as-gadget setup. I end up in the debugger with some layout function calling sheet-native-transformation on the parent of the check-box-pane which is NIL at this time. Anyone got a clue as who is responsible for providing a parent for this thing?
Have you had a closer look at http://common-lisp.net/pipermail/mcclim-devel/2005-August/004246.html ? Regards, Max -- Max-Gerd Retzlaff <m.retzlaff@gmx.net> http://bl0rg.net/~mgr/ http://blogs.bl0rg.net/mgr/ (soon on http://(blog.)matroid.org) For your amusement: The best way to make a fire with two sticks is to make sure one of them is a match. -- Will Rogers
Anyhow, there still seems to be a problem in the with-output-as-gadget setup. I end up in the debugger with some layout function calling sheet-native-transformation on the parent of the check-box-pane which is NIL at this time. Anyone got a clue as who is responsible for providing a parent for this thing?
|Have you had a closer look at |http://common-lisp.net/pipermail/mcclim-devel/2005-August/004246.html ? | |Regards, |Max Heh, yes, I read it - and promptly forgot about it. Definite evidence of senility creeping in. So, now I can confirm his eloquent explanation since I've traveled far enough down that path to see the cause. Now, if I could just see the solution ;-{ Paul
| | So, now I can confirm his eloquent explanation since I've traveled far | enough | down that path to see the cause. Now, if I could just see the solution | ;-{ | I think I have it! Change the initialize-instance :after method on gadget-output-record to just doing (setf (gadget record) child) and move the rest of the stuff in there to just after the call to stream-add-output-record in with-output-as-gadget. Seems to work for the cases I have tried. Maybe it will work for Max as well? Paul
Hello On Sun, Dec 25, 2005 at 10:57:09AM -0500, Paul Werkowski wrote:
I think I have it!
Change the initialize-instance :after method on gadget-output-record to just doing
(setf (gadget record) child)
and move the rest of the stuff in there to just after the call to stream-add-output-record in with-output-as-gadget.
Seems to work for the cases I have tried. Maybe it will work for Max as well?
Yes, it's really better. Some of my tests and also Xophe's gadget-test work now. But there is still a SIMPLE-ERROR "There is no applicable method for the generic function #<STANDARD-GENERIC-FUNCTION SHEET-NATIVE-TRANSFORMATION (6)> when called with arguments (NIL)." for my example that has a WITH-OUTPUT-AS-GADGET inside an ACCEPTING-VALUES.. Btw. I've attached a patch for my interpretation of the description you've given for your changes.. There is a problem with the space requirement: I do my tests inside the CLIM-Listener and the scrollbar gets larger than needed, or better there is always some white space after the output-gadget (while its size seems to be related to the size of the actual gadget). (But I've just realized that I have a version of mcclim that is previous to Gilbert's recent work on the scrollbars. (Shame on me.)) And if I call a test in a freshly started Listener the output-gadget will always displayed in the top left corner of the Listener's application pane. Only if the first screen is "full" (that is the scrollbar gets actually useful) it will be displayed *after* the prompt (while it does not scroll past the gadget). Even a second or third output-gadget will be displayed in the top left corner on top of the previous gadgets, if the application pane does not yet scroll. I hope these confused descriptions are not too hard to understand. Thank you, Max -- Max-Gerd Retzlaff <m.retzlaff@gmx.net> For your amusement: Gravity is a myth, the Earth sucks.
Seems to work for the cases I have tried. Maybe it will work for Max as well?
|Yes, it's really better. Some of my tests and also Xophe's gadget-test |work now. But there is still a SIMPLE-ERROR | "There is no applicable method for the generic function| | #<STANDARD-GENERIC-FUNCTION SHEET-NATIVE-TRANSFORMATION (6)> |when | called with arguments (NIL)." |for my example that has a WITH-OUTPUT-AS-GADGET inside an |ACCEPTING-VALUES.. Btw. I've attached a patch for my interpretation of the description you've given for your changes.. I will try some more test - my Lispworks application uses w-o-a-g a lot so maybe that will turn more info. I will also try something with accepting-values. Re your patch, I've found that we can just get rid of the initialize-instance :after method. Make instance then should be called with the :gadget initarg instead of :child. Then the stuff in i-i :after can be stuffed into setup-gadget-record to save some space in the macro expansion. Will need to bind child with (gadget record) first. I'll post a more coherent patch, maybe tomorrow if testing goes well. Paul
| |Yes, it's really better. Some of my tests and also Xophe's gadget-test | |work now. But there is still a SIMPLE-ERROR | | "There is no applicable method for the generic function| | | #<STANDARD-GENERIC-FUNCTION SHEET-NATIVE-TRANSFORMATION (6)> |when | | called with arguments (NIL)." | |for my example that has a WITH-OUTPUT-AS-GADGET inside an | |ACCEPTING-VALUES.. | | Btw. I've attached a patch for my interpretation of the description | you've given for your changes.. | | I will try some more test - my Lispworks application uses w-o-a-g a lot | so maybe that will turn more info. I will also try something with | accepting-values. Looks like some more problems here when using accepting-values. 1) The function SETUP-GADGET-RECORD wants (WITH-SLOTS (HEIGHT) ...) but the ACCEPTING-VALUES-STREAM has no such slot :( 2) INVOKE-ACCEPTING-VALUES calls ERASE-OUTPUT-RECORD which signals SHEET-IS-NOT-A-CHILD with child being the gadget - a TOGGLE-BUTTON-PANE in my case, and sheet being the APPLICATION-PANE, the stream arg to ACCEPTING-VALUES. How did that happen? When the gadget is like CHECK-BOX-PANE (with children), then there is the same problem as before where the pane is not yet adopted when someone wants the native-transformation. So, the A-V stream must have a different protocol in play? | I'll post a more coherent patch, maybe tomorrow if testing goes well. I guess my fix is not ready for prime time as yet. Too bad, having gadget-based accept methods depends on all this working right. Paul
Here is a patch that gets with-output-as-gadget working better. It seems to work correctly but using updating-output has revealed some problems that I don't yet know how to fix (still working on it). The biggest problem with updating-output is that redisplay causes a new gadget-output-record to be created, but the gadget is not adopted by any sheet. The first gadget created remains as the adopted one but each redisplay causes the new, unadopted gadget to be "current". This shows up when erase-output-record is used and sheet-disown-child complains that the supplied gadget is not a child of sheet. Wrapping the with-output-as-gadget form as in (updating-output (stream :cache-value t) (with-output-as-gadget (stream) ...)) is a workaround. That workaround won't work in accepting-values though because invoke-updating-output fails with a no-applicable-method error on the stream ;-( The more minor problem (but still vexing) is that somehow updating-output ignores the stream-cursor-position adjustment that is supposed to move the cursor to after the gadget. The adjustment works fine without updating-output. I think the patch is safe to commit. Maybe someone has some ideas about solving the updating-output problems? Paul
participants (3)
-
Max-Gerd Retzlaff -
Paul Werkowski -
pw＠snoopy.mv.com