C++ CreateDirectory() not working with APPDATA - c++

I want to create a directory inside the %APPDATA% folder. I am using CreateDirectory() for this and it doesn't work. I debugged the code and it seems like the path is correct, but I can't see a new directory in my the APPDATA.
My code for creating dit in appdata:
void setAppDataDir(std::string name)
{
char* path;
size_t len;
_dupenv_s(&path, &len, "APPDATA");
AppDataPath = path;
AppDataPath += "\\"+name;
createDir(this->AppDataPath.c_str());
}
void createDir(const char* path)
{
assert(CreateDirectory((PCWSTR)path, NULL) || ERROR_ALREADY_EXISTS == GetLastError()); // no exception here
}
This is how I call the function:
setAppDataDir("thisistest");
I use Visual Studio 2019 and the debugger tells me, that path is
C:\\Users\\Micha\AppData\Roaming\\thisistest
What am I doing wrong?

CreateDirectory() is a macro that expands to CreateDirectoryW() in your case, which requires strings in UTF-16LE encoding (wchar_t*). You are casting the const char* path param to PCWSTR (const wchar_t*):
CreateDirectory((PCWSTR)path, NULL) ...
But you are not converting that string into a UTF-16LE string.
So, you need to convert your path into a wchar_t* string. There are some methods to do it, see Convert char * to LPWSTR.

The problem was the way I was giving path to CreateDirectory(). As #RemyLebeau pointed out, I should have used CreateDirectoryA(). This change solved the issue.

Related

Using std::filesystem output as LPCWSTR

I'm making a program which recursively lists all files in a certain directory and uploads each file separately to an FTP server using WinINet.
The problem I'm encountering is using filesystem::path::filename in the FtpPutFile() function because a LPCWSTR is needed.
Whats the best and easiest way to convert it (or somehow use it as is)?
std::string path = "C:\\Programs";
for (const auto & entry : std::experimental::filesystem::recursive_directory_iterator(path))
FtpPutFile(hIConnect, entry.path().filename(), entry.path().filename(), FTP_TRANSFER_TYPE_BINARY, 0);
The error I get is:
no suitable conversion function from "const std::experimental::filesystem::v1::path" to "LPCWSTR" exists
EDIT: Here is a solution that worked for me, by following Lightness solution:
std::string path = "C:\\Programs";
for (const auto & entry : std::experimental::filesystem::recursive_directory_iterator(path))
FtpPutFile(hIConnect, entry.path().wstring().c_str(), entry.path().filename().wstring().c_str(), FTP_TRANSFER_TYPE_BINARY, 0);
LPCWSTR is Microsoft's obfuscation of the const wchar_t* type, and filesystem paths conveniently have a wstring() member function. As you may recall, C++ strings give you access to their character buffer, too, via c_str().
So, entry.path().filename().wstring().c_str() is a LPCWSTR you can use (ugh!). Be careful to use that immediately, or store the result of wstring() somewhere for as long as you need the LPCWSTR to survive, because wstring() returns by value and you don't want a dangling pointer.
// Untested, but a logical adaptation of your code
const std::string path = "C:\\Programs";
std::experimental::filesystem::recursive_directory_iterator it(path);
for (const auto& entry : it)
{
const std::wstring filename = entry.path().filename().wstring();
FtpPutFile(
hIConnect,
filename.c_str(),
filename.c_str(),
FTP_TRANSFER_TYPE_BINARY,
0
);
}

Is this correct point to free char*

I have this code
{
char *filename = createFilename(file, extension);
...
...
delete[] filename;
}
inline char *DataSet::createFilename(LPCSTR file, LPCSTR extension)
{
char *path = new char[strlen(file) + strlen(extension) + 1];
strcpy(path, file);
strcat(path, extension);
return path;
}
Am I right to delete "filename" in the main function? I get ERROR_INVALID_NAME on delete. I have checked the filename and that is correct.
I know I should be using std::string but this is existing code. Please help
If it's existing code and you can't change createFilename to return a std::string, then how about changing the call site to use std::unique_ptr. It is specialized for arrays and would be a much safer bet than doing delete on your own. See this answer.
An error of type ERROR_INVALID_NAME usually occurs when the directory name, file name or volume label is incorrect. On Windows, you might have to take care of escape sequences. For example, if the path to the file is C:\Folder\File.ext you should use the string C:\\Folder\\File.ext. In addition, some characters may not be accepted by the API you're using even though Windows allows them to be used in file and directory names. See this.

