Identifying whether Shift is pressed during opening a Runtime

[JohnPapa]

I need to run a specific code on some occasions. I thought if I could identify whether the Shift key is pressed when the .accde is run, that would solve the problem.

Can we identify whether Shift is pressed during opening a Runtime

 

[Gasman]

ChatGPT states

You can't directly detect Shift key usage during startup, but you can infer it by checking if startup actions like the AutoExec macro ran. Use TempVars, global variables, or custom logs to help with this.

 

[JohnPapa]

Thanks for your reply. I do not understand ChatGPT's position.

 

[Gasman]

If you ask it, it will explain it's reasoning.
Basically you set a TempVar in an AutoExec. If that Tempvar is not set, then the Shift was used to open the DB.

Bit of lateral thinking.
You can prevent the bypass, you know that do you not?

 

[JohnPapa]

If you ask it, it will explain it's reasoning.
Basically you set a TempVar in an AutoExec. If that Tempvar is not set, then the Shift was used to open the DB.

Bit of lateral thinking.
You can prevent the bypass, you know that do you not?

Thanks. Yes, I use the ByPass. I do not use macros at all.

With the ByPass I merely set it to True or False.

 

[Gasman]

Well you will need to use the AutoExcec if you want to do what you want to do.

 

[JohnPapa]

With the ByPass the following is set to True or False

db.Properties!AllowBypassKey

Can't see how this can be used.

 

[JohnPapa]

Well you will need to use the AutoExcec if you want to do what you want to do.

Maybe I can do an exception and use the AutoExec, since the specific .accde is not the main program, but a ".accde", which calls the main .accde.

If I set a global variable to a value in AutoExec then that means that the Shift was NOT pressed, when I called the .accde?

 

[JohnPapa]

I tried it and it works fine. I added a simple msgbox statement.

The real reason for the Shift functionality is to be able to select when to Compact and Repair.

 

[The_Doc_Man]

You should be very careful about performing a C&R programmatically. There is a technical difference between automatic and manual C&R. When done automatically, code is running. When done manually, it is more likely that code is NOT running. The action of a C&R is summarized thus:

1. Make an empty database.
2. Step through the collections inherent in ANY DB and copy them, one collection at a time, including all content but not copying deleted items.
2.a - For tables, this includes copying the records, field definitions, and indexes (This is the bigger part of "Compact")
2.b - For all items, only valid non-deleted structures are copied. (This is the other part of "Compact" and the main part of "Repair")
3. Rename the initial DB.
4. Rename the new DB.
5. Delete the initial DB.

The problem is that in step 5, you are deleting the module in which your code was running. This is like the kids' cartoon image of sitting on a tree branch while sawing it off. Therefore, if you actually issued a command to do a compact & repair, the code running that command is about to go away. There is also a setting to do a C&R when closing the DB.

We have gotten reports that if a C&R fails, the result CAN become unusable. For this reason, we often suggest that a C&R should be done manually AFTER making a backup copy of the DB. (So that if it goes BANG ZOOM then you have an intact copy.) For various reasons, you don't want to make a copy of your DB via code because again you would be copying running code.

This next is MY opinion, perhaps shared by others... perhaps not. A front-end file should NEVER be C&R'd by an end user's action OR by automation, even if done implicitly. Instead, you should look into Pat Hartman's articles on auto-downloading a fresh COPY of the FE file each time you launch it. The developer can safely do a C&R on the master copy of the FE, so when you copy it, it IS as compact and as well repaired as it is going to get. Doing the FE download is about as fast as doing a C&R, but FAR safer.

Then set up a regular maintenance schedule that says "Every Wednesday afternoon at 3 PM" (or pick your other favorite time) "we will take the DB down for maintenance and backup operations." MANUALLY copy the back-end file or files to a temporary location, then C&R the BE manually, then make a "real backup" of the BE file that you will keep in an archive location. Then and only then, delete the backups from the temp area.

 

[JohnPapa]

Many thanks for all your feedback. Let me explain better.

I have two .accde files. The first .accde checks things such as bitness, whether there is a connection to the Internet, whether a BE exists.

If everything is OK the first .accde calls the second .accde, which is the main program. It is the second .accde which I want to be able to C&R. At the time of C&R the second .accde is not running.

