Get Keystrokes at Startup? 5

[Terabithia]

I have a VB6 app that I have several command line arguments that the user can use under certain situations. I have had trouble communicating to users how to do this, so I want to change the app to recognize if particular keys are pressed when the app starts, and execute depending on what keys are pressed. I have a splash form that might be of help.

So far anything I have tried catches the keystrokes after the form load event is finished, which is too late. Can keystrokes be captured at the module level? Any thoughts?

 

[strongm]

Suggestion: you probably don't want to start your application with a Form, then ...

 

[strongm]

... and might like to have a look at the GetKeyState API (easier technique than hooking all the keyboard input)

 

[Andrzejek]

How about giving your users a Form (menu) after the Splash screen and before any other forms where they can choose what they want instead of key strokes when starting your app?

This way users do not have to remember what keys to press when app starts, and it will be easy to communicate to them what option to choose after the app starts because the options will be in front of them.

So you will start your app NOT at the splash screen, you would do it after that, which your users do not care where the actual start will be.

Just my suggestion.


Have fun.

---- Andy

 

[SBerthold]

That may not be pratical (considering the OP requirements) for users who know how to set up a link with parameters, or ones who do not what to use the parameters at all.
It may only be pratical to do something like that when the user does something like holding SHIFT when the program starts, popping up the start-options form, which puts us back at using the GetKeyState API.

 

[CaptainD]

Would it be practical to have a database for each user, get the logged in user name and apply the parameters setup for each user?

 

[SBerthold]

I had thought about suggesting an INI file, but reading the OP again I understood the users would want to start the app only under certain situations, at certain times, using possibly different parameters each time.

I guess Terabithia will need to first respond and clarify for further help.

 

[vbSun]

Will it be ok to set up different shortcuts in User's desktop for each commandline and put appropriate labels?

------------------------------------------
The faulty interface lies between the chair and the keyboard.

 

[Terabithia]

My thanks to all of you for your interest, help and suggestions. I went with Strongm's suggestion and used the GetKeyState API, it worked great. My apps use numerous API calls, somehow I got stuck thinking I must get keyboard input from a form. It is hard to get anything done when you are hopping around on one leg and kicking yourself with the other.

For clarification, many of the folks that use my apps are business managers, and many of them could benefit from a bit more time invested in learning how to use a computer. I have spent far too much time trying to tell someone how to create a shortcut and add a command line argument. The need for these command line arguments are rare, in most cases they are never needed, so it is not a good idea to advertise them unless needed. Now if one of these special situations develops I can tell the user to hold some key combination and start the app. If this is a problem I give up.

I do use INI files, again due to the rare need I did not want to use them for this purpose. Sberthold's interpretation of what is going on was right on the mark.

My apps start from Sub_Main, not a form. I mentioned the splash form as it is quickly displayed and I thought I might be able to trap the needed keys there. Part of the problem with that is the form is displayed for several seconds while a great deal of initialization work is done, and the app will have quickly moved past where the keys needed to to be read. I think I could have worked around the problems with using the form, however using the GetKeyState API from the module works great and is very clean.

Thanks again!