[futurebasic] Re: Building window invisibly

Message: < previous - next > : Reply : Subscribe : Cleanse
Home   : December 1997 : Group Archive : Group : All Groups

From: Rick Brown <rbrown@...>
Date: Tue, 23 Dec 1997 23:17:49 -0600
Ken Shmidheiser wrote:
> I'm sure this has been addressed before, but could someone help me
> understand the concept of building a window invisibly. On Page 81, the
> Handbook says to make a window invisible, you change the ID to negative,
> and then restore it to positive to make it visible again. I have done this
> in the example below, but the window contents are gone when the positive ID
> is restored.

I don't think it's the concept of invisible windows that's eluding you
here, but rather the concept of window refresh events.

When any part of a window becomes newly visible (for example if you
bring the window to the front, or you turn it from invisible to
visible), the system generates a "refresh event" for that window, and
stores the event in a queue.  But FB does not act on the event
immediately: instead, FB waits until it encounters a HANDLEEVENTS
statement.  In addition to many other things that FB does during
HANDLEEVENTS, it sees if the event queue contains any refresh events for
its windows.  If it does, then FB redraws the window's edit fields,
buttons, scroll bars and picture fields.

In fewer words, this means that you need to execute at least one
HANDLEEVENTS statement some time after you make the window
visible--that's when the redrawing of the window's contents takes place.

If the only things you put into the window while it was invisible were
buttons, scroll bars, edit fields and picture fields, then FB will
redraw these for you "automatically" when HANDLEEVENTS executes.  But if
you've drawn to the window in other ways (e.g., with PRINT statements or
PLOT statements or such), then those won't automatically refresh.

> Has anyone been able to get Exercise 18.3 on Page 114 in "Programming The
> Macintosh with FB II" to work?

Yes.  I typed it in exactly as shown and it worked fine.  I had to
create another file called "myFile.rsrc", and paste a PICT resource into
it (giving it ID #128), and put the "myFile.rsrc" file into the same
folder as the app, in order to make it work.  Did you do all that?

> Here's my work-around code:
> LOCAL FN splashScreen
>   WINDOW #1,"",(0,0)-(360,215),-_dialogFrame
>   splashScreen& = FN GETPICTURE(128)
>   PICTURE (0,0), splashScreen&
> I'm concerned if I had more resources than just one, would this continue to
> work.

I'm not sure how you define "work"--Do you mean you _want_ your code to
display the other resources too, or that you want to make sure that the
above code _won't_ display the other resources by mistake?

In either case, here are the things to consider:  As written, the above
code will display the first PICT resource it finds whose ID number is
128.  It will first look in the "Current resource file" (which is
normally your app's resource fork), and if it doesn't find a PICT #128
there it will look in other open resource files (such as the System
resource file, which is always open).

Normally you will assign a different resource ID number to each of your
PICT resources (in theory, it's _possible_ to have two PICT resources
with the same ID in the same file, but it's virtually never done).  In
that case, all you need to do is: (1) make sure you pass the desired ID
number into GETPICTURE, and (2) make sure that your current resource
file is the file that contains the PICT resources.  Assuming that your
PICT resources are all in your app's resource fork, step (2) requires no
other action on your part.

- Rick