CAH0@bunny.gte.com (Chuck Hoffman) (04/29/91)
I'm new to Mac programming, though not new to programming, and haven't read this list in some time, so forgive me if this subject has been covered recently. Using THINK C 4.0, and its Debugger, I've written a short program with three windows open. With the Debugger, I'm finding that about every second there is an update event generated for one or the other of the second and third windows. I get all the update events I expect; these are extra events, not in response to anything my program is doing. If I select window 2, I get a stream of updates for 2. If I select window 3, I get updates for 3. If I select window 1, I get an update for 1 followed by updates for either 2 or 3, depending on which I used last. There are no extra or unexpected activate or deactivate events. There is nothing in any of the windows yet, because I've just begun to code the program. I am running under MultiFinder. Windows 2 and 3 have goaway boxes, which don't seem to have anything to do with the symptom. The symptom would not be apparent to a user of the program, except that I will eventually use the update events to trigger redrawing of the window (even that should still be not apparent). So, where are the extra update events coming from? My code? System 6.0.7 (Mac-IIcx)? MultiFinder? THINK C Debugger? Virex or Disinfectant INIT (I'm running both)? Thanks in advance. Chuck Hoffman, GTE Laboratories, Inc. | I'm not sure why we're here, cah0@bunny.gte.com | but I am sure that while we're Telephone (U.S.A.) 617-466-2131 | here, we're supposed to help GTE VoiceNet: 679-2131 | each other. GTE Telemail: C.HOFFMAN |
niko@iastate.edu (Schuessler Nikolaus E) (04/30/91)
In article <11082@bunny.GTE.COM> CAH0@bunny.gte.com (Chuck Hoffman) writes: > > Using THINK C 4.0, and its Debugger, I've written a short program with >three windows open. With the Debugger, I'm finding that about every >second there is an update event generated for one or the other of the >second and third windows. I get all the update events I expect; these are I was writing a game and it only had one window. I had it redraw the screen every time there was an update event... Same problem! There were so many update events that that the screen constantly flickered while it was doing the updating... doesn't GetNextEvent remove the event? Do you HAVE to use the BEGIN UPDATE and END UPDATE procedures to get it to stop? --
2fmlcalls@kuhub.cc.ukans.edu (04/30/91)
In article <1991Apr29.170744.12029@news.iastate.edu>, niko@iastate.edu (Schuessler Nikolaus E) writes: > In article <11082@bunny.GTE.COM> CAH0@bunny.gte.com (Chuck Hoffman) writes: >>three windows open. With the Debugger, I'm finding that about every >>second there is an update event generated for one or the other of the >>second and third windows. I get all the update events I expect; these are > > I was writing a game and it only had one window. I had it redraw the > screen every time there was an update event... Same problem! There > were so many update events that that the screen constantly flickered > while it was doing the updating... > > doesn't GetNextEvent remove the event? > Do you HAVE to use the BEGIN UPDATE and END UPDATE procedures to > get it to stop? No - GetNextEvent does not remove it. My understanding is that the event is removed, but the update rgn is not cleared. Begin/EndUpdate do that. So, yes, you need BeginUpdate and EndUpdate. (Don't bum, I had the same problem once and it was a game as well - real fast game, huh? :)) john calhoun
gourdol@imag.imag.fr (Gourdol Arnaud) (04/30/91)
>In article <11082@bunny.GTE.COM> CAH0@bunny.gte.com (Chuck Hoffman) writes: >> Using THINK C 4.0, and its Debugger, I've written a short program with >>three windows open. With the Debugger, I'm finding that about every >>second there is an update event generated for one or the other of the >>second and third windows. I get all the update events I expect; these are > >I was writing a game and it only had one window. I had it redraw the >screen every time there was an update event... Same problem! There >were so many update events that that the screen constantly flickered >while it was doing the updating... > >doesn't GetNextEvent remove the event? GetNextEvent (but you should use WaitNextEvent) DOES remove the events from the event queue. Note that update events are not standards events, as they are generated by the window manager on idle events. That is, when an idle event is received (aka null event), the window manager sweeps the window list, and if it finds a window whose updateRgn is not empty, it post an update event for this window. This implies that you can do as many InvalRect, InvalRgn as you want, you will receive only ONE updateEvt the next time you call GNE or WNE. >Do you HAVE to use the BEGIN UPDATE and END UPDATE procedures to >get it to stop? Got'it. That's what you have to do. Calling BeginUpdate changes the visRgn to something appropriate (the intersection of the visRgn and the updateRgn) and, most importantely, sets the updateRgn to the emptyRgn. Calling EndUpdate later restores the visRgn to its previous value. As the updateRgn is now empty, the window manager won't post other updateEvt for this window. Also, don't forget to set the correct port before calling BeginUpdate and to restore it after EndUpdate. Arno. -- /======================//==========================================/ / Arnaud Gourdol. // On the Netland: Gourdol@imag.fr / / // Via AppleLink: Gourdol@imag.fr@INTERNET# / /======================//==========================================/
sokoloff@athena.mit.edu (James T Sokoloff) (04/30/91)
> doesn't GetNextEvent remove the event? > Do you HAVE to use the BEGIN UPDATE and END UPDATE procedures to > get it to stop? No, Update Events are no queded in the fashion of all the level 3-5 events. Update events(priority level 2) are generated when there are no higher level events to return. Update events are generated by the system in real-time (At the call to GNE, WNE) and not when the call to InvalRgn() or InvalRect() is executed) Yes, you HAVE to call BeginUpdate() & endupdate() Actually, I don't see any reason for not wanting to do so. These calls make life much easier by setting up the visRgn to some intelligent region for the update. Neither call requires vast knowledge of the Mac. They are easy to use and very helpful... Please, save yourself some time and just use the calls provided for you... Cheers, Jim Sokoloff PS: No flames; I know you don't actually HAVE to call begin & end update; you could call ValidRgn/Rect, but this is much more difficult to explain, and has only limited usefullness (esp. to beginners who just want things to work in a non-coplicated manner)
hairston@henry.ece.cmu.edu (David Hairston) (04/30/91)
[CAH0@bunny.gte.com (Chuck Hoffman) writes:]
[] Using THINK C 4.0, and its Debugger, I've written a short program with
[] three windows open. With the Debugger, I'm finding that about every
[] second there is an update event generated for one or the other of the
[] second and third windows. I get all the update events I expect; these are
[niko@iastate.edu (Schuessler Nikolaus E) writes:]
[] I was writing a game and it only had one window. I had it redraw the
[] screen every time there was an update event... Same problem! There
[] were so many update events that that the screen constantly flickered
[] while it was doing the updating...
[]
[] doesn't GetNextEvent remove the event?
[] Do you HAVE to use the BEGIN UPDATE and END UPDATE procedures to
[] get it to stop?
hmm, there may be two problems here:
1) i think the debugger windows, when activated, will cause invalidation
of your application windows thus generating update events. i'm not
sure about this, tho.
2) do you have to use BeginUpdate(), EndUpdate()? well technically no
but only if you know what you're doing (and even then it isn't the
wisest thing to do ;). Basically when a windows updateRgn is not
empty, it will get an update event. BeginUpdate() and EndUpdate()
manage this in a smart way. For more details, read IM-I Chap. 9,
The Window Manager and specifically "How a Window is Drawn".
GetNextEvent/WaitNextEvent will remove the event from the queue but
won't remove the reason the event is getting generated, hence the
continuing generation of those events.
-dave-
hairston@henry.ece.cmu.eduwdh@well.sf.ca.us (Bill Hofmann) (04/30/91)
In article <1991Apr29.170744.12029@news.iastate.edu> niko@iastate.edu (Schuessler Nikolaus E) writes: >doesn't GetNextEvent remove the event? >Do you HAVE to use the BEGIN UPDATE and END UPDATE procedures to >get it to stop? YES! The updateEvt is generated by the Event Manager whenever no other events are pending. What it does is look down the list of open windows, and if the window "needs to be updated", an update event is generated. BeginUpdate/ EndUpdate signal the system that the update has been handled. One poorly documented fact is that BeginUpdate/EndUpdate is not reentrant. Don't try to call GNE/WNE inside it, you'll regret it. As for the other person's problem, it may be because you're stepping in the debugger, and the debugger windows cover your windows. I believe there's a flag which you can set in the project to make the debugger prevent this (you may need to boost the debugger partition size). -Bill Hofmann
sokoloff@athena.mit.edu (James T Sokoloff) (05/01/91)
David writes: > 1) i think the debugger windows, when activated, will cause invalidation > of your application windows thus generating update events. i'm not > sure about this, tho. No, this is not the case. Think C debugger saves the bits that are going to be destroyed when creating the debug windows. This causes the debugger to be less intrusive on the functioning of your program... Jim Sokoloff