Re: non-modal file save dialog
From: Roger Oberholtzer (roger_at_acme.pacific.pacific)
Date: 03/12/04
- Next message: Wolf Grossi: "tcl/tk8.4.4 & Win2K/SP4"
- Previous message: Patrick Cailly : METRONOME & BASIC: "Re: Can't get stupid, simple Tktable code to work"
- In reply to: Bruce Hartweg: "Re: non-modal file save dialog"
- Next in thread: Bruce Hartweg: "Re: non-modal file save dialog"
- Reply: Bruce Hartweg: "Re: non-modal file save dialog"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 12 Mar 2004 09:45:35 +0100
In fact, the application is very event driven. It controlls data
collection from many sources (serial, network, firewire). However, all
work it needs to do is not event driven. Thst is, it also has 'work'
procedures that deal with the results of all the acynchronous events
bringing in data. These events are as quick as possible and do not process
the data they may obtain. This was they are very quickly available for the
next event. We have basically divided the application into those things
that must be done now (the event part) and the parts that can be done as
time permits (the 'work' part). Tcl is, from our program's point of view,
a 'work' procedure. Only because I do not know how to have Tcl tell me
that there is X related work to do, so call me. But that is a whole
different topic (an a doable one in our application and how it uses Tcl).
We have toyed with the idea of making our application a task in Tcl. What
has stopped us is that we make great use of SIGIO/poll() in our event
loop. Our current implementation allows us to ensure that our event
mechanisim does not inetefere with the Tk event mechanisim. When we get
time we may implement this as a test. Still, if we do so, we are at the
mercy of any future Tk event logic changes.
As to the modal dialog, it does not stop our events from happening.
However, the work procedures do stop. After a while, this becomes a
problem.
The current case in point is a live moving map (love that canvas) from a
GPS. As the vehicle containing the application travels, this map is kept
up to date. We want to offer the user a chance to do a snapshot of the
map. So, we were going to offer a file save dialog. We are rethinking
that strategy.
On Thu, 11 Mar 2004 10:46:14 +0100, Bruce Hartweg wrote:
>
>
> Roger Oberholtzer wrote:
>> Your test acts as expected. From wish.
>>
>> I have a C application that is calling Tcl_DoOneEven() to make the event
>> loop function. Works nice in my application. However, if such a window
>> is popped up by some code executed in a call to Tcl_DoOneEvent(), it seems
>> that Tcl_DoOneEvent() does not return until the window is dealt with.
>>
>>
>
> well, I'm not sure how you're doing things, but it seems you have some
> fixed synchronous processing that occasionally processes events, instead
> of your application being event driven. so yes that call will wait until
> the dialog is finished to continue, but (as shown from the wish) events
> will still be processed, so If you can change you data monitoring to
> be event driven, then those events will still be processed when the
> dialog is up.
>
> Again, I don't know how large your program is, or how easy it would
> be, but if possible it could help if you flipped your application around
> i.e. instead of your C code in control occasionally calling into tcl,
> just put the main processing chuncks into an extension and let you
> main control just be a wish script that does package require MyCoolStuff.
>
> Bruce
- Next message: Wolf Grossi: "tcl/tk8.4.4 & Win2K/SP4"
- Previous message: Patrick Cailly : METRONOME & BASIC: "Re: Can't get stupid, simple Tktable code to work"
- In reply to: Bruce Hartweg: "Re: non-modal file save dialog"
- Next in thread: Bruce Hartweg: "Re: non-modal file save dialog"
- Reply: Bruce Hartweg: "Re: non-modal file save dialog"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|