|
I had set a image to the picture. At a simple project, this way is OK. I guess it need to draw the image in OnPaint function.
|
|
|
|
|
Hi,
on win7, if you open Notepad and write.exe and paste a long text, the notepad will scroll quickly with the mouse wheel.
The RichEdit control in the write.exe, however, uses some sort of "smooth scrolling", which is totally disturbing.
In my program, I want to make the CRichEditCtrl as snappy a CEditCtrl. Any ideas?
Many thanks,
-Gernot
|
|
|
|
|
Does this behaviour happen also in your code or is it specific to write.exe?
One of these days I'm going to think of a really clever signature.
|
|
|
|
|
I'd say it happens in any CRichEditCtrl you make unless you find a way to disable it. Yes, my program suffers from this behaviour.
|
|
|
|
|
I would guess then, that it is a feature of the control so unless there is a method in the class to disable it then you are stuck with it. You could try subclassing[^] the control to see if there is a way to improve it.
One of these days I'm going to think of a really clever signature.
|
|
|
|
|
hi all,
i am getting all drives list connected in my system.
as list of logical drive and physical drive.
for logical drives i m using GetLogicalDrives()
and for physical drives using com with this query "Win32_DiskDrive".
but how can i indetify which drive is external drive in out of all drive for both logical and physical.
please help me for this.
thank in advance.
|
|
|
|
|
You could always check the documentation[^].
One of these days I'm going to think of a really clever signature.
|
|
|
|
|
this is working only for physical disk drive
i have done this with MediaType parameter with "External hard disk media" value.
now what can i use for logical drives.
modified 5-Sep-12 4:35am.
|
|
|
|
|
Since a physical drive can contain many logical drives it probably does not make sense for logical. You probably need to find the logical drive's parent device and check that.
One of these days I'm going to think of a really clever signature.
|
|
|
|
|
ok so how can i get its parent disk
|
|
|
|
|
Sorry, I'm not sure, but maybe one of these functions[^] will help.
One of these days I'm going to think of a really clever signature.
|
|
|
|
|
thanks for you help its done...
|
|
|
|
|
Maybe you could give the details here, so it will be available for others facing similar issues.
One of these days I'm going to think of a really clever signature.
|
|
|
|
|
using this to get hard disk num of selected drive
CString drive_is;
int ret_disk_num=-1;
drive_is.Remove('\\');
drive_is.Trim();
CString szDrive=_T("\\\\.\\");
szDrive+= drive_is;
int rt;
HANDLE h = CreateFile(szDrive, GENERIC_READ, FILE_SHARE_READ|FILE_SHARE_WRITE,NULL,OPEN_EXISTING,FILE_ATTRIBUTE_NORMAL | FILE_FLAG_OVERLAPPED,NULL);
if(INVALID_HANDLE_VALUE != h)
{
VOLUME_DISK_EXTENTS vdExtents;
ZeroMemory(&vdExtents, sizeof(vdExtents));
DWORD d =32;
DWORD dwRet;
rt = DeviceIoControl(h, IOCTL_VOLUME_GET_VOLUME_DISK_EXTENTS, NULL, 0, &vdExtents, d, &dwRet, NULL);
CloseHandle(h);
h=NULL;
if(rt != 0)
{
for (DWORD n = 0; n < vdExtents.NumberOfDiskExtents; ++n)
{
PDISK_EXTENT pDiskExtent = &vdExtents.Extents[n];
ret_disk_num =pDiskExtent->DiskNumber;
}
}
else
{
DWORD d;
d = GetLastError();
}
if(h!=NULL)
CloseHandle(h);
}
else
{
return ret_disk_num;
}
return ret_disk_num;
}
after getting disk drive num chek the media type of drive using Win32_DiskDrive.
|
|
|
|
|
In the code for part of a project I am working on is the following use of a thread:
if(txt == "Start" && UpdateData(true))
{
if(!m_inst->StartOperation())
{
MessageBox("The Instrument is Currently in use by another function");
return;
}
if(! CreateData(m_MaxFreq, m_Resolution))
return;
EnableItems(false);
m_Continue = true;
m_datacount = 0;
GetDlgItem(IDC_SPECTRUM_START)->SetWindowText("Stop");
m_Thread = AfxBeginThread(Acq_Data,this,THREAD_PRIORITY_HIGHEST);
return;
}
My goal is to make the data acquired and then displayed continuously. I tried to just loop the thread, but this did not work. I realize I may have to modify the member function the thread calls (Acq_Data), but I am not sure. If someone has a good suggestion (or general thread advice) it would be great help. I can also provide more info if needed (as there is little additional code provided in this initial post relating to the other member functions).
Thanks!
|
|
|
|
|
Neither the code, nor the explanation about the goal of your program is enough. Looking at the code I'm almost sure your threading isn't correct.
|
|
|
|
|
AndrewG1231 wrote: My goal is to make the data acquired and then displayed continuously.
Remember that you cannot update the UI from the secondary thread. Have the worker thread "post" a message to the primary thread (the one that owns the UI).
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
|
|
|
|
|
Ok, so the thread is merely obtaining the information and being passed elsewhere for updating the UI? This would explain why the for loop attempt failed. So, I must look for the area of the code where the data is drawn is your suggestion?
|
|
|
|
|
The less hassle free solution is sending a message from the worker thread to the ui thread by using SendMessage() or PostMessage() with one of your windows.
|
|
|
|
|
Thank you for the suggestion, but I am unfamiliar with SendMessage() and PostMessage(). Would you be able to give me an example of how to do this or direct me to a good tutorial/article?
|
|
|
|
|
Its easy. Inside your program every window belongs to a thread - the thread that created the window (note that in a normal program every window is created by a single thread). That thread has a message queue. Every time you do something to the window - click on it with the mouse, request redrawing part of its client area - a message for that window is put in the message queue of the thread that handles that window. The gui thread should remove messages and process them in a loop (this is called the main message loop: GetMessage/DispatchMessage funcionts). In your case MFC does this for you, in pure win32 you do that for yourself. The window messages (WM_LBUTTONDOWN, WM_CLOSE, WM_PAINT, etc...) are also messages that come from that message queue, and when the gui thread encounters such a window message it dispatches that to the windowproc of the right window. OK, how is this related to worker threads? Actually message queues are one of the best things to use as inter-thread communication and fortunately this thread-message queue is thread safe, you can put a message to it from any other thread. For example you can put a window message into the message queue of the gui thread by calling PostMessage() or SendMessage() form your worker thread. Both of these functions put a message to the message queue of the gui thread but PostMessage() returns immediately while SendMessage() blocks the execution of the caller thread and returns only after the gui thread has processed the message. OK, but where to send the message, and what message??? You should define your own window messages by starting from the WM_APP constant. You define for example WM_APP+0 and WM_APP+1 and so on as your thread messages. With PostMessage() and SendMessage() you can send these custom messages to your main window and you can also specify 2 integer parameters: wParam and lParam (lParam is somtimes used as a pointer). For example when you are copying a big file on the worker thread and the percentage counter changes you can use PostMessage() to send a WM_APP+0 message with a wParam=percentage parameter. In your main window you handle the WM_APP+0 message (on your gui thread) and update your progressbar accordingly. Note that we used PostMessage() that put the message to the queue of the gui thread for later processing and PostMessage() returned immediately without unnecessarily waiting for the actual processing of the message on the gui thread (and the progressbur update) so as to prevent slowing down the worker thread. No need to wait for that progressbar update on the gui thread! A codeproject article that demonstrates the use of these thingies with MFC: Synchronization in Multithreaded Applications with MFC[^]
modified 4-Sep-12 20:30pm.
|
|
|
|
|
Good comment, but you may win an award for the most poorly formatted comment this year.
|
|
|
|
|
Well, formatting has never been a strength of mine...
|
|
|
|
|
Yeah that was pretty painful
|
|
|
|
|
Try some better spacing, and use paragraphs; this is very hard on the eyes.
One of these days I'm going to think of a really clever signature.
|
|
|
|