Solved Hiding a Form (1 Viewer)

abdullahkhan

Member
Local time
Tomorrow, 01:20
Joined
Apr 14, 2020
Messages
146
Hello,

Consider a database DB1 and DB2. It is intended to import free forms if DB1 into DB2. Now is it possible to hide a specific form of DB1 so that it does not show up under forms tab in import dialogue of DB2.

I tried selection Hidden attributes in form properties (by right clicking on the form and then selecting "View Properties" and then clicking on Hidden checkbox) but it still shows up in the import dialogue.

Best Regards,
Abdullah
 

arnelgp

error reading drive A:
Local time
Tomorrow, 04:20
Joined
May 7, 2009
Messages
9,580
see this discussion on how to Hide the database objects.
 

abdullahkhan

Member
Local time
Tomorrow, 01:20
Joined
Apr 14, 2020
Messages
146
see this discussion on how to Hide the database objects.
Thanks for reply. I used similar procedure for hiding few tables and it works for tables. My issue is regarding form. How can I deep hide a form?
 
Last edited:

Micron

AWF VIP
Local time
Today, 16:20
Joined
Oct 20, 2018
Messages
3,115
Do you really care if it can be seen, or are you just trying to prevent anyone from importing it into another db? If the source file is mde or accde, you can see reports, forms, macros and modules but you can't import them.
 

abdullahkhan

Member
Local time
Tomorrow, 01:20
Joined
Apr 14, 2020
Messages
146
Do you really care if it can be seen, or are you just trying to prevent anyone from importing it into another db? If the source file is mde or accde, you can see reports, forms, macros and modules but you can't import them.
Honestly. Problem is not just seeing it or importing. Problem is, I don't want some one to see its name and then export a form with same name and over write original form. I set this form to open at startup just to run some code and then close.
 

Micron

AWF VIP
Local time
Today, 16:20
Joined
Oct 20, 2018
Messages
3,115
Well maybe arnelgp will help you adapt the code he suggested but I don't understand what you mean by your reply. It sounds like there might be 2 or more developers adding changes to a main db being developed and this has nothing to do with users but I don't know.
 

abdullahkhan

Member
Local time
Tomorrow, 01:20
Joined
Apr 14, 2020
Messages
146
Well maybe arnelgp will help you adapt the code he suggested but I don't understand what you mean by your reply. It sounds like there might be 2 or more developers adding changes to a main db being developed and this has nothing to do with users but I don't know.
In other words, I don't want the users or anyone else to see the name of a specific form by using backdoor of database i.e. using import dialogue.
 

isladogs

CID Moderator
Staff member
Local time
Today, 21:20
Joined
Jan 14, 2017
Messages
13,386
Hi
I've just seen this thread after reading your PM.
I must admit I don't really understand the point of this thread.

You can right click any database object including forms in the navigation pane and hide it.
However it can still be viewed if Show Hidden Objects is ticked and , of course, the process is reversible.

Only tables can be 'deep hidden'. It would also be useful for queries but it can't be done
There is no equivalent process for forms and frankly I can't see any reason why it would ever be useful.

If you don't want users to be able to perform actions like exporting forms, apply security such as disable shortcut menus, hide the navigation pane and remove Access options then convert to an ACCDE.

Hope that helps
 

isladogs

CID Moderator
Staff member
Local time
Today, 21:20
Joined
Jan 14, 2017
Messages
13,386
I've just read the link @arnelgp provided in post #2.
I disagree with two points made by the OP in that thread
1. Deep hidden tables are not deleted when a compact and repair is done. If that was ever the case, it hasn't been true for at least a decade.
2. Queries cannot be deep hidden
 

abdullahkhan

Member
Local time
Tomorrow, 01:20
Joined
Apr 14, 2020
Messages
146
Hi
I've just seen this thread after reading your PM.
I must admit I don't really understand the point of this thread.

You can right click any database object including forms in the navigation pane and hide it.
However it can still be viewed if Show Hidden Objects is ticked and , of course, the process is reversible.

Only tables can be 'deep hidden'. It would also be useful for queries but it can't be done
There is no equivalent process for forms and frankly I can't see any reason why it would ever be useful.

If you don't want users to be able to perform actions like exporting forms, apply security such as disable shortcut menus, hide the navigation pane and remove Access options then convert to an ACCDE.

Hope that helps
Thanks for reply. I just wanted to hide name of one form so that it should not appear in the import dialogue when someone used my db to import into other db. I guess it is not possible. The purpose of while this practice is to close the back door into my db (I'm not using ACCDE because of 32bit and 64bit problem).

I'm not using AutoExec macro to trigger startup procedures and also I set a procedure which delete AutoExec macro if there is any. I use a form (let's say frmStart) to trigger all those actions (alternate to AutoExec macro) by putting those procedures in on_load event and then selecting this form to open when current db is opened (options>current document).