Problems transforming QString to _bstr_t

I am trying to transform a QString to _bstr_t type as follows:
QString mFilename="C:/agatebo/amahoro.doc";
QByteArray srcBa1 = mFilename.toLocal8Bit();
const char *srcString1 = srcBa1.data();
CString myStringSrc(srcString1,srcBa1.size());
BSTR bstrUser = myStringSrc.AllocSysString();
_bstr_t user(bstrUser,TRUE);
but when I pass the _bstr_t I get to this function:
pdfObject->cPrintFile(user);
PDFCreator ,a program whose COM interface I am using just crashes .I suspect this has something to do with unicode but can’t figure out what yet.I should mention that when I directly pass a path to the file like this:
pdfObject->cPrintFile(L"c:\\agatebo\\amahoro.doc");
all is ok ,I simply want to be able to use QStrings that come from other modules of my Qt application.I am compiling with Qt 4.8 msvc2010 if this matters. I would appreciate any
You should be able to use QString.utf16()
void ProcedureThatTakesWChar(const wchar_t* s) {
std::wcout<<s<<L'\n';
}
void ProcedureThatTakesBstr(const BSTR& s) {
std::wcout<<s<<L'\n';
}
int main(int argc, char *argv[]) {
QString qs("this is a qstring");
//pass directly
ProcedureThatTakesWChar(qs.utf16());
//if you really want to use a _b_str initialise it with .utf16()
//_b_str will handle SysAllocString and SysFreeString. QString
//does not have to stay in scope.
{
_bstr_t bs(qs.utf16());
ProcedureThatTakesBstr(bs);
}
return 0;
}
Since you're on Windows and the method call works when you pass in a wide string, that means you're compiling in Unicode mode. This means that TCHAR,_bstr_t etc. are typedefed to wchar_t. You can learn more about Unicode support in Windows here.
The good news is that QString and Microsoft's Unicode implementation both use the same character encoding, UTF-16.
To get the raw QString data you simply call QString's utf16() method. This returns a pointer to an array of null-terminated unsigned shorts -- the same type as wchar_t on Windows!
So in all you should have to do here is this:
pdfObject->cPrintFile(mFilename.utf16());

appending to a string does not change string value

