By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
449,346 Members | 1,282 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 449,346 IT Pros & Developers. It's quick & easy.

baffling C# question

P: n/a
I have posted this before, but no one responds, so here
it goes again. I think my question is intimidating people
and I have no idea why?!? This is not a new concept. You
can do this with other programming languages, so why is
C# so different? Again, here is my baffling C# question.

I have C# code that opens an application, but right after
it opens I am confronted by prompts for information
(i.e. "Please enter your id"). I would like to handle
these prompts programmatically with C#. Is there some C#
code that passes a value to a prompt and then forces
the "ok" button?
Nov 15 '05 #1
Share this Question
Share on Google+
12 Replies


P: n/a
It can be done, but i wouldn't use C# for it.
From waht you are saying, you want to get the windowhandle of the dialog,
fill in text into a set of textboxes for hte prompt, and hit ok.
I know of no .NET classes that can do that nativly. You will have to go down
to the platform invoke level and call win32 functions directly.
Due to the amount of p\invoke, i'd advise using MC++ and asking in a Win32
group how exactly to do everything you need to. Such things are really
beyond the topic here. If you ahve done it before in C++ or delphi or VB6,
you should have a pretty good idea of what API's you want to call.
But by using MC++, you should be able to create an assembly that just
handles that lowerlevel stuff and can be called from C# where the bulk of
your work can still be done.
"Mike" <mi**@nospamhere.net> wrote in message
news:0c****************************@phx.gbl...
I have posted this before, but no one responds, so here
it goes again. I think my question is intimidating people
and I have no idea why?!? This is not a new concept. You
can do this with other programming languages, so why is
C# so different? Again, here is my baffling C# question.

I have C# code that opens an application, but right after
it opens I am confronted by prompts for information
(i.e. "Please enter your id"). I would like to handle
these prompts programmatically with C#. Is there some C#
code that passes a value to a prompt and then forces
the "ok" button?

Nov 15 '05 #2

P: n/a
> I have posted this before, but no one responds, so here
it goes again. I think my question is intimidating people
and I have no idea why?!? This is not a new concept. You
can do this with other programming languages, so why is
C# so different?
Would you be so kind and give us an example?
Again, here is my baffling C# question.
I have C# code that opens an application, but right after
it opens I am confronted by prompts for information
(i.e. "Please enter your id").
I would like to handle
these prompts programmatically with C#. Is there some C#
code that passes a value to a prompt and then forces
the "ok" button?

Nov 15 '05 #3

P: n/a
You should be able to send keystrokes uisng the
System.Windows.Forms.SendKeys class, it ought to be capable of doing most of
what you need.
--
Regards

John Timney (Microsoft ASP.NET MVP)
----------------------------------------------
<shameless_author_plug>
Professional .NET for Java Developers with C#
ISBN:1-861007-91-4
Professional Windows Forms
ISBN: 1861005547
Professional JSP 2nd Edition
ISBN: 1861004958
Professional JSP
ISBN: 1861003625
Beginning JSP Web Development
ISBN: 1861002092
</shameless_author_plug>
----------------------------------------------

"Mike" <mi**@nospamhere.net> wrote in message
news:0c****************************@phx.gbl...
I have posted this before, but no one responds, so here
it goes again. I think my question is intimidating people
and I have no idea why?!? This is not a new concept. You
can do this with other programming languages, so why is
C# so different? Again, here is my baffling C# question.

I have C# code that opens an application, but right after
it opens I am confronted by prompts for information
(i.e. "Please enter your id"). I would like to handle
these prompts programmatically with C#. Is there some C#
code that passes a value to a prompt and then forces
the "ok" button?

Nov 15 '05 #4

P: n/a
John,

I tried SendKeys and I was impressed. It's a bit too
unpredictable for me, but I think it's a step in the
right direction. At least you understand where I want to
take this thing.
-----Original Message-----
You should be able to send keystrokes uisng the
System.Windows.Forms.SendKeys class, it ought to be capable of doing most ofwhat you need.
--
Regards

