|
If you want to detect drive is DVD or CD, first use GetDriveType, then check capacity of disk. CD-ROM takes about 650-700 MB of data. If capacity is more than 700MB, it is a DVD!
A. Riazi
|
|
|
|
|
Search for STORAGE_MEDIA_TYPE. It's an enumeration defined in winioctl.h. I believe this is what you're looking for.
|
|
|
|
|
thanks, this was a good hint.
I have put the solution on the thread
|
|
|
|
|
<br />
#include <Winioctl.h><br />
BOOL CMainFrame::IsItADvd (char cVolume)<br />
{<br />
BOOL bResult = FALSE;<br />
CString sTemp;<br />
GET_MEDIA_TYPES GetMediaTypes;<br />
DWORD dwBytesReturned;<br />
<br />
sTemp.Format ("\\\\.\\%c:", cVolume);<br />
sTemp.MakeUpper ();<br />
HANDLE hDevice = CreateFile(sTemp,GENERIC_READ, FILE_SHARE_READ,NULL, OPEN_EXISTING, 0, NULL);<br />
<br />
if (hDevice == INVALID_HANDLE_VALUE)<br />
return FALSE;<br />
<br />
if (DeviceIoControl(hDevice, IOCTL_STORAGE_GET_MEDIA_TYPES_EX, NULL, 0, (void*)&GetMediaTypes, sizeof (GET_MEDIA_TYPES), &dwBytesReturned, NULL))<br />
bResult = (GetMediaTypes.DeviceType == FILE_DEVICE_DVD);
<br />
CloseHandle (hDevice);<br />
return bResult;<br />
}<br />
|
|
|
|
|
Hello,
Just wondering if there are any math tricks for doing this.. If not does anyone know the best way of doing this?
Given a CString "123".
I need to add each digit in the string.. The sum of this example would be 6 (1+2+3).
The string will always be at least 1 digit and no more than 3 digits.
Any ideas?
Rob
|
|
|
|
|
for (int i=0; i < str.GetLength(); i++
{
char digit = str.GetAt(i);
sum += (digit - '0');
}
-c
WWT2D?
|
|
|
|
|
Thanks. Wrote it a little different but you got me on the right track... THANK YOU,
Rob
|
|
|
|
|
I need some tips on what is the best way to fix this.
I need a way to view a log file in my program.
The log file is in standard ASCII text format.
But problem is that the log file can be 2-300 MB big.
And I don't want to load the whole file into memory.
So I can’t use the standard CEdit.
Anyone know if there exists any controller for this?
Maybe an enhanced read-only CEdit controller that supports what I need?
Someone must have needed to do this before.
Or I need to start coding something my self. If so What’s best way to do it ?
Is it to create a new controller inherited from CEdit and only show the first 100 lines and manipulate the scroll bar to fool the user that there are more to show and when user scrolls down read in the next 100 lines (depends on how much was scrolled ofcourse) from the log file and show that? Any ides and tips are appreciated.
/Mathias
|
|
|
|
|
Are you using 9X? If so, you may want to skip the CEdit entirely - it is limited to 64K of data.
I'd use a custom control, although this is no trivial amount of work. Are there any articles here on CodeProject about this kind of thing?
You can pick your friends, and you can pick your nose, but you can't pick your friend's nose.
|
|
|
|
|
A viewer is easy, editing the file is more awkward.
Simply create a SDI prog with a CScrollView style and the create what was called a virtual view onto the file. The easy way if to create a DWORD array in which you store the position of the start of each line, e.g. read the file and for each line store the start position of each line, makes finding each line easier, when scrolling backwards. Or the old fashioned way write this data to a temporary binary file, which is then used as an index. Remember to display the 1st screen full very quickly
Then when reading the file store "100" lines, i.e. a bit more than a screen full into a CStringArray. You now have the data to display.
This is a bit of a kludge but it solves the problem of stepping backwards through an ASCII file.
There is a cavaet beware of the bug that the max value in a scroll control is 32767, so if you file is > 32767 you need to find the M$ workaround.
I have ued this method for a specialised file viewer and it works very well.
If I have seen further it is by standing on the shoulders of Giants. - Isaac Newton 1676
|
|
|
|
|
A good way to access files that are very large is to use memory mapped files. PJ Naughter has a good class wrapper to handle implementing them. Essentially, the file is mapped into memory and you access it (forwards or backwards) with pointers as if everything were in an array. The operating system handles all of the buffering of data for you.
You can take any section of the file and do with it what you want in any sort of control, and it works for both read-only and writeable files. I have used memory mapped files that are on the order of 600+ MB without difficulty.
Dave
"You can say that again." -- Dept. of Redundancy Dept.
|
|
|
|
|
Yes I was going to suggest memory mapped files as well. MMF is an excellent way to handle various operations on large files, quickly and efficiently. You could probably just build a vector<int> which had the offset to the start of each line and use this in a virtual list control. Editing is a lot more work, but you said you don't need that.
Re. "writeable files" yes you can, but you can't efficiently insert or delete, just overwrite or append.
Neville Franks, Author of ED for Windows. www.getsoft.com
Make money with our new Affilate program
|
|
|
|
|
Hello,
I have a problem with these function.(i work with VC7 and MDI project)
when i do GetWindowRect to get Child window coordinates i get coordinates from the top left (0,0) of the screen,it's OK.
But when i want to position window i use SetWindowPos ans there is a probleme because SetWindowPos sets the window position from the top left corner of the client area of the main frame !!
You know how can i get function like "GetWindowPos" or "SetWindowRec" ??
Thx in advance
|
|
|
|
|
The functions you use are all ok. But you need to adapt the origin by calling ScreenToClient() from the window which holds the client window to adapt the coordinates.
So from within your client it should look like:
CRect rct;
GetWindowRect(&rct);
GetParent()->ScreenToClient(&rct);
SetWindowPos(...);
|
|
|
|
|
THX ! 
but with ScreenToClient() i get the height and width of the window (like GetClientRect), but not the position in the client area of the main frame.
ex :
with :
GetWindowRect(&WndRect)
i get :
{top=159 bottom=476 left=233 right=886}
after :
GetParent()->ScreenToClient(WndRect);
i get :
{top=<big>0</big> bottom=317 left=<big>0</big> right=653}
(the window is not in the top left corner of the client area )
you know how to have coordinate in the client area?
|
|
|
|
|
First of all it seems to me like you called GetWindowRect on you frame window instead of your child window, because your client coordinates should never return 0 in your case (a child window should not have it's upper-left edge at the same point as it's parent).
To move your window according to the client area, I think a call to GetClientRect should return the it's coordinates when called on a CMDIFrameWnd, thus giving you the coordinates of your client area in relation to the windows origin (0, 0). With these information you only need to add the obtained value to your new child's position and then move it to it's new place - that's all
|
|
|
|
|
i have already try GetClientRect but I have always (0,0). but i should call GetclientRect in specific place ?
thx you for your help !
|
|
|
|
|
I had a whole night to think about your problem ....
I thought a call to GetClientRect from within your mdi frame wnd would give you the coordinates of your client area ... but possibly is does not. So what I came across is that every mdi window holds a variable called m_hWndMDIClient, a handle to it's client area. Calling GetWindowRect on this handle, the converting it to the mdi frame's client coordingates with ScreenToClient should deliver you your requested information...
|
|
|
|
|
lol Sorry for your bad night !!
i'm going to try this...
I keep you informed
|
|
|
|
|
jeremysay wrote:
Sorry for your bad night !!
Doesn't matter ... I can make up for my missing sleep at work...
|
|
|
|
|
Schlaubi wrote:
Calling GetWindowRect on this handle
oups  i'm sorry but i don't know to call GetWindowRect on handle
can you give me sample code ?
|
|
|
|
|
Simply call the API version ::GetWindowRect(), where the first parameter is the handle to the window from which to detect the coordinates. A second approach could be Attaching the handle to a CWnd object and then calling it's GetWindowRect (but I prefer the former way )
|
|
|
|
|
GGRRRREEEAAAAATTTT it's works fine !! i found
CWnd* pMDIClientWnd = CWnd::FromHandle(pFrame->m_hWndMDIClient);
if (pMDIClientWnd)
{
pMDIClientWnd->GetWindowRect(&ClientRect);
}
to Use m_hWndMDIClient, it is the right solution !! i get the coordinates of client area and i can to position my window where i want !!
THX THX again Schlaubi you help me so much, i should send you bottle of wine
|
|
|
|
|
jeremysay wrote:
i should send you bottle of wine
Nice idea ... thx
btw: I prefer the red one, dry and fruity
|
|
|
|
|
jeremysay wrote:
GGRRRREEEAAAAATTTT it's works fine !! i found
...and calling
::GetWindowRect(m_hWndMDIClient, &ClientRect)
would do it without needing to deal with CWnd.
Sorry, but in my last post I forgot the code snippets .. but luckily you found the solution anyway.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