With this setup I can even download a new version of .accde automatically, whether 32-bit or 64-bit. The process is transparent to the user and very quick since the .accde is zipped.

Pam is correct about the fact that C&R on a server is slow, so I always prompt the user for a local folder where the db is copied to from the server and then copied back. For a BE of about 250Mb it is fast.

Going back to my original question, I will try using the AutoExec macro, this being the first macro that I ever used for obvious reasons.

 

[JohnPapa]

Hi Pam, as I mentioned the functionality which I would like to add in the first .accde is to check whether the BE DB is used by any of the users and if none of the users are using the BE DB I would like to enable the user to C&R the BE DB. If any of the users are using the BE Db then no C&R would be possible.

I want to be able to give this option by running the code in the first .accde, by having the user press on the Shift key when running the first .accde. Identifying the Shift pressing is the trigger.

 

[isladogs]

Its ancient code but ....

Logged In Users

This utility allows you to select any Access database and monitor who is currently using it

isladogs.co.uk

 

[JohnPapa]

It's Pat, John.

Somewhere on @isladogs website is a link to a database that shows the active users in a database. You can use the code within that module to examine the roster list. Don't worry about what your name appears as. All you care about is that the db has only a single active user.

As I said. I would not use this method. You should not rely on a user to remember to do a C&R.

However if you don't want to create a scheduled task, you can create a table in the BE that you use to log the last C&R that happened on demand. In this table once the C&R is complete, you can update the last entry with the current size of the db. Then every time the FE opens, It can obtain the current size of the BE and compare it to the size at the last C&R and if the size has increased by more than 10% or whatever you deem the correct percentage, you can tell the user to run the C&R procedure or you can force it. You can also use the last forced C&R date to force a C&R at least once per month/week or whatever.

Good thoughts. Many thanks.

 

[JohnPapa]

If you ask it, it will explain it's reasoning.
Basically you set a TempVar in an AutoExec. If that Tempvar is not set, then the Shift was used to open the DB.

Bit of lateral thinking.
You can prevent the bypass, you know that do you not?

Hi Gasman, I have a .accde which has one form, which is specified as the startup form.

I tried to use AutoExec to open another dummy form and theoretically if Shift is pressed this dummy form would not be opened and in this way the user would know if Shift was pressed. The dummy form is opened when Shift is not pressed and is not opened when Shift is pressed, BUT cannot check from the main form whether the dummy form is open or not. Any ideas?

 

[Josef P.]

You can use a Win API function to check whether the mouse button is being held down at the current time.

 

[Gasman]

Hi Gasman, I have a .accde which has one form, which is specified as the startup form.

I tried to use AutoExec to open another dummy form and theoretically if Shift is pressed this dummy form would not be opened and in this way the user would know if Shift was pressed. The dummy form is opened when Shift is not pressed and is not opened when Shift is pressed, BUT cannot check from the main form whether the dummy form is open or not. Any ideas?

No need for the AutoExec to open a form I would have thought?
It is just there to see if shift was pressed on opening the DB.
So if not used, either do nothing or open your startup form, and take it out of the DB properties.

 

[JohnPapa]

No need for the AutoExec to open a form I would have thought?
It is just there to see if shift was pressed on opening the DB.
So if not used, either do nothing or open your startup form, and take it out of the DB properties.

Thanks Gasman. Can you please clarify:
1) Do I still define the Startup form?
2) What do I take out od DB properties?
3) How do I test if Shift was used?

 

[Gasman]

1. Up to you. If you open the form from the AutoExec, then No, otherwise Yes.
2. The startup form name.
3. The fact that AutoExec was processed or not?

So best to leave the form at startup alone and just create a simple Autoexec. The reason being, if you rely on the Autoexec opening the form and the Shift key is used to open the DB, you will not have that form open.

 

[JohnPapa]

1. Up to you. If you open the form from the AutoExec, then No, otherwise Yes.
2. The startup form name.
3. The fact that AutoExec was processed or not?

So best to leave the form at startup alone and just create a simple Autoexec. The reason being, if you rely on the Autoexec opening the form and the Shift key is used to open the DB, you will not have that form open.

I am using the /runtime shortcut. Am I correct in assuming that Shift will not work in this case?