[mcclim-devel] accepting-values: prompts not clickable, no redraw, improper output recording?
The attached test case does produce strange results for accepting-values calls. In the test case you will find 2 commands. The first one causes an implicit accepting values to be generated when you click on the menu button (or type "Implicit AV<ret>" in the interactor pane). In my CVS checkout (about 12 hours old), the Implicit AV command presents three prompts, of that only the last one accepts input. Notice, when damaging the draw area only the last one is repainted, even though not shown first. Explicit AV also generates three prompts, of that the first and the last accepts input. Both are redrawn upon X damage. I also put up a video of this behaviour in case it is not reproducable for you. They are at http://clemens.endorphin.org/strange-clim-artefacts/ (Most of them are MPEG4 provided with four different flavors of fourcc. The last is in Motion JPEG, but quite huge. I won't give an off-topic explaination here of what caused the problems seen by those participating in the IRC discussion of this bug, but when you're interested http://itdp.fh-biergarten.de/~itdp/html/mplayer-users/2005-03/msg00069.html ) Regards, -- Fruhwirth Clemens - http://clemens.endorphin.org for robots: sp4mtrap@endorphin.org
Clemens Fruhwirth <clemens@endorphin.org> wrote:
The attached test case does produce strange results for accepting-values calls.
After a fair amount of source reading: Not a bug. Paolo, thanks for adding it to http://mcclim.cliki.net/Bug. I removed it. The follownig code is not a valid test case. See below.
(accepting-values (input-stream) (accept 'string :prompt "A string" :stream input-stream ) (terpri input-stream) (accept 'integer :prompt "An integer" :stream input-stream ) (terpri input-stream) (accept 'integer :prompt "An integer" :stream input-stream ))))
From the CLIM spec, 6th paragraph in the description of accepting-values in Chapter 26:
"Inside of accepting-values, programmers should supply the :query-identifier argument to each call to accept. If :query-identifier is not explicitly supplied, the prompt for that call to accept is used as the query identifier. Thus, if :query-identifier is not supplied, programmers must ensure that all of the prompts are different. If there is more than one call to accept with the same query identifier, the behavior of accepting-values is unspecified." -- Fruhwirth Clemens - http://clemens.endorphin.org for robots: sp4mtrap@endorphin.org
Clemens Fruhwirth <clemens@endorphin.org> wrote:
Clemens Fruhwirth <clemens@endorphin.org> wrote:
The attached test case does produce strange results for accepting-values calls.
After a fair amount of source reading: Not a bug.
I changed my feelings regarding this issue. As even McCLIM makes incorrect use of its own facilities, I decided that it's better that accepting-values gives at least an annoying warning if it detects an incorrect usage pattern. This is easy to do, see the serial-checking patch below. Regarding McCLIM's own incorrect use of accepting-values, see commands-accepting-values-fix.diff. The partial command parser must generate :query-identifier for all accept statements, because it does not generate unique prompts. This is bug becomes visible when using (define-foobar-command (com-foobar :menu t :name t) ((x 'integer) (y 'integer)) ()) When the command is invoked via menu or via a partial command, the two integer arguments cause two identical prompts, namely "Enter an integer". The problem with this is that accepting-values uses :prompt when :query-identifier is missing, and as the command parser hasn't supplied unique prompts, the query-identifiers are non-unique too. Non-unique query-identifiers in accepting-values cause strange screen corruption. I really don't like that and when this happens to a new user - as it happend to me - the user has little clue where to start searching for a remedy and might even be tempted not to search at all because this looks like a toolkit bug. So, we better spend some time on checking usage patterns. -- Fruhwirth Clemens - http://clemens.endorphin.org for robots: sp4mtrap@endorphin.org
participants (1)
-
Clemens Fruhwirth