John Timney (Microsoft ASP.NET MVP)
----------------------------------------------
<shameless_author_plug>
Professional .NET for Java Developers with C#
ISBN:1-861007-91-4
Professional Windows Forms
ISBN: 1861005547
Professional JSP 2nd Edition
ISBN: 1861004958
Professional JSP
ISBN: 1861003625
Beginning JSP Web Development
ISBN: 1861002092
</shameless_author_plug>
----------------------------------------------

"Mike" <mi**@nospamhere.net> wrote in message
news:0c****************************@phx.gbl...
I have posted this before, but no one responds, so here
it goes again. I think my question is intimidating people and I have no idea why?!? This is not a new concept. You can do this with other programming languages, so why is
C# so different? Again, here is my baffling C# question.
I have C# code that opens an application, but right after it opens I am confronted by prompts for information
(i.e. "Please enter your id"). I would like to handle
these prompts programmatically with C#. Is there some C# code that passes a value to a prompt and then forces
the "ok" button?

.

Nov 15 '05 #5

P: n/a

"Mike" <mi**@nospamhere.net> wrote in message
news:0c****************************@phx.gbl...
I have posted this before, but no one responds, so here
it goes again. I think my question is intimidating people
and I have no idea why?!? This is not a new concept. You
can do this with other programming languages, so why is
C# so different? Again, here is my baffling C# question.

I have C# code that opens an application, but right after
it opens I am confronted by prompts for information
(i.e. "Please enter your id"). I would like to handle
these prompts programmatically with C#. Is there some C#
code that passes a value to a prompt and then forces
the "ok" button?


I have one simple question: Why can't you copy or modify the Access
report?

Perhaps there is a good reason, but it mystifies me. You seem to be making
a mountain of a project out of a molehill of a task.

Modifying the report is the obvious, simple, straightforward, virtually
trivial task. Parameter queries can usually be changed in minutes to
programatic control for providing these values. Using SendKeys, hooks,
window messages, etc. is the most roundabout way of tackling this problem.

I may be able to help you with either approach, but I don't want to waste
the effort of providing the right solution to the wrong problem.
Nov 15 '05 #6

P: n/a
Convince us you're not building some bu)(*&# hacker tool or password
spammer. I've seen several of your posts on this and you've answered
the questions as to why you want to do this.

Sorry to be so suspicious, but lately all my problems in coding have
been 100% because of hackers and the bullshit they cause in added
layers of extra crap security and such.

"Mike" <mi**@nospamhere.net> wrote in message news:<0c****************************@phx.gbl>...
I have posted this before, but no one responds, so here
it goes again. I think my question is intimidating people
and I have no idea why?!? This is not a new concept. You
can do this with other programming languages, so why is
C# so different? Again, here is my baffling C# question.

I have C# code that opens an application, but right after
it opens I am confronted by prompts for information
(i.e. "Please enter your id"). I would like to handle
these prompts programmatically with C#. Is there some C#
code that passes a value to a prompt and then forces
the "ok" button?

Nov 15 '05 #7

P: n/a
I know VB6 had a nifty SendKeys("mysecretpassword{enter}") function. This
function is available in C# by doing this:

System.Windows.Forms.SendKeys.Send("mysecretpasswo rd{enter}");

Chris LaJoie

"Mike" <mi**@nospamhere.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.
-----Original Message-----

"Mike" <mi**@nospamhere.net> wrote in message
news:0c****************************@phx.gbl...
I have posted this before, but no one responds, so here
it goes again. I think my question is intimidating people and I have no idea why?!? This is not a new concept. You can do this with other programming languages, so why is
C# so different? Again, here is my baffling C# question.
I have C# code that opens an application, but right after it opens I am confronted by prompts for information
(i.e. "Please enter your id"). I would like to handle
these prompts programmatically with C#. Is there some C# code that passes a value to a prompt and then forces
the "ok" button?


I have one simple question: Why can't you copy or

modify the Access
report?

Perhaps there is a good reason, but it mystifies me.

You seem to be making
a mountain of a project out of a molehill of a task.

Modifying the report is the obvious, simple,

straightforward, virtually
trivial task. Parameter queries can usually be changed

in minutes to
programatic control for providing these values. Using

SendKeys, hooks,
window messages, etc. is the most roundabout way of

tackling this problem.

