Hoping for some help here, as I am tearing my hair out!I'm using Visual Studio 2010.
I have an MFC C++ application to deploy. I have a config.ini file that I'd like referenced when the exe starts. At the moment the user cannot double click on a *.myfile and it open, because the application does not "start in" the application folder (where I am installing the ini file to), and so cannot find the ini. I've tried the following
I tried finding info on setting the "start in" folder for the &Open action, but cannot find anything.
I can't find any info on setting a registry value of the ini file at installation, since this would be a relative reference depending on the user's choice, and so this doesn't apply.
It is unmanaged so the C++/CLI app.config solution doesn't apply.
Using the Application Data folder, but this gives me the wrong path - I'm using Windows 7, this is probably why, but I want my deployment to work on Windows XP ++.
Reading the app path at start up (from here) (put this in CMyApp::InitInstance().
Code:
CString strPath;
TCHAR* pstrExePath = strPath.GetBuffer (MAX_PATH);
::GetModuleFileName (0, pstrExePath, MAX_PATH);
strPath.ReleaseBuffer();
int pos = strPath.ReverseFind('\\');
strPath = strPath.Left(pos);
strPath += "\\config.ini";
This is the closest, but in debug mode there is a weird "\.\" in the path invalidating it. I could use a #ifdebug but this is messy surely?
Really appreciate any help - thanks!
EDIT:
Using this:
TCHAR szPath[MAX_PATH];
if (SUCCEEDED(SHGetFolderPath(NULL, CSIDL_COMMON_APPDATA, NULL, 0, szPath)))
{
MessageBox(NULL,szPath, "MyApp", MB_OK|MB_ICONWARNING);
}
I get: "C:\ProgramData" as the szPath. Maybe this is right for debug mode? Or the development machine?
Thanks for all the input and prompts. It helped me get to this solution. Hopefully it helps some others to have the info in one place. This solution is a very simple one and probably not for full commercial deployment!
In VS2010 in the FileSystem (Setup)
put the config file in the User's
Application Data Folder \ Productname
Set InstallAllUsers to false, so that
you don't need conditionals on where
your config file is located, based on
the user's installation choice
In the InitInstance() function add
something like the following:
[listbreaker]
TCHAR szPath[MAX_PATH] = {0};
if(SUCCEEDED(SHGetFolderPath(NULL, CSIDL_APPDATA|CSIDL_FLAG_CREATE,NULL,SHGFP_TYPE_CURRENT,szPath)))
{
PathAppend(szPath, "\\MyApp\\");
// Can check to create the directory here
//if (!PathFileExists(szPath))
// CreateDirectory(szPath, NULL);
PathAppend(szPath, TEXT("MyApp.ini"));
// can check to create default file here if removed by user
//if (!PathFileExists(szPath))
//g_ConfigData.write_default() // be nice if it could write itself
//MessageBox(NULL,szPath, "MyApp", MB_OK|MB_ICONWARNING);
}
if (!g_ConfigData.ReadData( szPath ) )
MessageBox(NULL,"Configuration file cannot be read", "MyApp", MB_OK|MB_ICONWARNING);
Some useful links that really helped me on this are:
How to get the %AppData% folder in C?
http://msdn.microsoft.com/en-us/library/206sadcd.aspx
http://www.vbforums.com/showthread.php?t=491920
http://jedej.com/2011/02/22/constant-special-item-id-list-windows-special-folders/
http://www.codeproject.com/Messages/2623871/using-CSIDL_APPDATA-or-CSIDL_COMMON_APPDATA.aspx
I'd appreciate any further help on this, as I'm sure there are more refined and flexible solutions (e.g. handling "All Users" choice on installation).
Related
I am porting existing C++ app (game engine) to support Windows Store 8 and Windows Phone 8.1 Apps and I am having problem with the _wfindfirst function. On regular Win32 it returns a handle to the first found element matching the pattern. we use it mainly to get information about directory or file.
The function I am trying to get working on WindowsPhone/Windows Store App is like this:
bool sys_GetFileInfo(const std::string& path, FileInfo* info) {
...
long handle = _wfindfirst(p.c_str(), &item); // path gets converted to wstring
if (handle != -1L) {
info->size = (item.attrib & _A_SUBDIR) ? -1 : item.size;
info->modifiedAt = item.time_write;
_findclose(handle);
return true;
}
...
}
So it was used to retrieve file size and modification date (and if it happened to be directory the size was set to -1)
The first usage was to get info about working directory of an exe so in case of the WinRT/WP/WS I am using it with the path provided by
std::wstring wpath = Windows::ApplicationModel::Package::Current->InstalledLocation->Path->Data();
The path in this case is:
wpath = L"C:\\foo\\winrt\\winrt\\Debug\\foo_winrt.Windows\\AppX"
The problem is that it always returns -1, when I check the error string with GetLastError() code I get the access denied error. This is confusing as in my understanding application should have read access to this location so _wfindfirst is a read operation right? On Win32 it worked given a regular directory path.
Why this function fails? Is there any other viable option to achieve the same result for WinRT ?
If still relevant, it seems you are not able to use standard C++ functions to access file system outside your app's sandbox (installed location and local app folder). They will fail with Access denied error. I think they behave pretty much the way CreateFile2 behaves, and according to MSDN:
When called from a Windows Store app, CreateFile2 is simplified. You can open only files or directories inside the ApplicationData.LocalFolder or Package.InstalledLocation directories.
In your case, as I can see, the installed location points to a development folder, and I think the system decides that this location isn't inside your app's sandbox.
Consider using Windows Runtime APIs from Windows.Storage namespace. These APIs can be used to access any file in the file system.
I've written a very simple service application based on this code example.
The application as part of its normal running assumes there exists a file in the directory it is found, or in its execution path.
When I 'install' the service and then subsequently 'start' the service from the service manager in control panel. The application fails because it can't find the file to open and read from (even though the file is in the same directory as the installed executable).
My question is when a windows service is run, which is the expected running path supposed to be?
When calling 'CreateService' there only seems to be a path parameter for the binary, not for execution. Is there someway to indicate where the binary should be executed from?
I've tried this on windows vista and windows 7. Getting the same issues.
Since Windows services are run from a different context than normal user-mode applications, it's best if you don't make any assumptions about working directories or relative paths. Aside from differences in working directories, a service could run using a completely different set of permissions, etc.
Using an absolute path to the file that your service needs should avoid this problem entirely. Absolute paths will be interpreted the same regardless of the working directory, so this should make the working directory of your service irrelevant. There are several ways to go about this:
Hard-code the absolute path - This is perhaps the easiest way to avoid the problem, however it's also the least flexible. This method is probably fine for basic development and testing work, but you probably want something a bit more sophisticated before other people start using your program.
Store the absolute path in an environment variable - This gives you an extra layer of flexibility since the path can now be set to any arbitrary value and changed as needed. Since a service can run as a different user with a different set of environment variables, there are still some gotchas with this approach.
Store an absolute path in the registry - This is probably the most fool-proof method. Retrieving the path from the registry will give you the same result for all user accounts, plus this is relatively easy to set up at install time.
By default, the current directory for your Windows service is the System32 folder.
A promising solution is creating an environment variable that keeps the full path of your input location and retrieving the path from this variable at runtime.
If you use the same path as binary, you could just read binary path and modify it accordingly. But this is rather quick-fix rather than designed-solution. If I were you, I would either create system-wide environment variable and store value there, or (even better) use windows registry to store service configuration.
Note:
You will need to add Yourself some privileges using AdjustTokenPrivileges function, you can see an example here in ModifyPrivilege function.
Also be sure to use HKEY_LOCAL_MACHINE and not HKEY_CURRENT_USER. Services ar running under different user account so it's HKCU's will be different than what you can see in your registry editor.
Today I solved this problem as it was needed for some software I was developing.
As people above have said; you can hardcode the directory to a specific file - but that would mean whatever config files are needed to load would have to be placed there.
For me, this service was being installed on > 50,000 computers.
We designed it to load from directory in which the service executable is running from.
Now, this is easy enough to set up and achieve as a non-system process (I did most of my testing as a non-system process). But the thing is that the system wrapper that you used (and I used as well) uses Unicode formatting (and depends on it) so traditional ways of doing it doesn't work as well.
Commented parts of the code should explain this. There are some redundancies, I know, but I just wanted a working version when I wrote this.
Fortunately, you can just use GetModuleFileNameA to process it in ASCII format
The code I used is:
char buffer[MAX_PATH]; // create buffer
DWORD size = GetModuleFileNameA(NULL, buffer, MAX_PATH); // Get file path in ASCII
std::string configLoc; // make string
for (int i = 0; i < strlen(buffer); i++) // iterate through characters of buffer
{
if (buffer[i] == '\\') // if buffer has a '\' in it, replace with doubles
{
configLoc = configLoc + "\\\\"; // doubles needed for parsing. 4 = 2(str)
}
else
{
configLoc = configLoc + buffer[i]; // else just add char as normal
}
}
// Complete location
configLoc = configLoc.substr(0, configLoc.length() - 17); //cut the .exe off the end
//(change this to fit needs)
configLoc += "\\\\login.cfg"; // add config file to end of string
From here on, you can simple parse configLoc into a new ifsteam - and then process the contents.
Use this function to adjust the working directory of the service to be the same as the working directory of the exe it's running.
void AdjustCurrentWorkingDir() {
TCHAR szBuff[1024];
DWORD dwRet = 0;
dwRet = GetModuleFileName(NULL, szBuff, 1024); //gets path of exe
if (dwRet != 0 && GetLastError() != ERROR_INSUFFICIENT_BUFFER) {
*(_tcsrchr(szBuff, '\\') + 1) = 0; //get parent directory of exe
if (SetCurrentDirectory(szBuff) == 0) {
//Error
}
}
}
I am attempting to open a .chm file(A windows help file) at a specific page/topic by using a system call in C++.
I can successfully open the .chm file to the start page through the following code, but how can I open a .chm file to a specific page/topic inside the help file?
system("start c:/help/myhelp.chm");
PS: I know system is evil/discouraged but the system part is not really relevant its the command line arguments I pass with the .chm file(that will specify what page I want to open) that I am trying to determine.
Ok the arguments are like so:
system(" /Q /E:ON /C HH.EXE ms-its:myChm.chm::myPageName.htm");
There is an API in the Windows SDK called HtmlHelp in the HtmlHelp.h file. You can call like so:
HtmlHelp(GetDesktopWindow(), L"C:\\helpfile\\::/helptopic.html", HH_DISPLAY_TOPIC, NULL);
The Microsoft Docs - HtmlHelpA function provides more information about the function. HtmlHelp() will normally resolve to HtmlHelpA() or HtmlHelpW() depending on whether Unicode compiler option is set or not.
See as well Microsoft Docs - HTML Help API Overview.
Another option - use ShellExecute. The Microsoft help is not easy to use. This approach is much easier and in line with your question. Here is a quick routine to open a help file and pass an ID number. I have just set up some simple char’s so you can see what is going on:
void DisplayHelpTopic(int Topic)
{
// The .chm file usually has the same name as the application - if you don’t want to hardcode it...
char *CmndLine = GetCommandLine(); // Gets the command the program started with.
char Dir[255];
GetCurrentDirectory (255, Dir);
char str1[75] = "\0"; // Work string
strncat(str1, CmndLine, (strstr(CmndLine, ".exe") - CmndLine)); // Pull out the first parameter in the command line (should be the executable name) w/out the .exe
char AppName[50] = "\0";
strcpy(AppName, strrchr(str1, '\\')); // Get just the name of the executable, keeping the '\' in front for later when it is appended to the directory
char parms[300];
// Build the parameter string which includes the topic number and the fully qualified .chm application name
sprintf(parms,_T("-mapid %d ms-its:%s%s.chm"), Topic, Dir, AppName);
// Shell out, using My Window handle, specifying the Microsoft help utility, hh.exe, as the 'noun' and passing the parameter string we build above
// NOTE: The full command string will look like this:
// hh.exe -mapid 0 ms-its:C:\\Programs\\Application\\HelpFile.chm
HINSTANCE retval = ShellExecute(MyHndl, _T("open"), _T("hh.exe"), parms, NULL, SW_SHOW);
}
The topics are numbered within your .chm file. I set up a #define for each topic so if I had to change the .chm file I could just change the include file to match and not have to worry about searching through the code for hardcoded values.
I am using Windows 7 and I have to run one program in that windows but that program working in Windows XP. This is a Visual C++ program and I am using Visual Studio 2008 for this. When I am running my application, it does not throw any errors, but it does not create a directory in "c:\program files\". So can anyone help me to create directory and exe file?
This is the code I am using:
char szAppPath[MAX_PATH];
char szFileName[MAX_PATH];
DWORD dwResult;
WIN32_FIND_DATA FindFileData;
HANDLE hFind;
dwResult = ExpandEnvironmentStrings( NULL, szAppPath, MAX_PATH); // "%ProgramFiles%"
// do same for NSim directory
strcat(szAppPath,"\\NSim");
hFind = FindFirstFile(szAppPath, &FindFileData);
if (hFind == INVALID_HANDLE_VALUE)
{
//Directory Does't Exists create New
if(!CreateDirectory(szAppPath,NULL)) //Throw Error
{
MessageBox("Unable to Create N-SIM directory","NSim Installer");
return ;
}
}
else
{
//check if is directory or not
if(!(FindFileData.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY))
{
MessageBox("Can't Create N-SIM directory\n Another file with same name exists","NSim Installer");
return ;
}
FindClose(hFind);
}
//***************************************N-SIM Application****************************
strcpy(szFileName, szAppPath);
HRSRC hRes;
if( bRegister == FALSE)
{
strcat(szFileName,"\\NSim.exe"); //make same name of the Client & Server in program file
hRes = FindResource(NULL, MAKEINTRESOURCE(IDR_LANSIMSERVER),RT_RCDATA);
if(flagUpgrade ==0)
{
CString trial = installationDate(); //----- Detemine Expiry Date -----
setRegistry(trial);
}
}
It's a file permissions issue, plain and simple. Programs can't just go rooting around system directories in Windows 7. That's why it works "properly" in Windows XP, but not in newer versions.
I can't tell for sure, but it looks like you're trying to write an installer. If so, why are you reinventing the wheel? There are tons of great setup utilities available—Visual Studio provides a setup project that you can customize to your needs, or look into Inno Setup, my personal favorite. A Google search will turn up plenty of other options that have already solved this problem for you, and innumerable others.
If this isn't an installer, and you're just trying to store application and/or user data in the Program Files folder, I highly recommend that you look elsewhere. You weren't supposed to shove data into the app folder under earlier versions of Windows, and Windows 7 just cuts you off at the knees if you do this. Your best bet is to follow the recommendations that existed from the beginning: Investigate the user and common Application Data folders carefully. Use the SHGetKnownFolderPath function to retrieve the full path to a known folder using its KNOWNFOLDERID. A couple of suggestions:
FOLDERID_ProgramData (a shared program data directory for all users)
FOLDERID_LocalAppData (a per-user program data directory, non-roaming)
FOLDERID_RoamingAppData (a per-user program data directory, roaming)
Alternatively, you can try running the application as an Administrator. You might want to look into creating a manifest that indicates the application requires administrator-level permissions to execute.
[edit] I edited the code in the question for readability and removed the commented out code (to see the wood for the trees). It is now obvious that nothing initialises szAppPath before calling strcat(), and calling ExpandEnvironmentStrings with NULL as the first argument is undefined (and certainly useless). Calling strcat() on an unitialised string is not likely to have the desired result. This may be an artefact of not posting the real code, or even of other peoples edits (including mine).
CreateDirectory sets the system error code on error; if you want to know what went wrong, check it! Any answer you get here will be an educated guess.
if(!CreateDirectory(szAppPath,NULL)) //Throw Error
{
DWORD errorcode = GetLastError();
LPVOID lpMsgBuf;
FormatMessage(FORMAT_MESSAGE_ALLOCATE_BUFFER | FORMAT_MESSAGE_FROM_SYSTEM | FORMAT_MESSAGE_IGNORE_INSERTS,
NULL, errorcode, MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT), (LPTSTR)&lpMsgBuf, 0, NULL );
MessageBox(NULL, (LPCTSTR)lpMsgBuf, TEXT("Error"), MB_OK);
return ;
}
If you just want to get the error code and look it up manually, then a complete directory of codes is available on MSDN, here, I would guess that ERROR_ACCESS_DENIED
(5) is most probable. A more elaborate example of error code display is given here.
windows7?
Ok, the problem is not with your program. Its with the file system permissions in Windows 7. User programs cannot create files there.
I think the problem is lack of privileges. You can debug your project to see whether the CreateDirectory function sets an error as ERROR_ACCESS_DENIED, if it does, you should make your program run with an administrator privilege. Add manifest in your project to do so.
It is intended to protect your computer against attack. Well maybe. Or Microsoft deciding to tell you what you are and not allowed to do on your own computer.
In any case you can change your UAC settings if you really have to write there in that way although that obviously exposes you to risk.
Otherwise play nice and do things the Microsoft way, using a proper installer.
I have a program that accesses a database using SQLite. When I open a OpenFileDialog or a SaveFileDialog before I do the SQLite call:
result = sqlite3_prepare_v2(databaseConnection,converted,10000,&stmt,&strptr);
and choose "Cancel", everything works okay (result == SQLITE_OK) but when I choose "Open", even if I don't do anything with the dialog's return file, it breaks (result == SQLITE_ERROR). Do you have any idea why this might be happening?
Thanks so much for your time!
EDIT: Here is the code I am using:
OpenFileDialog^ openFileDialog1 = gcnew OpenFileDialog;
openFileDialog1->ShowDialog();
sqlite3_stmt * stmt;
const char * strptr;
sqlite3 * databaseConnection;
int result = sqlite3_open("virtualpatient_chat.db", &databaseConnection);
if (result != SQLITE_OK) return;
result = sqlite3_prepare_v2(databaseConnection,"SELECT * from mappings;",10000,&stmt,&strptr);
if (result != SQLITE_OK) return;
Strangely, it won't work in my current project but I copied and pasted it into a brand new project and the error doesn't repeat. Now I'm just trying to figure out what the problem in my surrounding code could be...
There's no hope to diagnose the source of the problem from the question. Just some pointers.
Start by setting the OpenFileDialog's RestoreDirectory to True. This ensures that clicking Open doesn't change the program's working directory. If that works then there's a rather mysterious dependency on the current directory in the query.
Next thing to worry about are the DLLs that are getting loaded when you use the dialog. Project + Properties, Debug tab, tick "Enable unmanaged code debugging". Check out the Output window when you open the dialog, it shows a list of the DLLs getting injected. These are shell extensions, one of them might conflict with SQLite. No real clue what such an extension might do beyond maybe corrupting memory or using SQLite itself. You can temporarily disable shell extension with the SysInternals' AutoRuns utility. Start with the ones not written by Microsoft.
I finally figured out how to fix it. Under the Properties for my dialog box, I had to set the RestoreDirectory property to true. I'm not quite sure how that fixed it unless somehow by changing the directory it made SQLite not be able to find my database file.
Thanks for your help!