I'm trying to learn c++ for a project and I'm having a bit of a problem with string concatenation.
My application consists of the application itself and a statically linked library project.
In the library I've defined a type representing a path on the file system, acting as a wrapper around a std::string path literal.
I've defined a function to concatenate the parent folder's path with the (user supplied) name of the file/folder itself, adding in path separators as needed.
The function code looks like this:
std::string normalize(std::string parentPath, const std::string& name) {
if (name.empty()) {
return parentPath;
} else {
parentPath.reserve(parentPath.length()+name.length()+1);
if (*name.begin() != Path::SEGMENT_SEPARATOR) {
parentPath.append(1,Path::SEGMENT_SEPARATOR);
}
if(*name.rbegin() != Path::SEGMENT_SEPARATOR){
parentPath.append(name);
}else{
parentPath.append(name.begin(), --name.end());
}
return parentPath;
}
}
(Path::SEGMENT_SEPARATOR is a const char '/')
The problem is this: every call to string::append does not seem to do anything.
I debugged the function with gdb and the content of parentPath does not change.
I checked the user input, looking for '/0' or other invalid characters in the input ("name"), but did not find anything wrong with it.
When I moved the exact same function to the application project (out of the library project), it did work as expected (with the same input).
Both projects are compiled using the same toolset (GCC 4.8.1 and are using the C++11 dialect) and the same compiler parameters (all warnings on, no warnings received in code).
Is there anything in my code which could break string::append in this fashion ?
EDIT: the function is called from:
Path::Path(const Path& parent, const std::string& name) : path_(normalize(parent.path_, name)) { }
Path::Path(const Path& parent, const char* name) : Path(parent, std::string(name)) {}
Which in turn is called from(header file):
extern const IO::Path CONFIG_PATH;
extern const IO::Path LANGUAGES_PATH;
With definition in cpp file:
const IO::Path Game::CONFIG_PATH{"conf"};
const IO::Path Game::LOG_PATH{CONFIG_PATH,"log"};
Inspection of the LOG_PATH object shows its 'path_' member value as just "conf" instead of "conf/log" as expected.
Can I be sure CONFIG_PATH is initialized before LOG_PATH, can this be the problem?
EDIT:
I read up the standard and it seems you can't rely on any initialization order for globals.
This means the declarations of CONFIG_PATH and LOG_PATH are obviously errors and I should probably wrap them into a function call like this:
const IO::Path &getConfigPath(){
static IO::Path config{"conf"};
return config;
};
Can this be why the string appending fails ?
Ignoring the reason of your problem, I strongly suggest you to use this simple version:
std::string normalize(std::string parentPath, const std::string& name)
{
if (name.empty())
return parentPath;
else
{
if (name.front() != Path::SEGMENT_SEPARATOR)
parentPath += Path::SEGMENT_SEPARATOR;
if(name.back() != Path::SEGMENT_SEPARATOR)
parentPath += name;
else
parentPath.append(name.begin(), name.end()-1);
return parentPath;
}
}
You may use
string str1, str2, strFinal;
strFinal = str1 + "some static string" + str2;
Which I think you should
Just for your reference:
std::string normalize(std::string parentPath, const std::string& name)
{
if (name.empty())
return parentPath;
else
{
if (name[0] != '/')
parentPath += '/';
if(name[name.length()-1] != '/')
parentPath += name;
else
parentPath.append(name.begin(), name.end()-1);
return parentPath;
}
}
Here's an SSCCE demonstrating that your function works correctly. Problem is in code that you are not showing us.
The problem is almost certainly some configuration issue (mismatch in compiler options, linker options or preprocessor defs between the two projects) as it does not occur when the I merge the two projects into one.
Thanks for the comments on the concatenation function: I'll be rewriting it to a more readable form later on.
Thanks to everyone for the helpful comments.
EDIT: found the problem.
A preprocessor #define used to switch on linux dependent implementation of certain members of Path (mainly function creating new dirs and files) was switched on in main project but not in library. This probably caused the problem when the library was linked. Works like a charm now.

Trash characters when using buffers in c++

