Hi Christof,
Here is some closure on the amazing sometimes blank form. I finally got it to work with a kludge. First a little background. The form in question is sometimes called from another form and that's when it sometimes comes up blank. After the offending form is released, another form may or not be instantiated before returning focus to the calling form.

I didn’t mention any of this detail before, working from the assumption that figuring out the goofy state of the form and what form setting, API call, event to trigger, etc. to fix the problem was what was important.

The players:
Form A, an activity form that describes an activity at a seminar. An activity can be a choir, workshop, meeting, etc. An activity occurs in a location, has a start time, duration and participants among other attributes.

Form B, a person lookup form. A person is looked up a member database so he/she can be associated with an activity. This is the form that sometimes shows up blank

Form C, a form that determines the role of the participant, e.g., speaker, door host, a/v tech, etc. This turns out to be the culprit.

The sequence of events:
Form A instantiates form B in order to get a participant. After a participant is selected, form B is released and form C is instantiated to determine a participant role. Then form C is released returning focus to form A. An activity will often have multiple participants so once again Form B is instantiated.

It turns out that it depends on how form C was released last time whether or not Form B will be blank this time!

All this form instantiation and releasing is done through my framework, the same as all the other 200+ forms in the app. Many of our forms call other lookup forms that may in turn call other forms. This is the only instance where a form sometimes shows up with invisible controls.

Things to note:
1. The forms seem to be really releasing, i.e., _screen.forms increments and decrements as it’s supposed to. When a form is released the _screen.formcount goes down and the name disappears from the _screen.forms collection.

2. The problem form has a pageframe with nested containers and controls, but even removing the entire pageframe makes no difference in the behavior

3. I beefed up framework garbage collection to make sure that all form related bindevents are unbound, object refs are released, all containers are drilled down into, etc. Although that’s always a good idea, it made no difference here.

4. The framework form instantiation and release is quite simple and works without problem for the rest of the app.

5. Not one of the many good suggestions had any positive effect at all.

6. I can call several forms from form A and they always work fine, even when form B doesn’t!

I have to assume that something wasn’t really releasing or something else behind the scenes was set to some state that was causing the problem in this one specific case. By overriding standard framework behavior for form C, the problem goes away. I’m declaring victory and moving on.

Thanks for all your help and suggestions.

Gary





>Hi Gary,
>
>right now my current hypothesis of what's going on is: When VFP paints the controls something causes an exception jumping back to some outermost exception handler. Basically, VFP would stop painting. To verify this hypothesis, you could let your application run in the Visual Studio debugger and before doing so enable all exceptions on the Debug > Exceptions dialog checking the "thrown" column.
>
>It might be a division by zero exception. In this case, you could try to add the following code to the Init, Activate and Paint event (and maybe some more places):
>

>Declare _fpreset in msvcr71.dll
>_fpreset()
>