"Mike" <mi**@nospamher e.net> wrote in message
news:00******** *************** *****@phx.gbl.. .
Excellent question. I'm building a solution to a years-
old company procedure, which is "set-in-stone" (for lack
of better terminology). This procedure is so ingrained,
and the Access application is so widely distributed, that
to change any part of the Access portion of it is a big
no-no. I agree, changing the Access Report would be a
simple solution. But since that is not an option, I have
to use C#...which is really not so bad, because I am
learning by leaps and bounds about C# and what it is
capable of.
Sorry for continuing to pursue this thread, even though the decision itself
may not be within your control, however I can't help but question the
fundamental choice to dismiss the most obvious solution for some half baked
approach.
While learning C# may benefit you, it doesn't directly benefit the users at
all.
Why is distributing a new version of the report is more difficult to
distribute than your C# solution? The new report need not replace the
current one, so I don't see how having an additional report listed will
cause any problems whatsoever. The entire process of adding the report to
their existing Access application can be completely automated with a
installation tool. You don't need to redistribute the entire Access
database and all that it contains: no tables, forms, or other structures
besides the report itself need to be sent or modified. The end result will
be just one more Access report listed with a name of your choosing that can
reflect why and how it exists. I can't see how that will be much of a
problem..
If the process is so ingrained, you're still modifying it one way or
another, regardless of the programming tool used or how it's distributed.
Somehow they're going to need to run your C# app, and I'll bet it will be
more difficult to learn and use than choosing a different report in Access.
If you've read this far into my reply, I'll make it worth your while to bear
with me on this point.
The direct solution to your problem is to not rely on Sendkeys or the focus
state of that window. The only reliable means is to get the windows handle
(hWnd) of that window and the controls used so that you can send windows
messages to them directly using the Win32 API. There are tools to inspect
the window properties of applications at runtime, and these tools use
published APIs to track down any window created using the standard API.
Therefore, this technique is complex, but well-known and understood by those
of us who know the Win32 API. To learn how to use this approach is a rather
advanced for a novice, because there's no shortcuts to learning the Win32
API. There are tools that can help such as Spy++ and pview (VS6), but you
still need to understand what's going on at the API level to make much use
of them.
Daniel Appleman's Spyworks is great product that has rolled up many of these
APIs into components. While this product was originally designed for VB
programmers, it has been updated for dotnet.
His site and his books contain some of the best available info for Windows
programming on the net.
http://www.desaware.com 
