[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference bulova::decw_jan-89_to_nov-90

Title:	DECWINDOWS 26-JAN-89 to 29-NOV-90
Notice:	See 1639.0 for VMS V5.3 kit; 2043.0 for 5.4 IFT kit
Moderator:	STAR::VATNE

Created:	Mon Oct 30 1989
Last Modified:	Mon Dec 31 1990
Last Successful Update:	Fri Jun 06 1997
Number of topics:	3726
Total number of notes:	19516

1519.0. "Window updates in a callback routine" by YIPPEE::TARANTOLA (Faster than VMS!) Tue Oct 03 1989 12:19

I put this note on behalf of a busy friend. Here it is her problem description:

"
  I want to display a Modal caution box from a callback routine and wait for the
  user answer within the callback. I don't get the behavior I expect, in fact
  the caution box is displayed after the end of the callback only, and so I am
  not able to use the user answer within the callback.

  I realized also that all the text I write in STEXT or ListBox widgets from
  the callback routine is not displayed in the windows before the end of the
  callback. I understand that it has to do with the expose events that will
  be dispatched from the main loop at the next event only. Is it right?

  I have tried to use X$Flush after each writing, it worked but at the end of
  the callback the vaxstation crashed...

  What can I do to get the behavior I expect?
"
  Any idea will be appreciated,

Thanks a lot,

	-Carlo

T.R	Title	User	Personal Name	Date	Lines
1519.1	Wrong model?	CASEE::LACROIX	Object oriented dog food? No, sorry	`Tue Oct 03 1989 12:50`	13
	There are ways to do it, but you should consider rethinking a bit your application to fit better in the DECwindows model: generally speaking, you should do your stuff in the callback routine real quick, and return. Denis. PS: > I have tried to use X$Flush after each writing, it worked but > at the end of the callback the vaxstation crashed... If this really happened, submit a QAR! Nothing should have crashed, except maybe your application!
1519.2	More here than meets the eye	SDSVAX::SWEENEY	I was focused when focus wasnt cool	`Tue Oct 03 1989 18:17`	20
	The critical point that .0 misses is that "input" is an event that's mediated by the toolkit's main loop. Input and output are not synchronized in a callback, in fact, by adding XFlush calls, you frustrate the optimizations of the asynchronous client-server interaction. Here's a way to think about it: When you get a callback, you can be sure the event took place. You can manage, unmanage, edit, draw, etc. making no assumptions about the completion of those operations at the time you exit from the callback. On the next callback, etc., you can be sure that all of the previous callback's operations have completed, ie the client has flushed the output buffer. Don't expect one callback to be an "atomic" dialog.
1519.3	Yes but ...	YIPPEE::GUBERT	Compilation failed at line 1...	`Thu Oct 05 1989 04:26`	10
	Ref: .1 We realized that we should exit quickly from the callback but what if the user action needs a lot of computing and window displays to be done (run an expert system from a user action via a callback...) If it is not done in the callback where should it take place? Do we have to requeue an event in the X event queue for instance? Thanks a lot, arlette
1519.4	Long computing intervals	SDSVAX::SWEENEY	I was focused when focus wasnt cool	`Thu Oct 05 1989 08:53`	8
	The Style Guide discusses long computing intervals, and so have many notes in this conference and the DECWINDOWS_PROGRAMMING conference. Some solutions off the top of my head are: (a) watch cursor (b) work-in-progress widget (c) work procedures