I have Office 2003.
I would like to create Commandbar with timer in MS Access using VBA.
What I want is on ever half a second command bar button gets the name of active forms and lists name of forms.
How can I do that?
You can create a CommandBar using a Macro object in Excel 2003. However, needing to update it every 1/2 second is complete overkill. Forms won't get added or dropped very frequently, so you should have a static list for both performance and maintenance reasons.
The best way is to actually make a custom menu (an AddMenu line in the Autoexec macro) that calls a different macro with all the menu entries in it. Actual command bars require a good amount of VB to make them work properly.
Related
Below is my XML code
<toggleButton id="CloseBtn" label = "Close"
size="large"
imageMso="FrameDelete"
onAction= "=InvoiceRibbon_Close()"
getPressed="MyToggle"
keytip="C"
supertip= "Close current window."/>
By Function is Form code:
Public Function InvoiceRibbon_Close() As Boolean
It works on three computers. Two have Office 2016 Access and one is Access 2016 run time only. It does not work on the other two computers. Both are Access 2016 run time only. All three 2016 Run time computers are new computers which is Windows 10. Error message is attached.
The onAction function is inside Form VBA code. Below are some testing I did.
If I move InvoiceRibbon_Close to Module, it works.
On module OnAction function, I still cannot call function which is inside Form by Call Forms("FormName").InvoiceRibbonTesting_Close. Error message is still the same.
The function in Form works. I used it for a while.
I want to keep the function in Form VBA. I have hundreds Functions which is form related. It will be a huge tasks to move it to Module
Well, on the computers that fail, does ANY VBA code work? So, button code and what not - check if they work. If they don't work, then of course the Ribbon code will not work.
The other issue:
Check if you have a timer form running. Remember, the FANTASTIC idea you are using is to call functions in the form, and NOT USE horrible call backs which MUST be placed in standard code modules and thus are not attached to the given form in which 99% of the time we want code in that form to run and be used (say like any standard button code, but now you are using the ribbon. So, your setup is good and a high recommend approach.
Some things to check for this failure:
Does any VBA run at all? Check the trusted location settings.
Do you have a timer form running in the background. This is VERY but VERY VERY VERY important to check. What occurs with a timer form is that the form focus actually CHANGES to the the timer form while the timer code runs, and then returns back to whatever form currently has the focus. This is HUGE HUGE HUGE important since when you click on a ribbon button, it will FIRST TRY to run code in the current focused form's code module. This is good and great, since as you note that's were you have (and should) have that code that belongs to that form.
However, IF DURING THE TIME you click on the ribbon and the current forms focus changes (such as timer code, or other forms code running that MIGHT/MAYBE/COULD/PERHAPS/POSSBILE changes the forms focus to another?
Well, the Ribbon will look for and try to find that routine in the form with the CURRENT focus. A timer form running thus will change the form's focus, and if you click that button while the timer form code is running, then THAT FORM at THAT POINT in time actually has the focus, and thus the Ribbon will actually be attempting to find and run the function name in your ribbon in that timer form!!
You can quite quick test the above by removing for a test any timer forms you have running.
The other thing to look for is any kind of accidentally forms focus change. So, say a you recent added a sub form, or another navigation form or what not? Well, now the form you think that has the focus does not in fact have the focus, and thus the ribbon can't find the routine to run. This often happens when you say switch to a nice new computer, are using say the runtime. With a newer machine, often everything is running so much better and faster, that the FOCUS CHANGE you did not see much now occurs in a far more aggressive fashion.
The bottom line and thing you are looking for here is:
Does a un-expected form focus change occur. Say to some sub form that specifies a different ribbon, or some other small message or dialog or popup form that appeared un-expected. With any of these objects getting focus, then your main form with the code that the ribbon buttons call will not be found.
So, this is not a trusted location (ie: other VBA code works just fine), then next to check and test with is if any timer form is running (since as noted such forms VERY quick do get and rob the current forms focus away - and if you hit the ribbon at the same time while the timer code runs, then the focus change has also occurred, and thus the ribbon button will fail.
The above as a result ALSO means:
Don't have a timer form(s) if you can avoid as such.
The timer code if you have has to be VERY good and efficient code - it better get in, run VERY fast, and get out.
Don't have a aggressive timer interval. So, say some timer is to check and shut down access? Well, checking 10 times a second, or even once a second is OVER kill. Have it check say every 3 seconds.
Note that the above timer issue also often causes report print buttons to fail - you find that some blank form gets printed (and that blank form is in fact the timer form that temp had the focus when you hit your report print button.)
I currently have a functioning form that searches through my database by calling a query. What I'm trying to do is turn this into a standalone application where I can simply open a file and only the form opens, running the database on the back-end. I have tried running a macro that opens the form, and I have tried creating a shortcut to my desktop, but nothing has worked.
Does anyone have any suggestions? Anything that will only show the form and the search results would be good (desktop shortcut, HTML file, etc.).
Thanks!
You will need to split your database so that the tables are located in a separate back-end file (which can be kept on a server). These instructions apply to Access 2007 and 2010 but the process is very similar for 2013.
Once this is done, your tables will become linked tables (stored in a separate file) and your front-end .addcb file will only contain queries, forms and reports.
You can control which form opens when the application loads through File -> Options -> Current Database. There are also several other useful controls here for limiting what the user can do; ie.
Hiding the list of database
Hiding the tabs (you will therefore need to create buttons to move between forms)
Hiding the Ribbon and/or status bar
Disabling Layout View
It's safest to change these settings on a copy, so you don't inadvertently lock yourself out; however, by holding down shift when opening the file from within Access, most of these options will be bypassed and you will be able to edit the database / revert these settings should you need to.
In terms of making it a "stand-alone application", it is possible to create a copy that will open without requiring the full version of MS Access on the user's PC (instead using Access Runtime).
I always distribute my front-ends as .accde format (File -> Export ACCDE). The benefits are as follows:
Smaller file size
Optimise memory usage / improves performance
VBA code runs but cannot be viewed or edited
I think what you're looking for is here:
http://office.microsoft.com/en-us/access-help/command-line-switches-for-access-HA010166605.aspx
and
http://office.microsoft.com/en-us/access-help/command-function-HA001228801.aspx
Basic idea, create a macro called AutoExec that checks for a command line argument when opening the database. Setup a shortcut with a command line argument (whatever you decide to name it, I'll use 'lookuponly' as the example.) like this:
"C:\Users\%Username%\Desktop\MyDatabase.mdb" /cmd "lookuponly"
when you double click the shortcut it should auto-run the macro and open your lookup form. Of course under newer versions of access you'll have to set the location of the database as a trusted location or access will attempt to block the database.
http://office.microsoft.com/en-us/access-help/decide-whether-to-trust-a-database-HA010256412.aspx
I am trying to update an existing Switchboard in an Access database. When I click the "Switchboard Manager" button, I get the error "Invalid Procedure Call or Argument." Any ideas what might be causing this or how to fix it?
The switchboard manager stores your settings in a table named Switchboard Items. Open that table in Datasheet View, and see whether you can spot any stored values which don't make sense. Sorry, I can't tell you specifically what doesn't make sense ... hopefully you'll know when/if you see it.
Actually that error message sounds to me more like a problem with the form itself. So rename the form and table, and create a new switchboard, which will also create a new copy of the Switchboard Items table.
If that new form/table combination works correctly, delete or rename the new copy of Switchboard Items. Then rename the old saved version of that table back to Switchboard Items again and try it with your new form. If the problem was solely due to the form, your new clean copy of the form should now work with the original version of Switchboard Items.
Note that many Access developers avoid the switchboard manager. It is limited and brittle. You can substitute custom forms which command buttons for your menu options. That may seem like more work, but it's not a huge amount of extra work, and you will be protected against switchboard manager breakage.
I took a already set up database from the Office.com templates (File --> New --> Office.com Templates), since this template already gave me 80% of my requirements.
I then changed the last 20% of this template where I came into the following: It seems as this template is a web database. I am not sure about the differences of a web database and a normal database in Access at all but I did find out, they do not allow me to run VBA code. At least not when I am trying to call it by an event.
Is there any way to achieve this anyways? Or are there possibly any other ways, such as converting the web database into a normal one perhaps?
Actaully, you can call VBA code from the forms event code. However, it requires a bit of a kluge.
However, you don't need to do this in your case.
Do note that you can create client objects and use client VBA code in your web application.
This means you can add/mix VBA forms into that application (these client objects of course cannot run in a web brwoser, but they can be used the client).
Suggestion #1:
to hide record navigation buttons.
Open the web form in layout mode. Move a object (dirty the design).
Whack ctrl-g for VBA command prompt. Type in this:
forms(0).NavigationButtons = False
Now, save the form. The record navigation setting will be saved with the form.
Suggestion #2:
Open the web form with VBA. Use this code:
DoCmd.OpenForm "AssetsDetails"
Forms("AssetsDetails").NavigationButtons = False
Suggestion #3:
Call VBA code from the forms load event. This is a bit of kluge, but does work:
In the forms open event, place this macro code:
OpenForm (frmRunVBA,,,Dialog)
Note that in above WEB MACRO editor the VBA form above called frmRunVBA does NOT appear in the drop down choice list - but you CAN TYPE/force in the name – this is legal.
Now create a VBA form called frmRunVBA). In the forms load event, palce this code:
Private Sub Form_Load()
Forms("AssetDetails").NavigationButtons = False
DoCmd.Close acForm, Me.Name
End Sub
So you can call VBA code, but you really don't need to if you use tip#1.
I have a macro assigned to the onClick event of a button in a form. How can I call this macro programmatically?
I tried
btnName_Click
But this does not work since there is no function called btnName_Click() ... obviously :)
I can access the onClick Member via Me.btnNewRecord.OnClick but don't see a way to run the macro.
After extensive searching, I do not believe it is possible to reference the embedded macro, and run it. You can view the XML of the macro, but I know of no way of running it or even accessing it beyond it's XML stored as a string. A possible work around would be to convert all macros to VBA. To do this:
Open the form in design view.
Click Convert Form's Macros to Visual Basic
now you should be able to call the button's code with btnName_Click as you showed in your question. Obviously if you did this, you would sacrifice the advantage of using macros (i.e. limited functionality without the user needing to trust your database).
Original Answer, which doesn't apply to Embedded Macros:
Use DoCmd.RunMacro
Example:
Docmd.RunMacro(macroname)
where macroname is a string representing the name of the macro.