Dark gray, blank screen when app opens via vb script.

[Rick Wannall]

I use the following script to open an Access app, to avoid the security
warnings:

dim o
set o=createobject ("Access.Applic ation")
o.automationsec urity=1 'set macro security LOW.
o.opencurrentda tabase "\\spacehab.com \files\SHApps\E PRD\Live\eprd.4 .50a.mde"
o.usercontrol=t rue
set o=nothing

(We tried certificates but neither I nor our IT people could get it to work
properly, so we fell back on this. ICYWW)

The "4.50" reflects the version of the app in the production directory.

Been using this for about a year. No problem. App opens fine every time.

Until today.

I decided that I wanted form A to open after form B instead of before.
Nothing else. I cut the openform line, moved up about 10 lines, pasted it
back in.

Runing locally, as the mdb, no problem. The effect is perfect. I "compile"
to mde, copy to the file server, and run the mde from there, manually, not
through the script. Runs fine. Identical to how it ran on my workstation
as an MDB. Now I change my vb script to use the new file name
(eprd.4.50b.mde for this example), and things go completely to hell. Access
opens. In my taskbar I can see the name of all the forms that I expect to
be open, but none of them are visible.

There are no vertical or horizontal scroll bars. The forms themselgves do
nothing remarkable. One is a menu form with a graphic and a listbox. One
is review of items to do, with a couple of listboxes and a couple of
commandbuttons.

To recap: The existing vb script opens the previous version of the app just
fine. If I copy that script file and change it to open the new version of
the app, everything goes to hell. If I open the new version of the app
manually, everything is fine.

I've restarted, shut down and power back up, repaired my Office
installation, and now I'm trolling for ideas.

[Tom van Stiphout]

On Thu, 01 Jun 2006 21:48:43 GMT, "Rick Wannall"
<wa*****@notado main.de> wrote:

Very unusual.
Put a "Stop" instruction at the top of your code, and then step
through it in the debugger. I'm expecting an "aha Erlebniss".

-Tom.

I use the following script to open an Access app, to avoid the security
warnings:

dim o
set o=createobject ("Access.Applic ation")
o.automationse curity=1 'set macro security LOW.
o.opencurrentd atabase "\\spacehab.com \files\SHApps\E PRD\Live\eprd.4 .50a.mde"
o.usercontrol= true
set o=nothing

(We tried certificates but neither I nor our IT people could get it to work
properly, so we fell back on this. ICYWW)

The "4.50" reflects the version of the app in the production directory.

Been using this for about a year. No problem. App opens fine every time.

Until today.

I decided that I wanted form A to open after form B instead of before.
Nothing else. I cut the openform line, moved up about 10 lines, pasted it
back in.

Runing locally, as the mdb, no problem. The effect is perfect. I "compile"
to mde, copy to the file server, and run the mde from there, manually, not
through the script. Runs fine. Identical to how it ran on my workstation
as an MDB. Now I change my vb script to use the new file name
(eprd.4.50b.md e for this example), and things go completely to hell. Access
opens. In my taskbar I can see the name of all the forms that I expect to
be open, but none of them are visible.

There are no vertical or horizontal scroll bars. The forms themselgves do
nothing remarkable. One is a menu form with a graphic and a listbox. One
is review of items to do, with a couple of listboxes and a couple of
commandbuttons .

To recap: The existing vb script opens the previous version of the app just
fine. If I copy that script file and change it to open the new version of
the app, everything goes to hell. If I open the new version of the app
manually, everything is fine.

I've restarted, shut down and power back up, repaired my Office
installation , and now I'm trolling for ideas.

[Rick Wannall]

Do I ever hope you're right!

[salad]

Rick Wannall wrote:

Do I ever hope you're right!

It sounds like you are pointing to a record that doesn't exist. Ex:
Docmd.Openform "x",,,"ID = 1"
and there is no id#1.

[Rick Wannall]

There is no attempt to point at any record. I rarely use bound forms
anyway, but that's a side issue.

There should be 3 forms visible, just sitting there, ready for the user to
do something on one of them. (One of them actually closes itself on a timer
after 20 seconds.)

Sadly, the problem does not occur when starting the MDB from the script, so
following the code throught the opening sequence is pointless, since the
problem does not appear.

It seems so odd that the form names show up on my task bar, exactly as they
should. They seem to be open. They're just not visible, and there are no
scroll bars to get to them, and there's not code setting them invisible.
And if there were, there are no menus available period, so I couldn't unhide
a form even if that were the problem.

This one I don't get.

[Rick Wannall]

OK. Got the answer, sort of. I know the code it's related to, and I know
that it has something to do with timing, and that's probably as far as I'll
chase it.

It all started when I moved this line of code:

Call MaximizeApplica tionIfNotAlread y

That line of code was previously called only in two places, activated when
the user's mouse moved over an area on a form. I was so convinced that
moving and positioning forms (which I also added) and maximizing a window
were such vanilla, absolutely uninteresting actions that I sort of
overlooked them in my mental checklist. Looks like I'm learning this
lesson, yet again: Never, ever overlook anything.

I inserted that line additionally into my opening stream of code. That's
what caused the problem. My startup form does some login validation and
link checking, then it opens 3 forms. I was thinking that I might go ahead
and maximize after opening the forms. Wrong. I could not find any place in
that stream of activity that I could leave that line of code and wind up
with forms visible when the application opened.

I yield to the intransigence of the immutable unknown, so I removed the line
and copied it to the MouseMove event of the detail section of the 4 forms
that could possibly wind up open, depending on user preference settings.

Works like a charm.

For those who care, the functions invoked by the offending line are shown
below.

I guess that in programming, as in comedy, timing is everything.

=============== =============== =============== =========
Public Function MaximizeApplica tionIfNotAlread y()

If IsAccessMaximiz ed = False Then
Call AccessMaximize
End If

End Function

Function IsAccessMaximiz ed() As Boolean
If apiIsZoomed(Get AccesshWnd()) = 0 Then
IsAccessMaximiz ed = False
Else
IsAccessMaximiz ed = True
End If
End Function

Function AccessMaximize( )
AccessMaximize = apiShowWindow(G etAccesshWnd(), SW_MAXIMIZE)
End Function

Declare Function apiIsZoomed Lib "user32" Alias "IsZoomed" (ByVal Hwnd As
Long) As Long
Declare Function apiShowWindow Lib "user32" Alias "ShowWindow " (ByVal Hwnd
As Long, ByVal nCmdShow As Long) As Long