I don't know what from Access 97 has changed in the Access 2000 release. So I'll just ask other questions, directed at things to check out.
Someone earlier asked if the pop-up forms opens okay on its own? I will restate the question: Do you see the same "transparency behavior" if you just open the pop-up form from the database window, with no other forms (or queries or reports or...) open? Do you see the same "transparency behavior" if you do the same, but also make sure as few as possible other programs and processes are running?
Does Access 2000 actually give you a "Transparency" property (whatever this new property might be called, or wherever this new effect might be contained) for forms or form section backgrounds or such like things as might of concern here? I know that in Access 97, I can set *some* colors to a Transparent value, but I also know I can't do that to a form section's background. I can't *set* a form to see through it to what's underneath the form itself. Has Microsoft actually given us this ability explicitly in Access 2000 somehow? The answer may be "no", but the question seems worth asking to this someone who doesn't know the answer yet.
As Neilll says, it could also be a "repaint" problem, an instance of the computer not getting around to repainting the form. This might be due to a number of things.
Repaint thought #1):
In Access 97, there are two Echo methods, which explicitly turn off/on form repainting until explicitly turned on/off again. See if something like that is happening in your code. Turning Echo off is suggested as a method to increase speed sometimes if the user does not need to see the screen change while processing is going on. But if code stops before Echo is turned back on, the user can be left looking at what seems to be a locked-up instance of Access (other apps are not affected). And other windows that pop up on top of Access seem to leave "holes" or "tracks" of emptimess [sic.] in the Access window, if they are closed or moved around. If Echo were turned off, and your pop-up form were popped up before Echo was turned back on, I *actually* wouldn't expect to see it at all. But strange things happen on other people's ;-) computers, I'm told, and I've not programmed with Access 2000 yet. Its behavior might be a bit different. So this seems to be an unlikely possibility, but one worth ruling out.
Repaint thought #2):
Your computer might be hurting for enough free memory at the time that your pop-up form pops up -- enough free memory to finish repainting the screen and the new form. (Your computer/Access may even warn you with a "Not enough memory" dialog then or soon after; or it may not). This is one good reason to answer the first question: Does the pop-up exhibit the "transparency behavior" when you have as little else as possible running? Try a clean boot on your computer, closing anything other than Access that you can get away with closing, then opening your Access database (holding down the shift key while opening it, so that any automacros don't even run). Then run your pop-up dialog itself from the database window, and see how it behaves. (The clean boot is your attempt to make sure that as little as possible even gets the chance to use memory and forget to release it or release it properly.)
(repaint #2, cont'd) If your pop-up consistently runs without the "transparency behavior" in this kind of test, or even on a machince with a lot more memory, but not when other things are running or have been running -- if so, then this may be a decent indication that memory usage problems could be your culprit.
(repaint #2, cont'd) Is the form that calls the pop-up form a large form? Meaning "large in the sense that would use up memory", not "large in the sense of width by height"
. Either a large number of controls or large amounts of data displayed on the form would use up large amounts of memory.
(repaint #2, cont'd) A long-worded "For Instance": A form in one of the databases I developed earlier this year contains an OLE object field, and users drag into it Word and Excel documents which contain sometimes-very-large pictures within them. (In fact, the point is to store and display the pictures, and I haven't figured out how to display the pictures directly -- on every PC -- in an OLE field yet. But Access has no problem displaying Word and Excel docs on a PC with Word and Excel installed, so the pictures are in the docs, and the docs are displayed.) The documents are embedded, not linked, so the full contents of the file are stored in the datbase field and displayed on the form. The OLE object field does display its contents *if it can*, *not* an icon representing the contents. I was really, really, really (emphatic enough for ya'?) just buggering confused when my supervisor and principal-user-of-the-form called me in and showed me how the form sometimes flaked, just a short while after I made it available to him. Buttons background colors would go white instead of gray, leaving the foreground color intact. Fonts on controls would change. The embedded picture, data in other fields, other stuff would disappear from view. And all of this behavior was inconsistent -- and inconsistent (and seemingly inconsistent) is a whole lot tougher to track down than consistent! Moving off the record where the behavior first occurred at a given instance, then moving back, might show the form and record intact again (or might show it messed up again, in the same/similar-enough or a different way) -- so data wasn't affected, just the view. Nothing in my code was causing it, Scout's Honor. "It's not my fault, Boss! But more important, I can't figure it out just yet. I'm still trying, though." I noted that the behavior only started occurring after certain records were displayed -- at last a consistency! Testing confirmed this. Avoid those records, avoid the problem. It turns out that, after development and testing of the form with pictures provided by the department responsible for providing the pictures for actual use, said department produced more pictures for actual use -- as of course, they were supposed to. But some of the pictures they were now providing were far larger than any of the pictures provided for my use during testing, even though those original pictures were also for actual use. These pictures were far larger in terms of the amount of memory required to diplay them, and the PCs were having memory problems after displaying large pictures. Windows didn't have enough memory left then to properly handle display updates, and colors, fonts, and more suffered. In some cases, we saw the "Not enough memory" error, and in others we didn't. That is what began to put me on this track, though. (And be sure that I checked my code to be sure that I was explixitly releasing any memory I was using.) Testing did include displaying the same records on the PC with the most memory. And that was enough to allow display of some of the problem records without incident, but not some of the largest. Our solution in the end had to be this: The picture-producing department has to produce pictures that take up less memory so that the pictures can all be displayed on all of our computers: pictures with less detail, pictures with less (no) extraneous white space around the edges, pictures with less information contained in them, and in some cases, physically smaller pictures. Now the form in question doesn't run out of memory, and the requisite users can do their work. (...Of course, if I ever find the way to display GIFs or other picture formats directly from a database field, then I can cut down on the memory requirements even further by eliminating the need to have Word or Excel running to display the documents currently stored in the fields. Apparently, I just haven't found an OLE server for picture formats, not even for .WMF files (Windows Metafiles)! This isn't a company priority now, though, since the current system is working.)
Good Luck, Readers!
-- C Vigil =)
(Before becoming a member, I also signed on several posts as
"JustPassingThru" and "QuickieBoy" -- as in "Giving Quick Answers"
![[afro2]](/data/assets/smilies/afro2.gif "[afro2] [afro2]")
instead of hanging out in this Zen state ![[yinyang]](/data/assets/smilies/yinyang.gif "[yinyang] [yinyang]")
? The thought comes as a way of forcing a repaint in a way other than using the .Repaint method. Maybe in the Load or Open event, maybe in a timer event to keep it happening repeatedly, maybe on a button or form click event ... 
