Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

IMG question

1 view
Skip to first unread message

Stuart

unread,
Nov 21, 2009, 4:21:36 PM11/21/09
to

I was playing around with the IMG package (in conjunction with Tcl/Tk
8.4 ) and I have one issue that
I can't seem to get around. I'm using Img to capture a window and
create a GIF file. The widget allows
the user to select among print options with a menubutton. The problem
is that it seems no matter
what I do, that part of the menu is always captured in the GIF file.
I've tried things like

tkwait win .widget.print.menu or even destroy .widget.print.menu
before calling a routine to
capture the window. But no matter, the menu always winds up in the GIF
file. I've also tried
to just select the canvas that is part of the widget, but the menu
when activated extends
over the canvas and shows up in the GIF file.

Is there some technique that could be used to make sure the menu
disappears before I try
to capture the canvas?

set info2 "$m add command -label \"Make Plot & Print \"\
-command { destroy .$GAUGE.but.pri.menu; windowToFile .
$GAUGE }"

This is the menu option that initiates the capture and print process
via windowToFile .

I can't seem to get rid the menu from the plotfile. I suppose I could
hack windowToFile
(written by D. Easton) to ignore any subwindow with "menu" in it, but
I was wondering if
there was a more "elegant" solution.

Stuart

Stuart

unread,
Nov 21, 2009, 4:29:41 PM11/21/09
to
On Nov 21, 11:21 am, Stuart <bigdak...@aol.com> wrote:

<snip>

> I can't seem to get rid the menu from the plotfile. I suppose I could
> hack windowToFile
> (written by D. Easton) to ignore any subwindow with "menu" in it

Well even that won't work, since I'm just trying to capture the canvas
part of the widget.

Stuart

Stuart

unread,
Nov 21, 2009, 10:12:19 PM11/21/09
to
On Nov 21, 11:21 am, Stuart <bigdak...@aol.com> wrote:
> I was playing around with the IMG package (in conjunction with Tcl/Tk
> 8.4 ) and I have one issue that
> I can't seem to get around. I'm using Img to capture a window and
> create a GIF file. The widget allows
> the user to select among print options with a menubutton. The problem
> is that it seems no matter
> what I do, that part of the menu is always captured in the GIF file.
> I've tried things like
>
> tkwait win .widget.print.menu or even destroy .widget.print.menu
> before calling a routine to
> capture the window. But no matter, the menu always winds up in the GIF
> file. I've also tried
> to just select the canvas that is part of the widget, but the menu
> when activated extends
> over the canvas and shows up in the GIF file.
>
> Is there some technique that could be used to make sure the menu
> disappears before I try
> to capture the canvas?
>
> set info2 "$m add command -label \"Make Plot & Print \"\
> -command { destroy .$GAUGE.but.pri.menu; windowToFile .
> $GAUGE }"
>

Well I tried this modification:

-command {after 500 windowToFile .$GAUGE }"

That worked. Does this mean the menu widget doesn't disappear until
the "command" is completed?
I'm not sure how robust this will be, but so far I've tried it on a
busy system and I haven't
had the menu appear in any of the plots.

Stuart

Donal K. Fellows

unread,
Nov 22, 2009, 7:14:58 AM11/22/09
to
On 22 Nov, 03:12, Stuart <bigdak...@aol.com> wrote:
> Does this mean the menu widget doesn't disappear until
> the "command" is completed?

In short, yes. Tk puts off redrawing things until after the currently-
ready events have all been processed so that all updates to the screen
can be done at once. Usually this works really well and makes Tk feel
really snappy and fast, but occasionally (e.g., this time) it matters.

> I'm not sure how robust this will be, but so far I've tried it on a
> busy system and I haven't had the menu appear in any of the plots.

It can go wrong on a *very* busy system where there's a lot going on
at once, so it's better to use:

after idle after 10 windowToFile .$GAUGE

The [after idle] postpones things until Tk's done its internal
redrawing, and the [after 10] gives a moment for any queued external
events (especially certain kinds of window-system initiated redraws)
to be handled.

Donal.

Stuart

unread,
Nov 23, 2009, 2:12:36 AM11/23/09
to
On Nov 22, 2:14 am, "Donal K. Fellows"

Thanks for the info.

Yours,

Stuart

0 new messages