Jump to content

Need to move away from hotkeyset and blockinputex if possible


Recommended Posts

I have been working on a program for several months and think it is about time to start over. I have a commercial package that runs in the forground and this program I am writing runs in the background. My program is designed to severy limit the keystrokes the user can make in the commercial package and disables the use of the mouse. It also uses HotKeySet for the F1 and F2 keys and they act as macros.I am generally not please with the way things are working.

The HotKeySet is neat but has some issues. It stops execution of the script no matter where it is and jumps to the HotKeySet. That can cause problems. Then if the user just holds down the HotKey you get a wicked "recursion" thing going.

I use BlockInputEx to block all but 6 keys and disable the mouse. The problem I have found with it is that when you block the mouse you also block the MouseClick() and unforutnately this commercial package does not respond to ControlClicks very well. On occasion I am forced to use MouseClick. Lo and behold the users have found that in the brief moment that I enable the mouse, do the mouse click and disable the mouse that they have a working mouse.

I need better and more complete control of both the keyboard and mouse. Something like:

While 1

CheckForKeypress

If KepPressed and Key = F1 then ....

CheckForMouseclick and ignore

Wend

I know that is pretty generic but more or less what I need. I only want to check for a keypress once per loop and need to completely disable the mouse yet still have the MouseClick and ControlClick work. Any ideas?

Link to comment
Share on other sites

So the user is allowed to interact with the commercial package but at the same time you want to limit the allowed keys plus do MouseClicks and ControlClicks?

Why do you want to do that? Why shouldn't the user be in full control what he enters?

My UDFs and Tutorials:

Spoiler

UDFs:
Active Directory (NEW 2022-02-19 - Version 1.6.1.0) - Download - General Help & Support - Example Scripts - Wiki
ExcelChart (2017-07-21 - Version 0.4.0.1) - Download - General Help & Support - Example Scripts
OutlookEX (2021-11-16 - Version 1.7.0.0) - Download - General Help & Support - Example Scripts - Wiki
OutlookEX_GUI (2021-04-13 - Version 1.4.0.0) - Download
Outlook Tools (2019-07-22 - Version 0.6.0.0) - Download - General Help & Support - Wiki
PowerPoint (2021-08-31 - Version 1.5.0.0) - Download - General Help & Support - Example Scripts - Wiki
Task Scheduler (NEW 2022-07-28 - Version 1.6.0.1) - Download - General Help & Support - Wiki

Standard UDFs:
Excel - Example Scripts - Wiki
Word - Wiki

Tutorials:
ADO - Wiki
WebDriver - Wiki

 

Link to comment
Share on other sites

But if it's a commercial package (ERP like SAP or whatever) it should be possible to revoke permission to "launch every nuclear weapon".

What do you do if a user is smart enougth to kill your background script?

My UDFs and Tutorials:

Spoiler

UDFs:
Active Directory (NEW 2022-02-19 - Version 1.6.1.0) - Download - General Help & Support - Example Scripts - Wiki
ExcelChart (2017-07-21 - Version 0.4.0.1) - Download - General Help & Support - Example Scripts
OutlookEX (2021-11-16 - Version 1.7.0.0) - Download - General Help & Support - Example Scripts - Wiki
OutlookEX_GUI (2021-04-13 - Version 1.4.0.0) - Download
Outlook Tools (2019-07-22 - Version 0.6.0.0) - Download - General Help & Support - Wiki
PowerPoint (2021-08-31 - Version 1.5.0.0) - Download - General Help & Support - Example Scripts - Wiki
Task Scheduler (NEW 2022-07-28 - Version 1.6.0.1) - Download - General Help & Support - Wiki

Standard UDFs:
Excel - Example Scripts - Wiki
Word - Wiki

Tutorials:
ADO - Wiki
WebDriver - Wiki

 

Link to comment
Share on other sites

Killing the background script is yet another step in making the script "bulletproof"

I played a little with _IsPressed() and it does tell you if the key you were looking for was pressed but it does not block the input. It allows anything pressed to pass through to whatever is running. Not good.......

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...