If a form in Access DB is set as hidden. Then how to unhide it? so that we can manipulate the form programmentically using vb.net.
Thank you.
I cannot help with .net, in VBA:
Sub FormHidden()
Dim frm
For Each frm In CurrentProject.AllForms
SetHiddenAttribute acForm, frm.Name, False
Next
End Sub
The code Remou gave should work for unhiding forms whose properties have been changed to HIDDEN in the Access UI.
In VBA, to simplify Remou's example, that would be:
SetHiddenAttribute acForm, "MyHiddenForm", False
You may be required to automate Access from VB.NET in order to accomplish this, but SetHiddenAttribute is a method of the top-level Access application object, so ought to be fairly simple to use. The value of the VBA named constant acForm is 2, so you'd likely have to call that literally, something like this:
app.Application.SetHiddenAttribute 2, "MyHiddenForm", False
where the app object has been initialized as an Access application. Dunno how that's done in VB.NET, but in VBA it would be something like:
Set app = CreateObject("Access.Application")
I'm not sure if the correct syntax would be app.Application.SetHiddenAttribute or if it would be just app.SetHiddenAttribute, but you could easily try either one.
But keep in mind, it was Remou who gave the correct answer. I'm only speculating on how to make it work in a programming environment I don't even use!
Does the form have Visible property? You can set to true to make the form visible.
Do you mean the form is open but not visible, or that the form's meta properties are set to not visible? The later is something you shouldn't do, as items set with visible off will be deleted the next time the database is compacted.
Related
How can I stop Access from prompting "Do you want to save changes to the layout of query" when I try to close a form that has a subform in datasheet view?
I have a form with a subform in Datasheet view with the .SourceObject set to a temporary pivot / crosstab query (no actual form object). If the user changes the width of a column and closes the window with the built-in Access close button, the user (and annoyed developer) is always presented with the "Do you want to save changes to the layout of query" prompt.
I am able to avoid this prompt by setting MySubform.SourceObject = "" in the click of my Close button but anyone clicking the [x] button or pressing CTRL+F4 or CTRL+W gets the prompt.
I have put breakpoints in the Form_Close and Form_Unload events but this prompt appears before they fire.
I want to clarify further that this subform object is Unbound and not based on a form object. I am building a dynamic Crosstab SQL statement, creating a QueryDef with the SQL, and then setting MySubform.SourceObject = "query.qry_tmp_Pivot" This is a neat technique for a crosstab/pivot query because the columns can vary and I don't think a form object would support that.
I am able to use the Watch window on the MySubform object and I can see that a MySubform.Form object exists. It has a Controls collection containing a control for all of the columns in my query. I have an optional routine that I can run that will loop through all of the controls and set their .ColumnWidth = -2, which will auto-size the column width based on the widest data of the visible rows in the datasheet. When this routine was running I was noticing that every time I closed the form (not using my Close button) I was getting the save prompt. I have disabled this routine for debugging but a user will still get the prompt if they manually adjust any column width.
I feel like I need to explain this extra detail so you realize this is not an Access 101 issue. You probably know that if you've read this far. Here's another thought I had: Maybe I could trap the Unload event in the subform control before the prompt happens. Because there is no true Form object to put test code in, I created a class object and passed MySubform to it. The class uses WithEvents and creates events like OnClose and OnCurrent on the class module's mForm object. Sample class code is below.
Private WithEvents mForm As Access.Form ' This is the form object of the Subform control
Public Sub InitalizeSubform(Subform As Access.Subform)
Set mForm = Subform.Form
Debug.Print Subform.Name, mForm.Name, mForm.Controls.count
' Create some events to intercept the default events.
mForm.OnClick = "[Event Procedure]"
mForm.OnClose = "[Event Procedure]"
mForm.OnUnload = "[Event Procedure]"
mForm.OnCurrent = "[Event Procedure]"
End Sub
Private Sub mForm_Click()
Debug.Print "Clicking " & mForm.Name
End Sub
Private Sub mForm_Current()
Debug.Print "On Current " & mForm.Name, "Record " & mForm.CurrentRecord & " of " & mForm.RecordsetClone.RecordCount
End Sub
Private Sub mForm_Unload(Cancel As Integer)
Debug.Print "Unloading " & mForm.Name
End Sub
Private Sub mForm_Close()
Debug.Print "Closing " & mForm.Name
End Sub
The VBE Watch window shows my new events on the mForm object but unfortunately they never fire. I know the class works because I used it with a bound subform and all of the events are intercepted by the class. I'm not sure what else to try.
Events on the subform never fire because it's a lightweight form (without a module). See this Q&A and the docs. Lightweight forms don't support event listeners, but do support calling public functions from an event, e.g. mForm.OnClick = "SomePublicFunction()"
Note that the workaround described in this answer also opens up the possibility of displaying a crosstab query in a form without saving it at all.
Alternatively, you could try capturing the event on your main form, and suppress saving there.
I gave answer credit to #ErikA for this question. He directed me to an answer to a somewhat related question here which is what I ended up implementing and it works. His instructions were very straightforward and easier to implement than I first anticipated.
The answer to my question seems to be that it may not be possible to avoid the save prompt when using a lightweight form object. If someone comes along with a solution I'd still like to hear it.
What I learned from this experience:
An unbound subform that has its .SourceObject set to a table or query will not have a code module. This considered to be a lightweight object.
Public functions can be added to event properties on lightweight forms but they don't seem to fire before the save prompt appears as the parent form is closing.
Binding a pivot query or temp table to a real form object that has 254 controls on it is the only way I found that doesn't prompt to save design changes when the parent form closes. Mapping the query/table columns to the 254 datasheet controls is super fast.
A class is a nice way to intercept events if you're not using a lightweight object. A class also lets you open multiple instances of the same object.
I ended up not implementing my solution without using a class because there were no events I needed to capture. At this point I don't need my frmDynDS to be used for other purposes and I'd like to keep the object count down (this is a large app with 1400+ objects).
I put the following code in a function that gets called when the subform is loaded or refreshed.
With subCrosstab
' Set the subform source object to the special Dynamic Datasheet form. This could be set at design time on the Subform control.
.SourceObject = "Form.frmDynDS"
' Run the code to assign the form controls to the Recordset columns.
.Form.LoadTable "qry_tmp_Pivot" ' A query object works as well as a table.
' Optional code
.Form.OnCurrent = "=SomePublicFunction()"
.Form.AllowAdditions = False
.Form.AllowEdits = False
.Form.AllowDeletions = False
.Form.DatasheetFontHeight = 9
End With
I can now resize the columns and never get a prompt to save layout changes no matter how I close the parent form.
I just like to reorder the VBA of a bunch of Forms in Access, doing all nearly the same. So I created a class clsPopup and I just want to pass some collections out of all this Forms into the class, so I can access their entries over there or in there or how ever.
I could pass the Form-element of the Popup to the class as I created a sub named Load in clsPopup like
Dim m_frm As Form
sub Load(frm As Form)
Set m_frm = frm
debug.print m_frm.colSp("Name")
end sub
In the Form I tried
Dim m_clsPopup As clsPopup
Dim colSp As Collection
sub Form_Load()
Set m_clsPopup = New clsPopup
Set colSp = New Collection
colSp.Add "SomeString", "Name"
m_clsPopup.Load Me.Form
end sub
At this point I got the 2465 Runtime error in the line of m_clsPopup.Load Me.Form.
My main idea is, to just collect all the needed data within the Forms as collections and than I easily could work with them in the class.
Of course I thought of arrays, but collections seems so much more handy and I could avoid some terrible indexing.
Ahh, and it needs to work in Access 2010. Might that be the problem?
I feel like just a tiny pice of code is missing. Could anyone help to create nice code out of a masterpiece of redundancy?
I have an application with several forms(frm1, frm2...). Under each form there is a sub method: sub1. Is that possible to create a method in module to get all opened forms and made then run frm1.sub1, frm2.sub1...?
I already know that My.Application.OpenForms can find all opened form. But how to use this for next step? Since there are bunch of forms I can't name the form like this one by one.
'$'
Dim frm As Form
For Each frm In My.Application.OpenForms
If frm Is My.Forms.TheFormINeed Then
'do something
end if
This may sounds newbie. Please help me.
If all the subs you want to run are present in all the forms, then
For Each frm In My.Application.OpenForms
CallByName(frm, "sub1", CallType.Method, Nothing)
Next
should do the trick.
Bear in mind of course that your main form may not have the sub, so you can use If..Then etc to include or exclude particular forms of course.
You can name forms by the way by setting the.Name property
folks. I am new to programming, but I am writing some macros to help manage a shared Excel workbook for my job.
I am implementing a few different user roles for people who need to access this workbook. The security is not very critical, just to prevent people from accidentally making (and saving) changes to things they shouldn't be. I am just having a UserForm prompt for the password and, based on what's entered, grant the proper access.
I have it written so that the user's entry into textbox on the UserForm is referenced directly as Me.textboxPasswordEntry.Value for any comparisons. It occurs to me that this may not be best practice, but I can't put my finger on why. Maybe I'm just over thinking? At the same time, it seems silly and wasteful to declare a variable, pass the value to the variable, and then analyze that.
The Sub below is from the UserForm, and I've included it to show you what I mean. This is a very straight-forward scenario, I know, but am I courting trouble if I continue this practice through more complex ones? If so, what kind of problems might I run into?
Thanks.
Private Sub buttonOK_adminPW_Click()
'The subs SetUserType_[level] are in the ChangeUserType module
'AdminPass and DesignPass are module-level variables set on UserForm initialization
'Default user type is User. Read-only access.
'Admins can edit the workbook, but must save via a macro to ensure
' things are reset properly for Users (some sheets hidden, etc.)
'Designers can edit the workbook, but also have full ability to save using
' the regular file menu/ctrl+s/etc.
Application.ScreenUpdating = False
Select Case Me.textboxPasswordEntry.Value
Case AdminPass
'Shows right control buttons and unlocks the wkbk for admin access
SetUserType_admin
Unload Me
Case DesignPass
'Shows all control buttons and unlocks the wkbk for designer access
SetUserType_design
Unload Me
Case Else
MsgBox ("Password incorrect. Please retry.")
With Me.textboxPasswordEntry
.Value = ""
.SetFocus
End With
End Select
Application.ScreenUpdating = True
End Sub
Yeah I've also pondered over "best practise" with userforms over the years... I guess it's just through experience that I use approach below most often:
Use as little code as possible in the userform itself (thinking
is, the form is more "reusable" if it does as little as possible
back to its parent... its reason for existance is just to get input)
Do use code on the "activate" event of the form to clear all the
fields on the form (this makes sense to be in the form because then
you don't need to remember every control on the form to clear at
every point you use it)
Either directly reference objects from
the form in your calling code (i.e. stPassword =
userform1.tbPassword.value) or...
Use "public" variables in the
userform ... i.e. before all code in userform declare "public stPasswordInput as string" then you can reference in your calling code with e.g. stPassword = userform1.stPasswordInput
I'm keen to see what other people suggest though!
I created my own Outlook form to use it as standard surface to enter certain orders instead of the normal message form. The creation, editing and sending works perfectly fine and in the next step I want to insert some code via VBA.
My problem is that I can´t access the objects of my form in the VBA editor. E.g. I want to show a message box when a certain checkbox is checked. According code would be:
Sub example()
If CheckBox1.Value = True Then
MsgBox("Checkbox 1 is checked.")
End If
End Sub
When I run the code I get the error that the object could not be found. The same goes for every other object, like textboxes or labels etc.
I guess the solution is pretty simple, like putting Item. or sth. like that in front of each object. But so far I wasn't able to find the solution.
I´m using Outlook 2010.
I know this is a year too late but you'll want to do something like this example below. It's kinda a work around but you can get whatever value was selected.
Sub ComboBox1_Click()
Set objPage = Item.GetInspector.ModifiedFormPages("Message")
Set Control = objPage.Controls("ComboBox1")
MsgBox "The value in the " & Control.Name & _
"control has changed to " & Control.Value & "."
End Sub
You should be able to get the value, just get a handle on the object you want using the Inspector
The following is an excerpt from here
When you use a custom form, Outlook only supports the Click event for
controls. This is a natural choice for buttons but not optimal for
controls like the combo box. You write the code by inserting it into a
form’s VBScript editor. You need to have the Outlook form open in the
Form Designer and click the View Code button found in the Form group
of the Developer tab.
Sub CheckBox1_Click()
msgbox "Hello World"
End Sub
The code page is fairly minimal with no syntax highlighting. I just tried this now and it does work. Dont forget to Publish your form to pick up the new changes.
I know this is almost 6 years late but, in VB and VBA, simply start with the form name. (And if that doesn't work, just keep going up a parent object and you'll get there.) So, your code becomes:
Sub example()
If MYFORMNAME.CheckBox1.Value = True Then
MsgBox("Checkbox 1 is checked.")
End If
End Sub
Of course, after typing "MYFORMNAME." you'll know if it will work because typomatic will kick in when the system recognizes "MYFORMNAME" after you hit the period.