Anyone can export AutoExec macro (may be blank) from any other db just to replace my AutoExec and prevent triggering procedures that I set. So I set a procedure to delete any AutoExec macro in my database on_load event of frmStart. That anyone can also export blank frmStart into my db (that is only possible if he knows that my startup form's name is frmStart. So the main purpose is to hide this name.

So if anyone who has my DB can use this to browse for import into my his db or any blank db can see all the forms present my db and if he sees form name like frmStart or similar, he may create a blank form with the same name and export it into my db. Now when this db is when opened, there is no code in the on_load event of startup form and the db is unprotected. I hope I made my point clear. So if hiding is not possible, any other suggestions are welcomed to address this scenario.

Best Regards
Abdullah
 

theDBguy

I’m here to help
Local time
Today, 13:20
Joined
Oct 29, 2018
Messages
10,713
Thanks for reply. I just wanted to hide name of one form so that it should not appear in the import dialogue when someone used my db to import into other db. I guess it is not possible. The purpose of while this practice is to close the back door into my db (I'm not using ACCDE because of 32bit and 64bit problem).

I'm not using AutoExec macro to trigger startup procedures and also I set a procedure which delete AutoExec macro if there is any. I use a form (let's say frmStart) to trigger all those actions (alternate to AutoExec macro) by putting those procedures in on_load event and then selecting this form to open when current db is opened (options>current document).

Anyone can export AutoExec macro (may be blank) from any other db just to replace my AutoExec and prevent triggering procedures that I set. So I set a procedure to delete any AutoExec macro in my database on_load event of frmStart. That anyone can also export blank frmStart into my db (that is only possible if he knows that my startup form's name is frmStart. So the main purpose is to hide this name.

So if anyone who has my DB can use this to browse for import into my his db or any blank db can see all the forms present my db and if he sees form name like frmStart or similar, he may create a blank form with the same name and export it into my db. Now when this db is when opened, there is no code in the on_load event of startup form and the db is unprotected. I hope I made my point clear. So if hiding is not possible, any other suggestions are welcomed to address this scenario.

Best Regards
Abdullah
Hi. Pardon me for jumping in, but I think @isladogs already told you how to hide a form, so it won't show in the import Wizard, if they didn't elect to show hidden objects. So, in a sense, it is very possible. However, since you don't use ACDDE, there is no point in hiding your startup form, because they can still see its name from the Options settings. You cannot really protect your work, if you don't use ACCDE. To overcome the 32/64-bit issue, you'll just have to use two versions of your ACCDE. If none of the above answers are acceptable to you, then you might start thinking about using another platform than Access. Just my 2 cents...
 

abdullahkhan

Member
Local time
Tomorrow, 01:20
Joined
Apr 14, 2020
Messages
146
Hi. Pardon me for jumping in, but I think @isladogs already told you how to hide a form, so it won't show in the import Wizard, if they didn't elect to show hidden objects. So, in a sense, it is very possible. However, since you don't use ACDDE, there is no point in hiding your startup form, because they can still see its name from the Options settings. You cannot really protect your work, if you don't use ACCDE. To overcome the 32/64-bit issue, you'll just have to use two versions of your ACCDE. If none of the above answers are acceptable to you, then you might start thinking about using another platform than Access. Just my 2 cents...
Thanks for reply and suggestions.
 

theDBguy

I’m here to help
Local time
Today, 13:20
Joined
Oct 29, 2018
Messages
10,713
Thanks for reply and suggestions.
Hi. I hope you took it as "constructive criticism." There were a few "holes" in your logic. First of all, the Wizard is not the only way to "import" objects from one db to another. So, even if the Wizard "can't see" your form, it doesn't mean it can't be imported into another db. Second of all, the code in the Autoexec macro fires first before the code in the Startup Form. So, removing an Autoexec macro using code from a Startup form is "too late" to protect you from said Autoexec macro.
 

isladogs

CID Moderator
Staff member
Local time
Today, 21:20
Joined
Jan 14, 2017
Messages
13,386
@theDBguy has made many of the points I was going to make
There is little point worrying about security if you don't use an ACCDE file for your FE.
As you have users running both 32-bit & 64-bit Access, you will need to create two versions of the ACCDE for each bitness.

The next most important things are the items I mentioned in post #9:
apply security such as disable shortcut menus, hide the navigation pane and remove Access options then convert to an ACCDE.
Some other points:
1. Even if you hide forms etc in a ACCDB, anyone can import them from another database if they tick Show Hidden Objects
2. If you import a database object with the same name as an existing object e.g. frmStart, the imported object is given a subscript such as frmStart1. The existing object is not overwritten.
3. If you have good reason to be so concerned about users deliberately trying to undermine your work and wreck your database, then you should move your data to a more secure RDMS such as SQL Server ... and, of course, use an ACCDE file for your FE
 

Pat Hartman

Super Moderator
Staff member
Local time
Today, 16:20
Joined
Feb 19, 2002
Messages
28,998
I have to say I'm perplexed at the problem you are trying to solve. Users shouldn't be sharing copies of your FE so if one user breaks his copy, it's HIS problem and his management should be notified because he shouldn't be mucking around in databases where he doesn't belong. Why in the world would anyone insert an autoexec into an app created by someone else unless they intended to do damage? A person like this needs to be reported and fired for destroying company property.

That said,
Try renaming the FE from .accdb to .accdr. I don't know if this will cause a 32/64 problem. This tells Access to always treat this app as a runtime so it prevents users from putting anything into design view or linking to the app. If the problem user knows enough to rename the app back to .accdb, he'll do it but it will prevent accidental changes. Also, although Access file extensions have meaning, you can actually use any extension you want. So you can name your app:
MyApp.abc

Double clicking on it won't open it and the import utility should not work either. To open it with a shortcut, just reference the path to MS Access and follow with the full path/name of the app db.
 

abdullahkhan

Member
Local time
Tomorrow, 01:20
Joined
Apr 14, 2020
Messages
146
I hope you took it as "constructive criticism.
Hi, definitely I took it that way because I decided to use ACCDE (that is why I thanked for suggestion) and sorry for my short reply due to which it looked other way. Even though I have 32bit access but I'll use other PC to make 64bit ACCDE. You've suggested using ACCDE before in my some other post but I was reluctant due to x32 and x64 problem. It seems that ACCDE is inevitable.
Second of all, the code in the Autoexec macro fires first before the code in the Startup Form.
For this, I hope you don't mind but I'll object to this statement. See the attached database which just have one form and an autoexec macro. Form is set to open at startup and it fires first and then the macro. Form on_load even and autoexec both have a messagebox in embeded macro to show which fires first.
If you have good reason to be so concerned about users deliberately trying to undermine your work and wreck your database, then you should move your data to a more secure RDMS such as SQL Server ... and, of course, use an ACCDE file for your FE
Thanks for detailed reply. My database is not that critical nor my users will try to wreck the database. I'm new to access and want learn with different approaches and may be these approaches look silly.
Double clicking on it won't open it and the import utility should not work either. To open it with a shortcut, just reference the path to MS Access and follow with the full path/name of the app db.
Thanks for detailed reply. As I stated above, my approaches seems silly because I am new to developing access databases and learning different ways and methods. I just think if someone try to break into like this then how would it can be prevented. An I will try this too i.e. the thing you suggested about renaming.

And I hope you guys don't mind me discussing such approaches here. When I post something, I have in mind that if it couldn't be done in the way I thought it should be done then I will get some other way to prevent this issue.

Thanks a lot again you guys for putting in your time for helping.
 

Attachments

theDBguy

I’m here to help
Local time
Today, 13:20
Joined
Oct 29, 2018
Messages
10,713
For this, I hope you don't mind but I'll object to this statement. See the attached database which just have one form and an autoexec macro. Form is set to open at startup and it fires first and then the macro. Form on_load even and autoexec both have a messagebox in embeded macro to show which fires first.
Hi. I stand corrected. I remembered it wrong. Thanks for reminding me. Since I don't use embedded macros, I never saw a startup form fire before the Autoexec macro. Good luck with your project. Cheers!
 

Pat Hartman

Super Moderator
Staff member
Local time
Today, 16:20
Joined
Feb 19, 2002
Messages
28,998
I just think if someone try to break into like this then how would it can be prevented.
Access has very little protection against hackers which is why you rarely see "shrink wrapped" products built on Access. I do have a product sold to the "public" that uses an Access FE and either an ACE or SQL Server BE bu my client base is corporations and they actually sign a binding non-disclosure agreement and spend thousands of dollars each year for annual support.

In a business environment, you will rarely run into people who try to hack the database. But, you should still use some standard protection against accidental damage and the .accde does that.
 

isladogs

CID Moderator
Staff member
Local time
Today, 21:20
Joined
Jan 14, 2017
Messages
13,386
I was also surprised to see that the startup form loaded first. I modified your code to use an event procedure instead of an embedded macro. Same result. Normally you would either use start up code in an autoexec macro OR in a startup form, not both!
Autoexec is useful where you need to ensure 'safe' code runs even if an application is opened when it hasn't been trusted
 

Users Who Are Viewing This Thread (Users: 0, Guests: 1)

Top Bottom