I am trying to make my Access (2013) application look less like Access and more like a "real" piece of software. One of the things I am trying to accomplish is changing the icon from the normal A/grid/lock to an image of my choosing.
Is this possible? If not really, what is my next best option?
Thanks!
You can change the icon that Access shows when running your database, it's under Options -> Current database.
You cannot change the icon that Explorer shows for your .accde file.
Of course you can create a shortcut with the commandline to MSACCESS.EXE and your database, and that shortcut can have a custom icon.
You may also be interested in this answer by Albert D. Kallal: https://stackoverflow.com/a/24638829/3820271
I just developed this method yesterday to allow an Access Executable to have a custom icon. It does involve making some additions to your computer's registry. Be aware I did this for Access 2010 on a Windows 7 machine. I have not tested this for windows 8 or 10, but I do think it will be the same.
I know the entries of .14 ONLY refer to Access 2010. Access 2013 should be .15 and Access 2016 should be .16.
When you export your "accde" registry entries to a .reg file, stick with the .14, .15, or .16 that is exported for your specific system. The only thing you will be changing is any occurrence of "accde" to "accxx" with the "xx" being your new letters for your chosen suffix for the Access executable database.
Below is the .reg file that will perform the registry "fixes" and I have included a few notes along the way. This is not for the beginner, but I do believe a seasoned Access developer should be able to follow. Are you a little uncomfortable with the registry? Use Google to help you find a write-up or two about the registry and how to make changes to the registry.
OK, the .reg file:
Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\.accVR]
"Content Type"="application/msaccess.exec"
#="Access.ACCVRFile.14"
[HKEY_CLASSES_ROOT\.accVR\Access.ACCVRFile.14]
[HKEY_CLASSES_ROOT\.accVR\Access.ACCVRFile.14\ShellNew]
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\
FileExts\.accVR]
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\
FileExts\.accVR\OpenWithList]
"a"="MSACCESS.EXE"
"MRUList"="a"
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\
FileExts\.accVR\OpenWithProgids]
"Access.accVRFile.14"=hex(0):
[HKEY_CLASSES_ROOT\Access.ACCVRFile.14]
#="Microsoft Access ACCVR Database"
[HKEY_CLASSES_ROOT\Access.ACCVRFile.14\CLSID]
#="{73A4C9C1-D68D-11D0-98BF-00A0C90DC8D9}"
[HKEY_CLASSES_ROOT\Access.ACCVRFile.14\DefaultIcon]
#="C:\\_Work\\VR\\VR Logo.ico"
[HKEY_CLASSES_ROOT\Access.ACCVRFile.14\shell]
[HKEY_CLASSES_ROOT\Access.ACCVRFile.14\shell\Open]
[HKEY_CLASSES_ROOT\Access.ACCVRFile.14\shell\Open\command]
#="\"C:\\Program Files (x86)\\Microsoft Office\\Office14\\MSACCESS.EXE\" /NOSTARTUP \"%1\" %2 %3 %4 %5 %6 %7 %8 %9"
"command"=hex (7):79,00,6b,00,47,00,5e,00,56,00,35,00,21,00,21,00,21,00,21,00,\
21,00,21,00,21,00,21,00,21,00,4d,00,4b,00,4b,00,53,00,6b,00,41,00,43,00,43,\
00,45,00,53,00,53,00,46,00,69,00,6c,00,65,00,73,00,3e,00,32,00,41,00,5a,00,\
7e,00,60,00,4f,00,37,00,71,00,43,00,3f,00,4f,00,57,00,2c,00,66,00,65,00,5a,\
00,79,00,63,00,78,00,68,00,20,00,2f,00,4e,00,4f,00,53,00,54,00,41,00,52,00,\
54,00,55,00,50,00,20,00,22,00,25,00,31,00,22,00,20,00,25,00,32,00,20,00,25,\
00,33,00,20,00,25,00,34,00,20,00,25,00,35,00,20,00,25,00,36,00,20,00,25,00,\
37,00,20,00,25,00,38,00,20,00,25,00,39,00,00,00,00,00
From top line down:
Any .reg file has to start with the correct name of the regedit.exe you will be dealing with. In this case I am dealing with Windows 7, therefore version 5.00.
The rest of the code in this file came straight out of the registry.
Within [HKEY_CLASSES_ROOT] I scrolled down to the entry ".accde"
Right click on this and select the "Export" option from the drop down menu.
Provide the folder and file name to export to.
Now you need to do the same within [HKEY_CURRENT_USER]. Here you will need to:
Scroll to Software, then Microsoft, then Windows, then CurrentVersion, then Explorer, then FileExts, and finally .accde.
Right click, select Export, etc.
And lastly, within the [HKEY_CLASSES_ROOT] scroll to "Access.ACCDEFile.14"
Right click on this and select the "Export" option, provide the saving info and save the file.
Put these three files together, leaving out the Windows Registry Editor Version line from the second and third files.
What I did from here was to create my own suffix rather than use the Microsoft .accde. I used the initials of the company this software is being written for. In this example, I will just use my own initials, VR. Keeping the ".acc" and just changing the "de" to whatever I will be using for the new suffix in order to use my custom icon.
You do not need to stay with only two characters.
In this new .reg file, carefully work your way through the file changing the "de" (or "DE") within any accordance of "accde" (or "ACCDE") you find.
For example, one of the places you will find "ACCDE" is in the string "[HKEY_CLASSES_ROOT\Access.ACCDEFile.14" Change the "DE" to "VR" (for this example) giving you the new string "[HKEY_CLASSES_ROOT\Access.ACCVRFile.14"
When you are finished, I suggest you search for the string "accde" within the file to be sure you have changed them all to the new suffix you are going to use.
Before using this .reg file to update your registry, BACKUP YOUR REGISTRY!!!
I have created a framework which I want to use in my OS X app. Since updating to Xcode 7 on El Capitan, when I try to command-click on the import statement, Xcode goes to the following view.
How can I get Xcode to display the Swift representation properly?
I've had it happen before, and my solution was to recreate every project file which I don't want to do again.
From my experience there are two possible causes for this issue.
The first one is that your framework can't be located. To fix this you need to go to target's Build Settings and add a path to Framework Search Paths either an absolute:
/Users/{user}/path-to-framework-parent-directory
or relative to project directory:
$(PROJECT_DIR)/path-to-framework-parent-directory
Another possible cause is that the path to your framework contains a space in it. I found that it doesn't matter whether you try to escape it with backslash ../Project\ Name/frameworks or take the whole path in double-quotes "../Project Name/frameworks". The result would be that SourceKit could not load the module.
Note that $(PROJECT_DIR) could expand to a path with a space in it and it would too result in the same error. So it looks like a bug in Xcode/SourceKit (I tried the latest Xcode 7.2-beta3 and the bug is still there).
My repository was on the second hard drive /Voluems/Macintosh HD/Repos. I just renamed the hard drive to HD, so the path looks like /Volumes/HD/Repos and the problem was gone.
Max S. answer pointed me in the right direction, however I was using the 'recursive' option for my framework path.
To get things to work I had to explicitly add a path to directly the framework in question's immediate parent directoy (as oposed to just having a path to one of its higher up directories with the 'recursive' option set).
HTH
I had this problem too and the other solutions didn't work. I finally figured it out in my case:
The target name cannot have a space in it either
To rename it:
Go to your project settings
Expand the target list column on the left if not already there
Click on the relevant target once (or press Enter or Tab when having it selected) and type in the new name without the space
Weirdly, just changing the name of my folder from 'Developer' to 'Development' fixed the issue from me.
Running Product->Clean, Product->Build is what worked for me.
In my case, I have created a framework for my SDK along with podspec for making it cocoa pod.
I had the same problem when i use my SDK and it fixed when I imported Foundation API to the file where I am consuming my SDK
import Foundation
Here is another potential solution - one that worked for me:
After importing the framework I never built for simulator, only for real devices. Swift Modules were not showing up, same error. Then I built for Simulator and it suddenly worked, I could see the Swift Modules.
The reason is that when I make my framework, I have a step that copies the swift modules from the iphonesimulator build to the universal build, but does nothing with the modules from the iphoneos build. So my guess is that this is why it didn't work.
Note: once I selected simulator and built it started working all the time, regardless of the build destination.
I just switched from Access 2003 to Access 2007. In the very first "dev" copy (as I call it) pre-split, pre-front end, I need to import some data that are text files. I try to use the ribbon to do this, and after I walk through the steps I get this little pop up box that states
Microsoft Access has determined this to be a potential security risk. You shouldn't accept....
Then I Click OK to accept (open the file)... and nothing happens...no import, no file.
So I tried making a new table on import, creating a table in access then importing, coverting the data file to xls & web before importing, using a completely different data file. Nothing seems to change the outcome of Access not firing off some type of import event (which I think is supposed to be a wizard or something??)
So does anyone have any ideas what is going on with this?
I would just code the data import but I don't know how (without using the wizard to at least create the specification).
Is the folder where the database resides configured as a Trusted Location? I know VBA code won't run if it's not. I wasn't aware those types of restrictions extended to file import from the Ribbon. However, your error message sounds similar to a Trusted Location issue, so it may be worth checking.
See Create, remove, or change a trusted location for your files for detailed instructions on managing Trusted Locations.
Access was formerly very fussy about extensions and would stop working if, for example, a text file did not have an expected extension. It used to be necessary to modify the registry to get around this. It seems that the problem may still exist.