gft_robert@gsbacd.uchicago.edu (03/15/90)
I've to a handler in one stack that will need to process a lot of cards (ca. 1000). I thought it might be nice to provide one of those little "bar graphs" on screen which lets the user know how much has been done. The problem is: in my handler I'm going to each of the cards in question. In the interests of speed and appearance I lock the screen on entering the handler. So in my bar-graph-handler, I go back to the card I started on, unlock the screen, fill in the bar graph, lock the screen again, and go back where I was. Or so I thought. The screen won't unlock for me and my graph doesn't get drawn. Is there some trick to this? Can you lock and unlock the screen from within a handler? Here is pseudo-code for my handlers: on DoBigThing put id of this cd into origID lock screen push cd repeat with n=1 to BigNum go to cd n do lots of stuff (writing to file, etc.) DoMyGraph n,BigNum,origID end repeat pop cd end DoBigThing on DoMyGraph nowValue,maxValue,origID push cd go to origID unlock screen draw my graph using proportion of nowValue to maxValue lock screen pop cd end DoMyGraph This doesn't work even if I put the lock/unlock combo in the outer handler, surrounding the call to DoMyGraph. Any clues? Help much appreciated! Robert ============================================================================ = gft_robert@gsbacd.uchicago.edu * generic disclaimer: * "It's more fun to = = * all my opinions are * compute" = = * mine * -Kraftwerk = ============================================================================
bskendig@phoenix.Princeton.EDU (Brian Kendig) (03/15/90)
In article <8062@tank.uchicago.edu> gft_robert@gsbacd.uchicago.edu writes: >I've to a handler in one stack that will need to process a lot of cards (ca. >1000). I thought it might be nice to provide one of those little "bar >graphs" on screen which lets the user know how much has been done. A very good idea! I wish more programmers would thing of things like this... >The problem is: in my handler I'm going to each of the cards in question. In >the interests of speed and appearance I lock the screen on entering the >handler. So in my bar-graph-handler, I go back to the card I started on, >unlock the screen, fill in the bar graph, lock the screen again, and go back >where I was. Gaack! You're not *serious*, are you? If you visit one thousand cards, but stop at card 1 in between every stop, then you're making two thousand trips -- enough to make someone doubly impatient! Your handler shouldn't mess with the screen like that; it'll only slow things down. There are two obvious alternatives: - Don't bother locking the screen at all. Let each card visibly flip past. This way, the user will (we hope!) be satisfied that he knows something is going on, and if there's some ordered feature about the cards (say, sorted by last name, or by number), then the user might get some idea of how far along the computer is in its operation. - Lock the screen, and put a status indication in the message box. Locking the screen during a lot of card-flipping helps to speed it up somewhat. Put a message such as "xx% done..." into the box, and the user should be satisfied. >Or so I thought. The screen won't unlock for me and my graph doesn't get >drawn. Is there some trick to this? Can you lock and unlock the screen from >within a handler? The display is only updated when you change cards, *not* when you unlock the screen. Therefore, if you unlock the screen *before* going to the `status' card, then lock it again after getting there, your status display should work (although it'll be a card behind, but some reworking of your code should fix that). Hope this helps! << Brian >> -- | Brian S. Kendig \ Macintosh | Engineering, | bskendig | | Computer Engineering |\ Thought | USS Enterprise | @phoenix.Princeton.EDU | Princeton University |_\ Police | -= NCC-1701-D =- | @PUCC.BITNET | ... s l o w l y, s l o w l y, w i t h t h e v e l o c i t y o f l o v e.
tim@hoptoad.uucp (Tim Maroney) (03/19/90)
>In article <8062@tank.uchicago.edu> gft_robert@gsbacd.uchicago.edu writes: >>I've to a handler in one stack that will need to process a lot of cards (ca. >>1000). I thought it might be nice to provide one of those little "bar >>graphs" on screen which lets the user know how much has been done. >> >>The problem is: in my handler I'm going to each of the cards in question. In >>the interests of speed and appearance I lock the screen on entering the >>handler. So in my bar-graph-handler, I go back to the card I started on, >>unlock the screen, fill in the bar graph, lock the screen again, and go back >>where I was. In article <14541@phoenix.Princeton.EDU> bskendig@phoenix.Princeton.EDU (Brian Kendig) writes: >Gaack! You're not *serious*, are you? > >If you visit one thousand cards, but stop at card 1 in between every >stop, then you're making two thousand trips -- enough to make someone >doubly impatient! Gaack! You're not unaware that any half-sane database program caches recently visited file pages on a frequency of use basis, are you? I doubt that this would be significantly slower than just going from card to card. HyperCard redraws cards very fast on successive visits, and the frequently visited card should always be cached in RAM. There is some overhead, but it's nothing like the factor two the above would seem to suggest. >>Or so I thought. The screen won't unlock for me and my graph doesn't get >>drawn. Is there some trick to this? Can you lock and unlock the screen from >>within a handler? Probably a nesting problem. Each "unlock screen" only undoes the most recent "lock screen". There has to be an exact match in the number of the commands. Probably when you're doing your lock screen, the screen is already locked by something else you're doing. You can check this by putting in a test for "the lockScreen" property. I routinely lock the screen, change a card, and then unlock the screen with a visual effect in my scripts. It works fine, and it makes card operations like "fill in the blanks from a text file" look a lot cleaner. >The display is only updated when you change cards, *not* when you >unlock the screen. Therefore, if you unlock the screen *before* going >to the `status' card, then lock it again after getting there, your >status display should work (although it'll be a card behind, but some >reworking of your code should fix that). No, "unlock screen" actually updates the screen right then. It does not wait until you change cards. Incidentally, you might consider using a dialog instead of a card. While redrawing is fast, most graphic operations are not. If you're drawing the bar graph by doing somethinglike choosing the rectangle tool and dragging, you are imposing a lot of overhead. A dialog XCMD or XFCN using QuickDraw could save you a lot of time at run time (though not at development time!) -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com "As I was walking among the fires of Hell, delighted with the enjoyments of Genius; which to Angels look like torment and insanity. I collected some of their Proverbs..." - Blake, "The Marriage of Heaven and Hell"