|
thanx...
birajendu
CyberG India
Delhi
India
|
|
|
|
|
This is a function that finds all removeable drives in a system, including USB-connected harddrives.
It's not exactly what you asked for, but it works. Feel free to use bits and pieces of it.
The result is stored in the class variable
DWORD fRemovableDrives;
The function returns the number of drives found.
<code>
long CKonfig::GetRemovableDriveCount()
{
// Find units that Windows flags as REMOVEABLE
// Accept USB-hard drives too. And all USB unitsv that can handle data
int i;
char sDrivePath[3];
UINT uDriveType;
DWORD dwDrives;
fRemovableDrives = 0;
int noOfDrives = 0;
dwDrives = GetLogicalDrives();
strcpy(sDrivePath+1, ":\\");
// Loop through the found drives
for(i = 0; i < 32; i++) {
if(dwDrives & (1 << i)) {
// Create sDrivePath
sDrivePath[0] = (char) ('A' + i);
uDriveType = GetDriveType(sDrivePath);
if((uDriveType == DRIVE_REMOVABLE || uDriveType== DRIVE_RAMDISK)) {
// It's a removable or a RAM-DISK(nödlösning), add it to the list
fRemovableDrives |= (1 << i);
noOfDrives++;
}
else {
if(uDriveType == DRIVE_FIXED) {
// DRIVE_FIXED: The disk cannot be removed from the drive.
// Accept DRIVE_FIXED if it's a USB unit
char szBuf[10];
HANDLE hDevice;
PSTORAGE_DEVICE_DESCRIPTOR pDevDesc;
sprintf(szBuf, "\\\\?\\%c:", sDrivePath[0]);
// Open the unit with "zero rights". Works.
hDevice = CreateFile(szBuf, 0,
FILE_SHARE_READ | FILE_SHARE_WRITE, NULL, OPEN_EXISTING, NULL, NULL);
if (hDevice != INVALID_HANDLE_VALUE) {
pDevDesc = (PSTORAGE_DEVICE_DESCRIPTOR)new BYTE[sizeof(STORAGE_DEVICE_DESCRIPTOR) + 512 - 1];
pDevDesc->Size = sizeof(STORAGE_DEVICE_DESCRIPTOR) + 512 - 1;
if(GetDisksProperty(hDevice, pDevDesc))
{
if(pDevDesc->BusType == BusTypeUsb)
{
// It's USB, save it.
fRemovableDrives |= (1 << i);
noOfDrives++;
}
}
delete pDevDesc;
CloseHandle(hDevice);
}
}
}
}
}
return noOfDrives;
}
</code>
Kakan
|
|
|
|
|
See MSDN article Q264203.
"The words of God are not like the oak leaf which dies and falls to the earth, but like the pine tree which stays green forever." - Native American Proverb
|
|
|
|
|
Hello community,
does any one know how to fill CTreeCtrl from a ThreadFunction in two steps???
First step is when the root item is fill, and the next is when the child item is fill!
I try with this:
<br />
HTREEITEM hTreeItem;<br />
::SendMessage(AfxGetApp()->GetMainWnd()->m_hWnd, WM_FILL_TREE, 0, (LPARAM&) csFileName);<br />
<br />
<br />
::SendMessage(AfxGetApp()->GetMainWnd()->m_hWnd, WM_FILL_CHILD_TREE, (WPARAM&) hTreeItem, (LPARAM&) csTemp);<br />
<br />
LRESULT CForeCheckDlg::OnFillTree(WPARAM wParam, LPARAM lParam)<br />
{<br />
EnterCriticalSection(&m_CritSect);<br />
CString csUrl;<br />
csUrl = (CString&) lParam;<br />
CTreeCtrl* cTree = (CTreeCtrl*) ((CWeb*)m_cTabAll.GetTab(6))->GetDlgItem(IDC_TREE1);<br />
<br />
hTreeItem = cTree->InsertItem(csUrl,0,0);
LeaveCriticalSection(&m_CritSect);<br />
return 0;<br />
}<br />
<br />
LRESULT CForeCheckDlg::OnFillChildTree(WPARAM wParam, LPARAM lParam)<br />
{<br />
<br />
EnterCriticalSection(&m_CritSect);<br />
<br />
CTreeCtrl* cTree = (CTreeCtrl*) ((CWeb*)m_cTabAll.GetTab(6))->GetDlgItem(IDC_TREE1);<br />
HTREEITEM hParent;<br />
hParent = (HTREEITEM&)wParam;<br />
CString csUrl;<br />
csUrl = (CString&) lParam;
<br />
cTree->InsertItem(csUrl, 0, 0, hParent); <br />
<br />
LeaveCriticalSection(&m_CritSect);<br />
<br />
return 0;<br />
}<br />
<br />
The Childitems ar insert, but to wrong Roots!
Thanx for any help!
with best regards
break;
|
|
|
|
|
what's the use of a FAR pointer??
like what's the difference between char *str; char FAR *str; ?
is this the same meaning as we have in ASM ? FAR segment?.. anyway can you please type in a
small execute-able program stating the difference?
regards,
Rookie
Installing MFC...2% complete
|
|
|
|
|
this keyword exist for compatibility with old C (when 16-bits processors where running).
but now, FAR is defined as an empty macro :
#define FAR
TOXCCT >>> GEII power
[toxcct][VisualCalc 2.20][VisualCalc 3.0]
-- modified at 6:13 Tuesday 10th January, 2006
|
|
|
|
|
so FAR has got to do only with 16 bits..right?
regards,
Rookie
Installing MFC...2% complete
|
|
|
|
|
Rokiee wrote: so FAR has got to do only with 16 bits..right?
well seen sherlock...
simply because memory was not managed the same way at the old age of MS-DOS Operating System...
TOXCCT >>> GEII power
[toxcct][VisualCalc 2.20][VisualCalc 3.0]
-- modified at 7:04 Tuesday 10th January, 2006
|
|
|
|
|
Hello,
In the old 16 bit days, there were two different pointers: near and far. As far as I can remember, near pointers, point to memory addresses within the same segment and far pointers point to memory addresses within other segments.
At this time (and in the future) far and near pointers are all the same.
Hope this helps.
Behind every great black man...
... is the police. - Conspiracy brother
Blog[^]
|
|
|
|
|
thanks bob.. but why these "segment" concept has gone now? and why its was used before?
regards,
Rookie
Installing MFC...2% complete
|
|
|
|
|
The concept of the segmented memory is in Real mode of the processor. Windows works in protected mode of the processor where the memory is addressed as a flat 32bit.
That is why all pointers in VC++ or windows in a 32bit irrespective if its a near one or a far one.
-Prakash
|
|
|
|
|
Hello,
The segment concept is not gone, windows still uses internally within the virtual memory manager, but this is completely hidden from the programmer. Pointers these days are merely offsets from the start of the memory region allocated by Windows(r). This way, the memory allocated can be anywhere: pagefile, memory mapped file, RAM, etc. It doesn't matter the memory manager makes sure that the memory will be in RAM when you use it.
This is also the reason that you can't mess with other programs memory anymore since the offsets are only valid within the context of your process. Before, pointers could point to any memory source available to the system.
Behind every great black man...
... is the police. - Conspiracy brother
Blog[^]
|
|
|
|
|
Give me or refer any tutorials for MDI application in MFC.
|
|
|
|
|
Please refer MSDN samples for MFC
|
|
|
|
|
|
toxcct wrote: i won't answer much as it is the 4th time you ask the same question the same way...
Are you keeping statistics ?  I rarely check names when I answer a thread, so I always find it amazing how you can spot multithreaders like him.
~RaGE();
|
|
|
|
|
Rage wrote: Are you keeping statistics ?
no, simply i answered him the 4 times he asked this, and still he keeps asking... 
same question => same answers
Rage wrote: I rarely check names when I answer a thread
i don't do it every time, but i do it often ; as far as i also check sometimes the guys profiles to know if they are beginners or not (looking at their birth date when provided, their member level too, etc...), to respond in consequence... 
here is my secret 
TOXCCT >>> GEII power
[toxcct][VisualCalc 2.20][VisualCalc 3.0]
-- modified at 6:27 Tuesday 10th January, 2006
|
|
|
|
|
not for you dear ~Rage, but :
Who are you sucker who vote anonymously all my posts to '1' without even justifying your act ? bastard 
come on, show me your face stupid boy
TOXCCT >>> GEII power
[toxcct][VisualCalc 2.20][VisualCalc 3.0]
-- modified at 10:29 Tuesday 10th January, 2006
|
|
|
|
|
For MDI Application refer Jeff prosise book for MFC PROGRAMMING.
|
|
|
|
|
I completely agree with Yuwraj: The Prosise book got me started on MFC. Mind you, I'm not a big fan of the framework, but it's usable and Prosise makes it accessible.
"we must lose precision to make significant statements about complex systems."
-deKorvin on uncertainty
|
|
|
|
|
I have imported the dll org.mentalis.security.dll but while compiling
it gives the following error.
fatal error C1083: Cannot open type library file: 'c:\mentalis\seclib-1.0\signed_builds\1.1\org.mentalis.security.dll': Error loading type library/DLL.
Yuwraj
|
|
|
|
|
|
In the following short program, CreateIoCompletionPort fails and GetLastError says invalid handle was supplied. Return values from CreateFile is not INVALID_HANDLE_VALUE so I guess that IOCP doesn't accept handles for consoles.
I just want to confirm that it is true or I made a mistake in this program. I intended to receive console inputs via IOCP.
#include <stdio.h>
#include <windows.h>
int
main( void )
{
HANDLE stdin_handle, iocp, stdout_handle;
stdin_handle = CreateFile( "CON",
GENERIC_READ, FILE_SHARE_READ|FILE_SHARE_WRITE, NULL,
OPEN_EXISTING,
FILE_FLAG_OVERLAPPED, NULL );
stdout_handle = CreateFile( "CON",
GENERIC_WRITE, FILE_SHARE_READ|FILE_SHARE_WRITE, NULL,
OPEN_EXISTING,
FILE_FLAG_OVERLAPPED, NULL );
iocp = CreateIoCompletionPort( stdin_handle, NULL, 0, 1 );
if( iocp ) {
CloseHandle( iocp );
puts( "O.K." );
}
else {
printf( "Error = %lu, stdin=%p, stdout=%p invalid_handle=%p\n",
GetLastError(), stdin_handle, stdout_handle, INVALID_HANDLE_VALUE );
}
return 0;
}
-- modified at 4:02 Tuesday 10th January, 2006
|
|
|
|
|
the completion key should not be 0.
besides, i always create a iocp with no handle, and then attach stuff to it.
|
|
|
|
|
Though I supply non-zero value for the completion key ( the 3rd arg. ), the result is the same. And I couldn't find restrictions for the value of the completion key mentioned in MSDN.
And supplying INVALID_HANDLE_VALUE for the 1st arg is not compatible for NT 3.5 or below.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
