|
|
The IShellFolder interface is mainly used to manage folders and provide data for clipboard and drag & drop. I suggest to start without using that and implement the tree and list views using standard API functions like FindFirstFileEx and FindNextFile which provide basic information like size, time stamps and attributes.
For additional info like icons and file types use SHGetFileInfo .
To get the owner name for a file or directory use GetNamedSecurityInfo and LookupAccountSid .
Solutions to resolve reparse points (links and mounts) can be found in the web (open with CreateFile with flags FILE_FLAG_BACKUP_SEMANTICS | FILE_FLAG_OPEN_REPARSE_POINT and call DeviceIoControl with FSCTL_GET_REPARSE_POINT ).
To use the IShellFolder interface you have to get the DesktopFolder and use that to bind to other folders:
LPSHELLFOLDER pDesktopFolder;
::SHGetDesktopFolder(&pDesktopFolder);
LPSHELLFOLDER psfFolder = NULL;
LPITEMIDLIST pFolderPIDL = ::ILCreateFromPath(lpszPath);
HRESULT hRes = pDesktopFolder->BindToObject(
pFolderPIDL,
NULL,
IID_IShellFolder,
IID_PPV_ARGS(&psfFolder)
);
LPITEMIDLIST pPIDL;
CString strName; hRes = psfFolder->ParseDisplayName(
NULL, NULL, strName.GetBuffer(), NULL, &pPIDL, NULL );
strName.ReleaseBuffer();
::CoTaskMemFree(pPIDL);
psfFolder->Release();
::ILFree(pFolderPIDL);
pDesktopFolder->Release();
As you can see there are lot of tasks where some are quite complex.
|
|
|
|
|
|
HWND hWnd;
After that declaration, please, how can I find the total outside size of the current window including the window's frames and menu and any scroll bars etc, not only the window's available area for writing text and images in?
|
|
|
|
|
Once you have the window handle, you just call GetWindowRect[^]
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
|
Thanks.
SetWindowPos() sets up a window, and needs the desired total window size including borders and scroll bars etc.
Can I find easily the values of the needed total window size (say xj and yj) needed to set up a window whose image-and-text area (= client area) is xi * yi)?
|
|
|
|
|
Use GetWindowRect and GetClientRect to find those two values. The difference is the size of the frame portion. You can then calculate your required client size, add that to the frame sizes to get your new window size.
|
|
|
|
|
Just read an article on using classes as a DLLs following the class a __declspec(dllimport/dllexport) is needed. I was just wondering how MFC does it. On my system the MFC code is located in MFC140.DLL now when I inherit a let’s say CDialog class I don’t specify __declspec(dllimport)
Thanks
|
|
|
|
|
ForNow wrote: I don’t specify __declspec(dllimport) No because that declaration will be in the header file. You should take a look at Creating and Using a Dynamic Link Library (C++)[^] for more information. Basically the project that creates the dll needs __declspec(dllexport) and every application the wants to use it needs __declspec(dllimport) . This is usually controlled by a #define in the header that goes with the dll. If you create a DLL project in Visual Studio and select the "Export Symbols" checkbox, you get the following in the header:
#ifdef WIN32PROJECT2_EXPORTS
#define WIN32PROJECT2_API __declspec(dllexport)
#else
#define WIN32PROJECT2_API __declspec(dllimport)
#endif
class WIN32PROJECT2_API CWin32Project2 {
public:
CWin32Project2(void);
};
extern WIN32PROJECT2_API int nWin32Project2;
WIN32PROJECT2_API int fnWin32Project2(void);
|
|
|
|
|
Thanks I was just curious how MFC does it the code is in MFC140.DLL
and I don’t see any __declspec(import)
When I want to use CDialog
Also I assume when I follow theses steps in my .dll I’ll create a .lib
Thanks
|
|
|
|
|
The exported labels are not in the dll, as that means nothing to the compiler. They are in one of the header files somewhere in the MFC include folders. So if you find the definition of CDialog it will somehow be defined there.
|
|
|
|
|
FYI I did a dependency walker against MFC140.DLL and I got all the entry points N/A meaning without function names
|
|
|
|
|
Well they will be in there somewhere, but MFC/C++ names get mangled up and are not always easy to recognise. Be that as it may, if the entry points didn't exist then the dll would not be usable. I have not used MFC for many years so cannot actually check any of this. The key point is to ignore the dll and inspect the header files.
|
|
|
|
|
Exporting from a DLL Using __declspec(dllexport)[^]
Many export directives, such as ordinals, NONAME, and PRIVATE, can be made only in a .def file, and there is no way to specify these attributes without a .def file. However, using __declspec(dllexport) in addition to using a .def file does not cause build errors.
It's a protection scheme they are exported as privates or ordinals probably so they can avoid ANSI, MBCS, and Unicode issues on the call name.
In vino veritas
modified 25-Jan-18 0:07am.
|
|
|
|
|
|
My development environment is Eclipse C Android NDK
I want to create and run a Simple thread from a function
I am trying to use
pthread_create()
Can some one point me to a simple thread example C Android
What I tired and confusing for me is, what parms I need to pass to this function ?
JNIEXPORT void JNICALL
Java_org_testjni_android_Game_someFunction(JNIEnv * env, jobject obj)
{
|
|
|
|
|
What does the first part of your question have to do with the second? What thread are you trying to create and run? What is the JNI function for?
|
|
|
|
|
As Richard pointed out, there (should be) no need to export to the Java environment the pthread_create function. Make a wrapper (with a simpler signature) for that and then export to Java (if you need to) such a wrapper.
As about pthread_create , its very man page[^] provides sample code.
|
|
|
|
|
I'm using a class to work with the registry that I downloaded from an MSDN article. The problem is that whenever I go to read a string (REG_SZ), the RegGetValue call fails with ERROR_FILE_NOT_FOUND (#2).
In fact no matter what I've tried, it insists on returning that error. I've tried building the program for 64-bit as well as 32 - no difference. I've made sure that the key is being opened properly. That succeeds, but reading a string value does not. I'm now pulling my hair out.
Does anyone know why it's returning ERROR_FILE_NOT_FOUND?
This is the code that's calling RegGetValue:
inline std::wstring RegGetString(HKEY hKey, const std::wstring& subKey, const std::wstring& value)
{
DWORD dataSize{};
LONG retCode = ::RegGetValue(
hKey,
subKey.c_str(),
value.c_str(),
RRF_RT_REG_SZ,
nullptr,
nullptr,
&dataSize);
if (retCode != ERROR_SUCCESS)
{
throw RegistryError{ "Cannot read string from registry", retCode };
}
These are the relevant values: hKey is HKEY_CURRENT_USER,
subKey is "Software\Microsoft\Windows\CurrentVersion\Run" The string is properly escaped.
and value is a REG_SZ entry.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Hmmmm,
Your code works for me. Here is how I am calling your function:
HKEY hKey;
DWORD dwResult = RegOpenKeyEx(HKEY_CURRENT_USER, nullptr, 0, KEY_READ, &hKey);
if (ERROR_SUCCESS == dwResult)
{
std::wstring subkey = L"Software\\Microsoft\\Windows\\CurrentVersion\\Run";
std::wstring value = L"OneDrive";
RegGetString(hKey, subkey, value);
}
RegCloseKey(hKey);
Best Wishes,
-David Delaune
|
|
|
|
|
Thank you for your response. The code you posted works for me too.
I notice that you opened the HKEY without specifying a subkey in the call to RegOpenKeyEx. You only specified the subkey in the call to RegGetString. Is that the way it's supposed to work? Should I not pass a subkey to RegOpenKeyEx?
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Richard,
Richard Andrew x64 wrote: I notice that you opened the HKEY without specifying a subkey in the call to RegOpenKeyEx. You only specified the subkey in the call to RegGetString. Is that the way it's supposed to work? Should I not pass a subkey to RegOpenKeyEx?
No.
Your sample code works even if I open the subkey in the call to RegOpenKeyEx.
HKEY hKey;
DWORD dwResult = RegOpenKeyEx(HKEY_CURRENT_USER, L"Software\\Microsoft\\Windows\\CurrentVersion\\Run", 0, KEY_READ, &hKey);
if (ERROR_SUCCESS == dwResult)
{
std::wstring subkey = L"Software\\Microsoft\\Windows\\CurrentVersion\\Run";
std::wstring value = L"OneDrive";
RegGetString(hKey, subkey, value);
}
RegCloseKey(hKey);
Your original bug is due to the fact that you are sending an empty string instead of a null pointer. Make the following change:
inline std::wstring RegGetString(HKEY hKey, const std::wstring& subKey, const std::wstring& value)
{
DWORD dataSize{};
LONG retCode = ::RegGetValue(
hKey,
nullptr, value.c_str(),
RRF_RT_REG_SZ,
nullptr,
nullptr,
&dataSize);
if (retCode != ERROR_SUCCESS)
{
int iDebug = 0;
}
return L"";
}
The MSDN documentation is poorly written. You should be following the rules described in the documentation for the RegOpenKeyEx function[^] lpSubKey parameter.
The lpSubKey parameter can be NULL only if hKey is one of the predefined keys. If lpSubKey is NULL and hKey is HKEY_CLASSES_ROOT, phkResult receives a new handle to the key specified by hKey. Otherwise, phkResult receives the same hKey handle passed in to the function.
Use the 'Is this Page Helpful' button at the bottom of the MSDN documentation for the RegGetValue function[^] and report the discrepancy.
Best Wishes,
-David Delaune
|
|
|
|
|
Thank you, David. I have it working now. You saved what's left of my hair.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Are you sure that the string in value is correct?
|
|
|
|