I have a DLL that I need to handle in C++. I'm using WxWidgets (standard compilation, but I also tried Unicode on/off) and NetBeans. I also tried dealing with this without WxWidgets (windows.h) and had same problems.
Here is how I access the DLL functions using WxWidgets:
// -------------------- POINTERS TO FUNCTIONS
typedef bool(*TYPE_DLL_SetLicense)(char*, char*);
typedef bool(*TYPE_DLL_PingConnection)(char*);
typedef char*(*TYPE_DLL_ERR_DESCRIPTION)(void);
class DLL_Library
{
public:
// pointers to functions inside dll
TYPE_DLL_SetLicense DLL_SetLicense; //initialize - will wor fine as it returns only true/false (buffer only provide data)
TYPE_DLL_PingConnection DLL_PingConnection; //ping to serwer. Will return trahs, becouse it uses buffer to provide data ang get answear back
TYPE_DLL_ERR_DESCRIPTION DLL_ERR_DESCRIPTION; //error description. No buffer, no trouble. Returns correct string.
wxDynamicLibrary dynLib2;
int initialize(void)
{
//patch to dll
wxString path = wxStandardPaths::Get().GetExecutablePath().BeforeLast('\\') + _("\\DLL_dll\\DLLMOK.dll");
if(!wxFile::Exists(path)) return -1;
//load dll
if(!dynLib2.Load(path)) return -2;
//Assign functions in dll to variable
DLL_SetLicense=(TYPE_DLL_SetLicense) dynLib2.GetSymbol(wxT("DLL_SetLicense"));
DLL_PingConnection=(TYPE_DLL_PingConnection) dynLib2.GetSymbol(wxT("DLL_PingConnection"));
DLL_ERR_DESCRIPTION=(TYPE_DLL_ERR_DESCRIPTION) dynLib2.GetSymbol(wxT("DLL_ERROR_DESCRIPTION"));
return 0;
}
};
And here is the function I run. It should return and XML content, that I try to save to the file.
//DLL_PingConnection
//result ping to be save in file
wxFile file_ping_xml;
plik_ping_xml.Open(wxT("C:\\dll\\ping.xml"),wxFile::write);
char buffor_ping_xml[2000];
//I run the function here
bool is_ping = DLL_PingConnection(buffor_ping_xml);
if(is_ping)
{
tex_box->AppendText(wxT("DLL_PingConnection True\n"));
//we save result to file
bool is_write_ping_ok = file_ping_xml.Write(buffor_ping_xml,2000);
if (is_write_ping_ok){tex_box->AppendText(wxT("Save to file is ok ok\n"));}
else {tex_box->AppendText(wxT("Save to file failed :( \n"));}
}
else
{
tex_box->AppendText(wxT("DLL_PingConnection False\n"));
}
std::cout << "Error description: " << DLL_ERR_DESCRIPTION() << "\n"; //will work fine both in saving to file, and in streaming to screen.
The problem is that inside the file instead of good content I get rubbish like this:
NOTE that this only happens in functions that use buffers like:
char buffer[2000] //buffer will contain for example file xml
function do_sth_with_xml(buffer) //buffer containing xml will (should) be overwriten with xml results of the function - in our case DLL_PingCONNECTION should save in buffer xml with connection data
Documentation say that the DLL operates on Windows-1250. File ping.xml I have set to windows ANSI, but I don't think problem lies here.
EDIT: I have written problem without WxWidgets (I load DLL using windows.h) - same problems. Here is the code: Getting trash data in char* while using it as buffer in function . Please help :(
This
DLL_PingConnection=(TYPE_DLL_PingConnection)
shouldn't it be
DLL_PingConnection=(TYPE_DLL_PingConnection) dynLib2.GetSymbol(wxT("DLL_PingConnection"));
?
seems otherwise you will not get a valid pointer to the function in the DLL.
as a general rule you should check return values, especially from a DLL
you load dynamically since it happens that you sometimes get another version
of the DLL which may have a function with same name but other signature or
where is missing entirely.
You named a function
DLL_PingConnection=(TYPE_DLL_PingConnection) dynLib2.GetSymbol(....
and call it with
OSOZ.OSOZ_PingConnection(buffor_ping_xml);
you typedef a function
typedef bool(*TYPE_DLL_PingConnection)(char*);
you create a variable
char buffor_ping_xml[2000];
in your typedef it is char* and your buffor_ping_xml is char
how can that work ?
try
char *buffor_ping_xml = new char[2000];
/* or */
wchar_t *buffor_ping_xml = new wchar_t[2000];
/* or */
wxChar *buffor_ping_xml = new wxchar[2000];
bool is_ping = DLL_PingConnection(buffor_ping_xml);
wxString mystring = wxString::FromUTF8(buffor_ping_xml);
write mystring to file.
To Do:
look in your wxwidgets\libs folder for your libs
are there libwxmsw29ud_* with a 'u' in the name (after version number here 29)?
If not You can not use unicode
If yes next steps
for all different test char *, wchar_t *, wxChar * give the files different name.
for example file_ping_xml.Open(wxT("C:\dll\ping_w_t_FromUTF8.xml"), ...
for wchar_t * in combination with
wxString mystring = wxString::FromUTF8(buffor_ping_xml);
also in combination with
wxString mystring(buffor_ping_xml);
Then check out the look like, of the files in a browser .
To test you can go to your wxWidgets sample folder . Compile in the folder C:\wxWidgets\samples\docview\docview.cpp . Open with docview.exe a unicode file . How does it look.
Unicode download file
Unicode-related compilation settings
You should define wxUSE_UNICODE to 1 to compile your program in Unicode mode. This currently works for wxMSW, wxGTK, wxMac and wxX11. If you compile your program in ANSI mode you can still define wxUSE_WCHAR_T to get some limited support for wchar_t type.
Here is answear: Getting trash data in char* while using it as buffer in function.
Thanks everyone - expecially for patience.