|
Since thread API require a DWORD , you may expect up to 10 digits (in base 10 notation).
The above is a conservative approach since allowed ID range maybe smaller but I can't find any documented constraint on it.
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.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
|
|
|
|
|
pl_kode wrote: Please let me know how big or max int can a thread's ID be. i.e. how many digits a thread ID can be.
Microsoft do not document the range of the thread ID. On desktop Windows it is currently a handle into the kernel handle table and is therefore typically a number between 4 and a few thousand, but this is not true on Windows CE. You should allow for any value between 0 and 4,294,967,295.
Also kindly tell me how many, at the max, threads can run at the same time. Max number of threads running at the same time, what is it.
The number of threads that can be created is limited only by the amount of memory in the system. For any given process this is approximately the amount of virtual address space divided by the stack reservation size (normally 1MB, so 1500 is typically the maximum on a 32-bit system). The number of threads that can actually be running on CPU cores concurrently is the number of CPU cores. The number of threads in the runnable state (not blocked, waiting for a CPU) is also effectively unlimited, limited only by the amount of memory in the system.
It takes a finite amount of time to switch between one thread and another, and because of round-robin scheduling, if there are a lot of threads to run, it can take a long time between two time slices for a given thread. (When a thread's time slice expires, it goes on the end of the queue of threads to run.) In many cases the context-switch overhead tends to dominate the overall runtime, causing throughput to be lower than if you queued requests to run on a smaller pool of threads.
Windows has a handy concept called an I/O Completion Port which, once a thread is associated with it, will track when that thread blocks due to some other wait (for I/O, comms, sleep, whatever, as long as it's ultimately waiting on an OS object) and if there's a thread waiting for work, work is queued, and there are fewer than a threshold of threads already running, the thread that most recently started waiting for work is released. This generally keeps the number of runnable threads down. Scalable servers on Windows generally use I/O Completion Ports (SQL Server uses its own scheduler with asynchronous I/O so only has one thread per CPU core.)
DoEvents: Generating unexpected recursion since 1991
|
|
|
|
|
I have a list control which is declared like this
CListCtrl m_list1;
I set the background color to black, and the text color to white. Whenever I select a row, I just want to draw a rectangular wrap to the row. So I implement the item change method, like this:
void AlarmCompreMsgDig::OnLvnItemchangedList1(NMHDR *pNMHDR, LRESULT *pResult)
{
LPNMLISTVIEW pNMLV = reinterpret_cast<lpnmlistview>(pNMHDR);
m_lstAlarmCompreMsg.SetItemState(-1, 0, LVIS_SELECTED);
int rowIndex = pNMLV->iItem;
CRect rec;
m_lstAlarmCompreMsg.GetItemRect(rowIndex, rec, LVIR_BOUNDS);
rec.top -= 2;
rec.bottom += 2;
CDC* cdc = m_lstAlarmCompreMsg.GetDC();
CPen aPen;
aPen.CreatePen(PS_SOLID, 1, RGB(255, 255, 255));
CPen* pOldPen = cdc->SelectObject(&aPen);
cdc->Rectangle(rec);
cdc->SelectObject(pOldPen);
*pResult = 0;
}
</lpnmlistview>
That's all.
When I select a row, it works. Then I select another row, it works but do not erase the previous rectangular. So my list control is full of rectangular.
Does anyone know how to erase the previous rectangular? Thanks in advance,
|
|
|
|
|
When you select an item in a list control, OnLvnItemchangedList1() gets called multiple times. Once for the previous item, and again for the current item. Change the pen color accordingly.
"Love people and use things, not love things and use people." - Unknown
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
Thank you for your answer, DavidCrow.
Actually, I have a int member of dialog to keep the old row.
So this function look like this:
void AlarmCompreMsgDig::OnLvnItemchangedList1(NMHDR *pNMHDR, LRESULT *pResult)
{
LPNMLISTVIEW pNMLV = reinterpret_cast(pNMHDR);
m_lstAlarmCompreMsg.SetItemState(-1, 0, LVIS_SELECTED);
int rowIndex = pNMLV->iItem;
CRect rec;
m_lstAlarmCompreMsg.GetItemRect(rowIndex, rec, LVIR_BOUNDS);
rec.top -= 2;
rec.bottom += 2;
CDC* cdc = m_lstAlarmCompreMsg.GetDC();
CPen aPen;
if (oldRowIndex == rowIndex){
aPen.CreatePen(PS_SOLID, 1, RGB(0, 0, 0));
}
else
{
aPen.CreatePen(PS_SOLID, 1, RGB(255, 255, 255));
oldRowIndex = rowIndex;
}
CPen* pOldPen = cdc->SelectObject(&aPen);
cdc->Rectangle(rec);
cdc->SelectObject(pOldPen);
*pResult = 0;
}
But there is something wrong here: this function is called 3 time totally. The 1st time it will erase the old rectangular, the second time it draw new rectangular, and then the last time it erase the new created rectangular.
I don't know why???
|
|
|
|
|
tataxin wrote: But there is something wrong here: this function is called 3 time totally.
Which is correct. The first time you select an item, it should get called once with a new state of LVSI_FOCUSED|LVSI_SELECTED . The next time you select an item, it should get called three times: the first time for the old item to remove the LVSI_FOCUSED style; the second time for the old item to remove the LVSI_SELECTED style; and a third time for the new item with a new state of LVSI_FOCUSED|LVSI_SELECTED . Make sense?
"Love people and use things, not love things and use people." - Unknown
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
oh, that's great. I try to find out this, but not success up to now.
And, can you explain some more, what should I change in my source code now? I tried some thing but not correct.
the structure of pNMLV is
typedef struct tagNMLISTVIEW {
NMHDR hdr;
int iItem;
int iSubItem;
UINT uNewState;
UINT uOldState;
UINT uChanged;
POINT ptAction;
LPARAM lParam;
} NMLISTVIEW, *LPNMLISTVIEW;
which member should I take and how to compare with LVIS_FOCUSED, LVIS_SELECTED?
In fact, I tried this
int x = pNMLV->uChanged;
if (x == ){
} else if (x == LVIS_FOCUSED){
} else if (x == LVIS_SELECTED){
}
but it's always be LVIS_FOCUSED|LVIS_SELECTED, so it always draws and draws
|
|
|
|
|
tataxin wrote: int x = pNMLV->uChanged;
Look at the two "state" members.
tataxin wrote: if (x == ){
You have to compare bits here.
"Love people and use things, not love things and use people." - Unknown
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
I solved it,
The final source code is;
if ((pNMLV->uChanged & LVIF_STATE) != LVIF_STATE)
return;
if (pNMLV->uOldState & LVIS_SELECTED)
{
}
else if (pNMLV->uNewState & LVIS_SELECTED)
{
}
It works, great!!!!!
Thank you for your suggestion, DavidCrow,
|
|
|
|
|
GetDIBits is returning ERROR_INVALID_PARAMETER. How to find out which parameter is incorrect. Is there a way?
Regards
|
|
|
|
|
Maybe posting code...
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.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
|
|
|
|
|
|
I read that article but still i am not able to find the bug in my code. here is my code
CDC dcMem;
CBitmap bmpMem;
CBitmap *oldbm = NULL;
CDC dc;
HDC hdc = ::GetDC(m_pOcxItem->m_hWnd);
dc.Attach(hdc);
LPVOID lpvBits = NUL
// save the device context
int nHandle = ::SaveDC(hDC);
// create a memory device context for offscreen drawing
if (!dcMem.CreateCompatibleDC(&dc))
_com_issue_error(HRESULT_FROM_WIN32(::GetLastError()));
if (!bmpMem.CreateCompatibleBitmap(&dc, rect.Width(), rect.Height()))
_com_issue_error(HRESULT_FROM_WIN32(::GetLastError()));
oldbm = dcMem.SelectObject(&bmpMem);
dcMem.SelectObject((HBRUSH)GetStockObject(WHITE_BRUSH));
// delesect the device dependent bitmap from the offscreen device context (must be out when GetDIBits is called)
dcMem.SelectObject(oldbm);
// get the header structure for a device independent bitmap (DIB) setup with the biggest possible palette
BITMAPINFO *bmi = (BITMAPINFO *) _alloca(sizeof(BITMAPINFOHEADER) + 256 * sizeof(RGBQUAD));
memset(&bmi->bmiHeader, 0, sizeof(BITMAPINFOHEADER));
bmi->bmiHeader.biSize = sizeof(BITMAPINFOHEADER);
// query for the bitmap information (NULL does a query)
int scanLineCount = GetDIBits(dcMem, bmpMem, 0, rect.Height(), NULL, bmi, DIB_RGB_COLORS);
if (!scanLineCount)
_com_issue_error(HRESULT_FROM_WIN32(::GetLastError()));
//here this is giving one of the parameter is incorrect
With the same code my another bitmap is getting printed with black background.
Any help is appreciated.
|
|
|
|
|
What happens if you change two lines of your code to this:
dcMem.CreateCompatibleDC(GetDC())
bmpMem.CreateCompatibleBitmap(GetDC(), rect.Width(), rect.Height()))
|
|
|
|
|
But GetDC() returns a HWND parameter where as CreateCompabileDC expect CDC* value
|
|
|
|
|
Are you sure? GetDC()//it returns CDC*
|
|
|
|
|
No GetDC returns HDC whereas createcompatable takes CDC pointer
|
|
|
|
|
No its not ture.
CDC dc*;
dc=GetDC();
HDC hdc;
hdc=::GetDC(HWND);
|
|
|
|
|
I made small modifications to your code and passed my window hwnd but the result is same. one of the parameter is incorrect
|
|
|
|
|
Can you tell me what do you want to do?
|
|
|
|
|
I know this is not the forum. I am printing activex controls. I was not able to print them. Last week i posted the problem in com forum. I found the solution. we have 4 legacy activex controls. out of them i am able to print two of them. One is raising one of the parameter is incorrect and another is printing with black background image. This is my problem.
|
|
|
|
|
Is it possible for you to print your bitmaps without any activex controls?
|
|
|
|
|
i found in the msdn GetDIBits returns zero if the header information is incorrect
BITMAPINFO *bmi = (BITMAPINFO *) _alloca(sizeof(BITMAPINFOHEADER) + 256 * sizeof(RGBQUAD));
memset(&bmi->bmiHeader, 0, sizeof(BITMAPINFOHEADER));
bmi->bmiHeader.biSize = sizeof(BITMAPINFOHEADER);
int scanLineCount = GetDIBits(dcMem, bmpMem, 0, rect.Height(), NULL, bmi, DIB_RGB_COLORS);
the value of bmi->bmiHeader.biSize is 40 while debugging.
what i have to do to pass the correct header information
|
|
|
|
|
|
Thanks for the article. But that didn't help. My code is working well for two activex controls but for another it is returning invalid argument(GetDIBits). I am assuming that i have to do something in the activex control. What i have to do in that. That i don't know. If any one knows please help me.
|
|
|
|
|