<h1>FAQs</h1><h2>Invisible Ink? Why can't I see what I send to the window in OS X?</h2><p>OS X buffers every thing before sending it to the visible window. Think of it as an invisible window where your information is arranged and polished before being put on stage. Even Martha Stewart would call this a "Good thing." Remember how much trouble it was in OS 9 when your window would flash and redraw and you had to spend hours trying to make the update smoothly? That never happens in X. It never happens because of this buffering.</p>
<p>So when does the system know to transfer the buffered pixels to the visible screen? Learning this took a great deal of study and a bit of bribery. At one point we were even required to sacrifice a chicken. In the end we learned a bunch of stuff that you don't even need to know because we built it all into FB. But there are a couple of rules that may be of interest as you and Martha share a cup of java and talk about the good old days in the joint.</p>
<p><b>Interesting thing #1: </b>When you use the <span class="pre"">PRINT</span> statement, FB automatically flushes the buffer for you.</p>
<p><b>Interesting thing #2:</b> Unless you lock your program in a tight, unending loop, the buffer will always be handled automatically when it passes through your event loop. An example of this kind of loop would be:</p>
<pre>
For x = 1 to _tenZillion
REM do a bunch of stuff
next
REM Yikes! There was no time to flush the window buffer!!
</pre>
<p><b>Interesting thing #3:</b> In cases where you have to draw or print or do something and you have the program locked into a loop, there is a way to make pixels move from the buffer to the visible window: <code><span style="color: #996633;">FlushWindowBuffer</span></code>.</p>
<p>Here's an easy example and one that you will see in the editor. As the editor searches through files, you will notice that the Find/Change window displays the number of files searched and the number of items found. Because the loop is tight and windows and files are opening and closing so rapidly, there isn't time for the Find/Change window to be updated. So each time the editor updates the information in the status field, it uses the FutureBASIC statement <code><span class="pre";">FlushWindowBuffer</pre>.</p>
<p>The big drawback... If you are planning on using this to make your 23 year old QuickBasic program run because you built it with 178 event loops that didn't really work as they should in 1989 -- forget it. <span class="pre">FlushWindowBuffer</span> will slow down your program to a crawl when over used. It is also not the answer for gamers. If you are going to write a game, use OpenGL or Gworlds with CopyBits. There are examples of both on the CD.</p>
