Using MySQL in VC++ - mysql

I am trying to connect to MySQL using C++. The IDE that I am using is Visual C++ 2010. I followed the steps on the MySQL dev page (http://dev.mysql.com/tech-resources/articles/mysql-connector-cpp.html). I followed the steps exactly as given although i used a different OS(Windows). I get many linker errors in the process, which I am finding difficult to debug. Could somebody direct me towards a better or a simpler approach to acces MySQL using C++.
P.S. I have downloaded mysqlconnector for C++.

You could try mysql++, but you'll encounter the same linker errors I bet.
Have you set the include path (C:...\MySQL Server 5.1\include) and the library path (C:...\MySQL Server 5.1\lib\debug) ? In VC2010 to set global settings you have to :
VS2010 introduces the user settings
file
(Microsoft.cpp..users.props)
to control global settings including
Global search path. These files are
located at
$(USERPROFILE)\appdata\local\microsoft\msbuild\v4.0
directory.
The issue you are seeing is a bug in
the UI. To make it possible to change
the ordering of these read-only
directories, here is the workaround
that you can apply:
open up the property manager,
right click on the .user.props file to bring up the property page
open up VC++ Directories -> Include Directories, add new paths after
$(IncludePath)
Click on the "Edit" dropdown on VC++ Directories -> Include
Directories property, the user
directories as well as the inherited
values will show up in the upper pane
you can move the directory orders as you wish and save.
http://connect.microsoft.com/VisualStudio/feedback/details/550946/vs-2010-how-to-change-vc-directories-inherited-values-read-only

Related

How can I set the output path of a vc++ project different than its dependencies (nuget)?

Premise
I have a Visual Studio 2015 solution containing different VC++ projects.
Some of them (EXE and some DLLs) have the $OutDir set to default "$(SolutionDir)$(Configuration)\" (i.e. "C:\MySolution\Debug\").
For some other projects (DLLs), I need to change the output path to a sub-directory of the "default" $OutDir (i.e. "C:\MySolution\Debug\Pieces\".
Example directory tree:
C:\MySolution\Debug\
MyProgram.exe
Dependency.dll
.\Pieces\
MyPiece1.dll
MyPiece2.dll
Constraints
the "Pieces" DLLs depends on a third-party Dependency.dll (through NuGet package), which I cannot modify.
Usual solution
The usual way for this is to change the $OutDir project setting for "pieces" projects, but this will also force their dependencies to be output in the same sub-dir.
This is not wanted and also created problems in debugging and packaging of the entire solution.
What I tried so far
I tried to:
1. keep the $OutDir the same for all projects
2. change the "pieces" $TargetName to "Pieces\$(ProjectName)"
This seems to work (both MyPiece*.dlland Dependency.dll are correctly placed and debugging is fine), but unfortunately Visual Studio generates the following warning:
warning MSB8012: TargetName(Pieces\MyPiece1.dll) does not match the Linker's OutputFile property value (MyPiece1). This may cause your project to build incorrectly. To correct this, please make sure that $(OutDir), $(TargetName) and $(TargetExt) property values match the value specified in %(Link.OutputFile).
This warning is somewhat confusing, because the %Link.OutputFile in the project settings looks correct:
$(OutDir)$(TargetName)$(TargetExt) => C:\MySolution\Debug\Pieces\MyPiece1.dll
Question
What is the correct approach to solve my problem?
How do I force Visual Studio to output some of the generated files in a different path, but still having their Nuget dependencies in the "default" $OutDir?
I've searched the web and StackOverflow already, but I can't find a suitable answer.
Note: my problem is not related to upgrading a pre-VS2010 solution (as in Microsoft official notes on warning MSB8012 after solution upgrade and asked on StackOverflow).

Is it possible to change an .accde file icon to a custom image?

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!!!

Error accessing WinRT sensors in C++ desktop application

I am trying to access the WinRT sensors from a Win32 desktop application using C++/CX as mentioned here: https://software.intel.com/en-us/articles/using-winrt-apis-from-desktop-applications
When I include the C++/CX header file it causes an error when building the Win32 project.
Exact error text: "error C1190: managed targeted code requires a '/clr' option."
Since I am not using /clr code at all, this is a confusing error.
Any suggestions? Please educate me if there is a better way to do this.
The error you are getting is because you are compiling some files without /ZW option for compiler. Since you are able compile at least some files with WinRT extensions, but not others, your project configuration is inconsistent.
The option /ZW (enable WinRT extensions) has to be configured on the level of project (and not on the level of individual files). There are two ways to ensure your settings are consistent. First method is through UI in Visual Studio -- you have to go through all platforms/configurations on the project and ensure /ZW is enabled, then got through all indivudual .cpp files, and ensure they don't override project level settings. This is tedious and error prone. The easier method is to open .vcxproj in notepad and do the following:
Add this section at the beginnig of the file, under root Project node:
<ItemDefinitionGroup>
<ClCompile>
<CompileAsWinRT>true</CompileAsWinRT>
</ClCompile>
</ItemDefinitionGroup>
Search and remove any other places where <CompileAsWinRT> is defined.

ReSharper: Namespace does not correspond to file location

I renamed a folder and updated my namespace declarations, but ReSharper 6 claims that the namespace should be a reflection of how it was before the rename. Where is it storing the file location data?
Check to make sure your assembly name matches your new namespace. If you've changed your folder structure to match your new namespace, you may still see the ReSharper alert until you update the project properties.
As delliottg's comment says, in Visual Studio, go to
Project > [project name] Properties > Application
and change "Assembly name" as well as "Default namespace".
I also had this problem with a folder/namespace and none of the above steps fixed it.
In my case I had to do this in Visual Studio:
Right-click the "problem" folder in the solution explorer to open the properties
Ensure the "Namespace Provider" is set to true
This fixed the ReSharper issue for me and I was able to adjust namespaces as normal.
Root namespace is needed to be changed as following.
I use Resharper 2019.3.2 in VS 2019 vs 16.5.2 and I had similar issues.
When developing, I first work out my namespace hierarchy in a single project, then split the project in seperate class libraries. In the first stage, it is convenient to always let the subdirectory correspond to the namespace.
For example, my prototype MeshTools.dll project currently contains:
Meshtools ........................ 3 cs-files in \MeshTools
MeshTools.HeightField .......... 2 cs-files in \MeshTools\HeightField
MeshTools.VectorTools .......... 3 cs-files in \MeshTools\VectorTools
The above answers all assume one single namespace per project. Renaming directories manually may confuse Resharper and that can be repaired by setting the default assembly in the .csproj file to the proper namespace. Thanks for the tip.
However in my case, I have several namespaces in a single project, with each namespace in a Solution directory corresponding to a real directory. Setting the default assembly "Meshtools" does not affect ReSharper behaviour for HeightField and VectorTools, when things have gone wrong with the renaming.
I googled this issue and came by https://www.jetbrains.com/help/resharper/Refactorings__Adjust_Namespaces.html#
It turns out there is a right-click option on a Solution Directory -> Properties. You will find an option to decide, if the Solution Directory is a NameSpace provider or not. When something has gone wrong, Visual studio will reset the field to False. Set it back to True and Resharper will correctly refactor namespace or file location when needed..
If you're using JetBrains Rider, go to the Solution Explorer and right click on the csproj file, then properties in the context menu. In my case the Assembly Name was already updated but "Root Namespace" wasn't, updating Root Namespace allowed JetBrains to automatically update all namespaces.

Associate a help file with a library in the VBA object browser

I have a reference to the Microsoft Scripting Runtime (scrrun.dll) in one of my Access projects. If I open the object browser in VBA (by pressing F2) and choose 'Scripting' from the library dropdown it shows me all of the properties, functions, etc. for the Scripting library. If I choose one of these functions and then click on the help button (with the yellow question mark) it opens a help window with the title of 'Microsoft Visual Basic Help.'
It acts like it is unable to find the help file for this library. I can manually find the help file on my computer at the following location: "C:\Program Files (x86)\Common Files\microsoft shared\VBA\VBA6\1033\VBLR6.CHM". (Note: I have 64-bit Win 7, thus the '(x86)' in the Program Files folder name.)
I tried copying the help file to the following locations with no luck:
"C:\Windows\Help\VBLR6.CHM"
"C:\Windows\SysWOW64\VBLR6.CHM" (I believe SysWOW64 folder is the Win7 64-bit equivalent of C:\Windows\System32)
I have had this same problem with other referenced libraries as well, so I'm looking for some kind of generic solution. I'm hoping there is some way to specify a location for the help file of a particular reference, or something else along those lines.
Copy VBLR6.CHM to "C:\Program Files (x86)\Microsoft Office\Office10\1033\VBENLR98.CHM"
That's the short answer for this specific case...here's how to get there which may be useful for getting other help files associated:
Download Process Monitor (currently hosted here: http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx or do a Google search for Process Monitor)
Run Process Monitor with the following filter: 'Process Name' 'is' MSOHelp.exe 'include'
Open object browser in VBA
Choose the library (Scripting in this case)
Choose any function, property, or event in the library and click on the yellow question mark (this should open an empty window with the title Microsoft Visual Basic Help)
Go back to Process Monitor and scroll all the way to the bottom of the list; make sure the Path and Result columns are displayed
There should be dozens of 'PATH NOT FOUND' and 'NAME NOT FOUND' Results in the list. For each one of these results, there should be a corresponding Path where MSOHelp was looking for the help file. Choose any one of these and create a file with that path name. I chose to create a copy of the help file from its original location to the new spot and rename it to match what MSOHelp was looking for.
My best guess is that the scrrun.dll contains the name of the help file and over the years the dll stayed the same but the help file was renamed, modified, etc.