I may be able to help you with either approach, but I

don't want to waste
the effort of providing the right solution to the wrong

problem.


.

Nov 15 '05 #8

P: n/a
I have never heard of this problem before. Could you possibly try repeating
the SendKeys until it does work? I am aware of a couple APIs that might be
of some use. I'll do some research for you.

Chris LaJoie

"Mike" <mi**@nospamhere.net> wrote in message
news:03****************************@phx.gbl...
Chris,

I like your technique! It's almost exactly what I need! I
say "almost" because sendkeys is still very unreliable.
Sometimes it works, and sometimes it doesn't. When it
works, it works perfectly. When it doesn't work, the text
that is sent sometimes truncates. Sometimes it doesn't go
through at all.
-----Original Message-----
I know VB6 had a nifty SendKeys("mysecretpassword

{enter}") function. This
function is available in C# by doing this:

System.Windows.Forms.SendKeys.Send("mysecretpassw ord

{enter}");

Chris LaJoie

"Mike" <mi**@nospamhere.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.

>-----Original Message-----
>
>"Mike" <mi**@nospamhere.net> wrote in message
>news:0c****************************@phx.gbl...
>> I have posted this before, but no one responds, so here >> it goes again. I think my question is intimidating
people
>> and I have no idea why?!? This is not a new concept.
You
>> can do this with other programming languages, so why is >> C# so different? Again, here is my baffling C#
question.
>>
>> I have C# code that opens an application, but right
after
>> it opens I am confronted by prompts for information
>> (i.e. "Please enter your id"). I would like to handle >> these prompts programmatically with C#. Is there some C#
>> code that passes a value to a prompt and then forces
>> the "ok" button?
>
>I have one simple question: Why can't you copy or
modify the Access
>report?
>
>Perhaps there is a good reason, but it mystifies me.
You seem to be making
>a mountain of a project out of a molehill of a task.
>
>Modifying the report is the obvious, simple,
straightforward, virtually
>trivial task. Parameter queries can usually be changed in minutes to
>programatic control for providing these values. Using
SendKeys, hooks,
>window messages, etc. is the most roundabout way of
tackling this problem.
>
>I may be able to help you with either approach, but I
don't want to waste
>the effort of providing the right solution to the wrong problem.
>
>
>.
>

.

Nov 15 '05 #9

P: n/a
In looking into this I found out that most problems relating to SendKeys had
to do with the wrong window being in focus. If you ensure that your access
window (or whatever you're using) is the selected window, you should solve
all your problems. I found an alternative, the SendKeyboardState API in
user32.dll, which in my opinion looks like way more trouble than it's worth.
But if you want to research it, go for it! :)
good luck,

Chris LaJoie
Nov 15 '05 #10

P: n/a

"Mike" <mi**@nospamhere.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
Nov 15 '05 #11

P: n/a
Hey, I only said that because I've seen you cross post this alot and
never answer any questions back at you, that's all.

"Mike" <mi**@nospamhere.net> wrote in message news:<01****************************@phx.gbl>...
Convince you? I think not. I have a legitimate
programming question regarding Access reports which I
have already explained in detail through multiple posts.
If you want to live in fear of my "oh-so-scary" Access
application, then that's your choice.

Nov 15 '05 #12

P: n/a
Mike still hasn't solved this yet??

I really think you are barking up the wrong tree.. Access (even with new
fancy bells/whistles) - is a nasty, nasty legacy app.. you are better of
using legacy tools.. or migrating off Access.. To try to mix the two will
probably end up being a mess. Whip up a VB6 app with DAO and that should get
you fixed up..

"Chris Hornberger" <ch***@chornbe.com> wrote in message
news:53*************************@posting.google.co m...
Hey, I only said that because I've seen you cross post this alot and
never answer any questions back at you, that's all.

"Mike" <mi**@nospamhere.net> wrote in message

news:<01****************************@phx.gbl>...
Convince you? I think not. I have a legitimate
programming question regarding Access reports which I
have already explained in detail through multiple posts.
If you want to live in fear of my "oh-so-scary" Access
application, then that's your choice.

Nov 15 '05 #13

This discussion thread is closed

Replies have been disabled for this discussion.