|
I'm trying to use GetFileAttributes to check if a folder is read-only ( for example, when a user right-click on a folder and select Properties and change the read-only attribute )
this is what I do :
DWORD dwAttr = GetFileAttributes(sPath);
if (dwAttr==INVALID_FILE_ATTRIBUTES)
{
ASSERT( 0 );
}
if ( (dwAttr & FILE_ATTRIBUTE_DIRECTORY) )
{
if(dwAttr & FILE_ATTRIBUTE_READONLY)
{
ASSERT( 0 );
}
}
if I try on a file and it works :
CString sFileName( sPath);
sFileName+="tata.txt";
dwAttr = GetFileAttributes( sFileName );
if(dwAttr & FILE_ATTRIBUTE_READONLY)
{
ASSERT( 0 );
}
I assume I'm doing something really stupid, but I cannot see it.
Thanks.
Max.
|
|
|
|
|
|
So what's the problem? What value does dwAttr have? If there is an error, have you called GetLastError() ?
"A good athlete is the result of a good and worthy opponent." - David Crow
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
GetLastError() returns ERROR_SUCCESS
dwAttr is 0x00000010 ( FILE_ATTRIBUTE_DIRECTORY ), I would have expected the value to be 0x00000011 ( FILE_ATTRIBUTE_DIRECTORY and FILE_ATTRIBUTE_READONLY ).
Anyway, it's not an urgent issue for me or our product.
Thanks.
|
|
|
|
|
Maximilien wrote: for example, when a user right-click on a folder and select Properties and change the read-only attribute
That has no effect on my XP Professional SP 2 machine I am sending this from. Perhaps this is what Mark is talking about?
|
|
|
|
|
Same here. I can't find anything except comments about the OS ignoring this attribute and/or
using it for a different purpose.
Beats me....I've never had to worry about it
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Try using _taccess API.
int _access( const char *path, int mode );
int _waccess( const wchar_t *path, int mode );
path - File or directory path
mode - Permission setting
mode Value Checks File For
00 Existence only
02 Write permission
04 Read permission
06 Read and write permission
Regards,
Paresh.
|
|
|
|
|
that does not work either; works only for files, for folder it checks only the existence of the folder (see MSDN doc.)
|
|
|
|
|
Does anyone know the possible reason for the error message "LoadLibrary failed (xxxx.dll)- Invalid access to memory location"? I have a DLL which the same code, I built using VC++ 6.0 one month ago, registered successfully using Regsvr32.exe. Now, I rebuild the same code but when running Regsvr32 to register the newly build .dll and it failed with the message error above.
Between the one month, I installed MS Front Page 2002 and a graphic package to my PC and have ran Windows update once. I thought these might cause the error, so I uninstalled the two new programs and restored my system to the time when the DLL build register successful but the problem remains.
I have also reinstalled MSVC++ and all the other tools with no success....
My colleague, who has the same code, the same setting, can build and register the dll succesfully. If I used his .dll, I can register in my PC but not the one I build. We have the same exact code (source control) and the same copy of the .dsw and .dsp....
Any idea would be greatly appreciated.
|
|
|
|
|
Does your DLL and your colleague's DLL compare the same? If not, then they are somehow being built differently.
"A good athlete is the result of a good and worthy opponent." - David Crow
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
We didn't compare when both was working. Now, when my build did not register, we compared, and the size is about 4k diff but we can not figure out why. We've compared every possible setting/system DLL that we can think of...
|
|
|
|
|
tieng86 wrote: but we can not figure out why
Different Platform SDKs?
|
|
|
|
|
Have you tried the GetLastWin32Error to see exaclty where it is hanging up?
_____________________________________________
Flea Market! It's just like...it's just like...A MINI-MALL!
|
|
|
|
|
Thanks for your sugestion but how would I use the API since the dll is registered after the DLL is built successfully or manually registered on a command line outside of code? Also is this API avail in VC++ 6.0? I did some searching but did not find the help for it.
|
|
|
|
|
|
Hi,
I am using a tree control in a simple GUI.
I responded to a right click on the control and popped up a context menu for it, so far so good.
Next, I want to know which is the HTREEITEM that was selected, so I can do something with it.
The problem is this will work only if the item was first selected by a left click first and then the right click.
If I select an item by docuble click so it will open all of it's sub items and then right click on one of the sub items, the GetSelectedItem function will return me the root item and not the one I right clicked on.
any solution ?
Here are my right click and menu handling functions:
<br />
void Cfbe_sim_guiDlg::OnNMRclickSystemTree(NMHDR *pNMHDR, LRESULT *pResult)<br />
{<br />
DWORD dwPos=::GetMessagePos();<br />
CPoint point((int)LOWORD(dwPos),(int)HIWORD(dwPos));
<br />
CMenu menu;<br />
menu.LoadMenu(IDR_MENU1);<br />
CMenu *pContextMenu=menu.GetSubMenu(0);<br />
<br />
pContextMenu->TrackPopupMenu(TPM_LEFTALIGN|TPM_LEFTBUTTON|TPM_RIGHTBUTTON,<br />
point.x,point.y,AfxGetMainWnd(),<br />
NULL);<br />
<br />
<br />
*pResult = 0;<br />
}<br />
<br />
void Cfbe_sim_guiDlg::OnTreeObjectproperties()<br />
{<br />
<br />
HTREEITEM selected_item = m_ctl_system_tree.GetSelectedItem();<br />
<br />
<br />
CString item_text = m_ctl_system_tree.GetItemText (selected_item); <br />
.<br />
.<br />
.<br />
}<br />
|
|
|
|
|
That's by design.
If you want to select the node the cursor is over then you need to do it manually.
Something like this maybe...
POINT ClientCursPoint, ScreenCursPoint;
::GetCursorPos(&ScreenCursPoint);
ClientCursPoint = ScreenCursPoint;
::ScreenToClient(m_ctl_system_tree, &ClientCursPoint);
TVHITTESTINFO HTInfo;
HTInfo.pt = ClientCursPoint;
HTREEITEM hItem = TreeView_HitTest(m_ctl_system_tree, &HTInfo);
if (hItem)
{
...
TreeView_SelectItem(m_ctl_system_tree, hItem);
}
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
excellent !
that did the trick,
Thanks a lot
|
|
|
|
|
how i can monitor the top processes running in a windows machine from remote .
ie ....i need to make a remote task manager for windows ...Can anybody help
vineesh
|
|
|
|
|
why not remote desktop in the pc and look at the running process that way?
if you want to develop it yourself you will either need to know tcp/ip or use DCOM to make your task manager
GL
Yours Truly, The One and Only!
|
|
|
|
|
Hi All,
I have on basic doubt.
In windows environment both BSTR and LPWSTR are typedef ed to unsigned short *.
But the contents in that pointer are different. BSTR is a wide char string with length in the first byte. LPWSTR is a null terminated string.
But,
<br />
CString str;<br />
LPWSTR lpw = L"lpwstr";<br />
BSTR bst = AllocSysString("bstr");<br />
str = lpw;
str = bsw;
The code works fine, and behaves as we expect.
My doubt is how at run time the decision on the first byte is decided? i.e whether the first byte is the data or the length?? how the compiler identifies.
Thanks and regards,
Raja Pratap
|
|
|
|
|
Raj Prathap wrote: But the contents in that pointer are different. BSTR is a wide char string with length in the first byte.
Actually the length field is 4 bytes long.
Raj Prathap wrote: BSTR bst = AllocSysString("bstr");
The above should be:
BSTR bst = SysAllocString(L"bstr");
Raj Prathap wrote: The code works fine, and behaves as we expect.
My doubt is how at run time the decision on the first byte is decided? i.e whether the first byte is the data or the length?? how the compiler identifies
The trick is in SysAllocString that returs a pointer to the data string, not to the length prefix, see here http://msdn2.microsoft.com/en-us/library/ms221069.aspx[^] for a better explanation.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
|
|
|
|
|
Thanks. The link provided is really helpful.
I was not clear about the parts of the BSTR i.e length+data+terminator. I used think terminator would not be there since the length is already there. Any ways with the link to MSDN article, all doubts are cleared. Thanks a ton.
/pratap
|
|
|
|
|
You are welcome
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
|
|
|
|
|
Raj Prathap wrote: whether the first byte is the data or the length??
Starting address of a BSTR variable always points to real data that is the character string and length is stored at an offset minus starting address of a BSTR variable.
For eg:
BSTR bstrLengthTest = ::SysAllocString( L"Nibu" );
DWORD dwLength = *(DWORD*)((DWORD)bstrLengthTest-sizeof(DWORD));
cout << endl<< "String length in bytes is: " << dwLength << endl;
Hence BSTR always works both ways but an LCWSTR won't always work both ways.
|
|
|
|