|
does anyone know how to deselect a list ctrl item ive tried
list.SetItemState(i, 0, 0);
but this doesnt work
anyone have any idea
thanks
|
|
|
|
|
You'll need to handle LVN_ITEMCHANGING and return FALSE to allow the item to be (un)checked or (de)selected and return TRUE to disallow a change.
Here's some code that might help.
Add this to your CMyListCtrl class definition as a protected function:
// Returns TRUE if the item is checked, false if it is not or uState == 0
inline BOOL IsChecked(UINT uState) {return
(uState ? ((uState & LVIS_STATEIMAGEMASK) >> 12) - 1 : FALSE);}
Here's a sample function for handling LVN_ITEMCHANGING:
void CTestListView::OnItemchanging(NMHDR* pNMHDR, LRESULT* pResult)
{
NM_LISTVIEW* pNMListView = (NM_LISTVIEW*)pNMHDR;
// If old state is unchecked and new state is checked
// then item is being checked.
if ((! IsChecked(pNMListView->uOldState)) &&
(IsChecked(pNMListView->uNewState)))
MessageBox("Item is being checked");
// If old state is checked and new state is unchecked,
// item is being unchecked
else if ((IsChecked(pNMListView->uOldState)) &&
(! IsChecked(pNMListView->uNewState)))
MessageBox("Item is being unchecked");
// return FALSE (or 0) to allow change, TRUE to prevent
*pResult = 0;
}//OnItemchanging
Select: m_ListCtrl.SetItemState(iItem, LVIS_SELECTED, LVIS_SELECTED);
Deselect: m_ListCtrl.SetItemState(iItem, 0, LVIS_SELECTED);
Focused: m_ListCtrl.SetItemState(iItem, LVIS_FOCUSED, LVIS_FOCUSED);
Unfocused: m_ListCtrl.SetItemState(iItem, 0, LVIS_FOCUSED);
|
|
|
|
|
Look at your call, the 3rd param is which state bits you want to change. Since you pass 0, no bits are changed. Pass LVIS_SELECTED in that parameter to turn off that state bit.
--Mike--
Personal stuff:: Ericahist | Homepage
Shareware stuff:: 1ClickPicGrabber | RightClick-Encrypt
CP stuff:: CP SearchBar v2.0.2 | C++ Forum FAQ
----
#include "witty-quote.h"
Pinky, are you pondering what I'm pondering?
I think so Brain, but how will we fit the hamster inside the accordion?
|
|
|
|
|
Has anyone created an SWF file from code?
I have heard this can be done.
Carl
|
|
|
|
|
Hello,
I have an app installing a mouse hook:
The hook setup function...
BOOL CXCapture::Setup()
{
DFUNC_DEF(CXCapture::Setup);
BOOL bRetVal;
m_hMouse = ::SetWindowsHookEx(WH_MOUSE, &MouseProc, ::AfxGetInstanceHandle(), NULL);
bRetVal = m_hMouse != NULL;
DFUNC_RET(bRetVal != FALSE, DSTR("Could not initialise mouse_hook (Err#%d)", GetLastError()));
return bRetVal;
}
The callback function...
LRESULT CALLBACK CXCapture::MouseProc(int nCode, WPARAM wParam, LPARAM lParam)
{
DFUNC_DEF(CXCapture::MouseProc);
DTRACE(DSTR("Hook: %d::%d, %d", nCode, wParam, lParam));
return ::CallNextHookEx(m_hMouse, nCode, wParam, lParam);
}
It happens that while the mouse is inside my application's (only) dialog box, the callback function (MouseProc) is called flawlessly, but when the mouse focus is out of the window, the OS simply unhooks it.
Therefore, whenever the mouse leaves the app's window focus, I am left out with no mouse hook whatsoever!!
My question is why this is happening and what should (or can) I do in order to solve this.
All feedback is greatly appreciated.
David Nimrod
|
|
|
|
|
The Callback function needs to reside in a DLL. the each process can load the dll into it's own address space.
Carl
|
|
|
|
|
Yeah, I've read about that just an hour ago or so and am modifying the code.
Thanks for the reply.
David
|
|
|
|
|
Hello everyone, i have question that has been a problem to me for couple of days. I am new to db programming so bare with me.
I have a login dialog where the user enters a password, and i am trying to search my employee db to find out of that person is in the db..I simply do not know how to search my db and see if the person is an employee.
here is my code...if anyone could help out, it would be great.
//getting password from and edit box
CEdit *ebptr = (CEdit *) GetDlgItem(IDC_TEXTBOX);
int i;
char str[80];
i = ebptr->GetWindowText(str, sizeof str-1);
//set my password
box_password = str;
///THIS IS WHERE I DONT HAVE ANY CLUE, HOW TO SEARCH MY DB //FOR THE PASSWORD, PLUS HOW DO I KNOW IF THE PASSWORD EXITS IN THE DATABASE?????
rsEmployeeSet.m_strFilter = "password = box_password";
rsEmployeeSet.Open();
|
|
|
|
|
CString strValue = _T("4");
int nValue = 0;
int nMatches = _tscanf (strValue.GetBuffer(0), _T("%d"), &nValue);
strValue.ReleaseBuffer();nMatches is zero. Why? 
/ravi
My new year's resolution: 2048 x 1536
Home | Articles | Freeware | Music
ravib@ravib.com
|
|
|
|
|
Hi Ravi,
I think you've got the wrong function here:
"The scanf function reads data from the standard input stream stdin and writes the data into the location given by argument."
It should be: _stscanf()
Maybe the ham sandwich's are running low.
Neville Franks, Author of ED for Windows www.getsoft.com and coming soon: Surfulater www.surfulater.com
|
|
|
|
|
Neville Franks wrote:
Maybe the ham sandwich's are running low.
In fact, they are! 
Many thanks for the _stscanf() correction  - I really must sleep more than 5 hours each night.
/ravi
My new year's resolution: 2048 x 1536
Home | Articles | Freeware | Music
ravib@ravib.com
|
|
|
|
|
Also, you don't need to call GetBuffer on CString as you are not writing to it's data. So somthing like this will be more efficiant:
CString strValue = _T("4");
int nValue = 0;
int nMatches = _stscanf (strValue, _T("%d"), &nValue);It saves you a whole function call... WAHOO!
Joel Holdsworth
|
|
|
|
|
Actually, two: both the GetBuffer() and the ReleaseBuffer() calls.
Oh, wait. You've added a call (the implicit cast to LPCTSTR).
Never mind .
Software Zen: delete this;
|
|
|
|
|
Exactly... they don't come free you know 
Joel Holdsworth
|
|
|
|
|
Hi,
I'm having problems painting with alpha in GDI. If I go:
backdc.FillSolidRect(&clientrect, 0xFF012345); What I end up with on the final bitmap surface is:
00 01 23 45 Does anyone know a way to overcome this?
Joel Holdsworth
|
|
|
|
|
The nearest function I can see to what you want would be the function AlphaBlend, though it looks
pretty fiddly to use.
Iain.
|
|
|
|
|
Yeah I've ended up using GDI+ now. It seems to the job nicly! I initially just wanted to avoid too many dependancies.
Joel Holdsworth
|
|
|
|
|
Hello,
How do I do about making an app replicate itself whenever a particular event occurs?
The application I have in hand is a multi-threaded one, which, at some point in time, has to create a new instance of itself dynamically and automatically, thereby replicating itself, with no user input whatsoever.
Can someone shed some light on the correct way to do this?
Thanks a lot.
|
|
|
|
|
That depends on what you mean by 'an app replicate itself'.
If you mean having a second process running the same code, in the same state, then you need to use CreateProcess() to start a second instance of your application, and pass sufficient information to the second instance for it to initialize itself to the same condition as the original. This will include information that lets you start an equivalent set of threads. This information could be passed in a file on the command line, or through some inter-process communication mechanism.
If you're looking for an API function like 'CreateDuplicateProcess()', I'm afraid you're out of luck.
Software Zen: delete this;
|
|
|
|
|
Thanks for the tip, Gary. Will take a look at CreateProcess and see if it allows me to accomplish what I need to.
David
|
|
|
|
|
I want to share some data between a thread that has Realtime priority (24) with another thread that has Normal priority (8). The Realtime thread is sending events to a midiOut device, the Normal thread is telling the Realtime thread what volume to use for the events. I might be able to get away without using any sort of exclusion mechanism, but I want to play safe. I’m concerned that a timer interrupt might occur in the middle of a data write, causing the read to be corrupted.
The obvious thing to do is to use a CRITICAL_SECTION, and to get both threads to do EnterCriticalSection()/LeaveCriticalSection() around the code that accesses the shared data. But I’m worried that doing EnterCriticalSection() in a Realtime thread will totally lock up Windows.
So a few questions:
1) If the Normal thread calls EnterCriticalSection(), does that prevent timer interrupts from happening until it calls LeaveCriticalSection()?
2) If the Realtime thread runs when the Normal thread owns the critical section object, so that the call to EnterCriticalSection() in the Realtime thread cannot complete until the Normal thread has released ownership of the critical section object, will this cause any problems? I’m worried that the Normal thread won’t be able to run because it’s been interrupted, and the Realtime thread won’t be able to run because it’s waiting for the critical section object.
3) Will all 32-bit versions of Windows behave in the same way with regard to this possible problem?
Thanks in advance.
Chris.
|
|
|
|
|
Hi Chris,
1) I don't think that I really do understand what you mean with timer interrupts, but the call to EnterCriticalSection() on the "normal" thread will cause the "realtime" thread to block on the EnterCriticalSection() call and this will give the processing cycles back to your "normal" thread, which will be happily executing until it calls LeaveCriticalSection(). Ie it is like having a high priority thread calling Sleep, so regardless of the priority of the thread, the processing time will be granted to other threads.
2) There is no need to worry about the "normal" thread, it will most probably still get the same amount of processing time (maybe even more than) that it used to get before. (Beware that I'm not saying that this processing time is enough for your normal thread to be 'responsive enough') The thing about the "realtime" thread is, you're correct it will block until the "normal" thread calls LeaveCriticalSection() so your realtime operation will probably stall. Instead of doing this you can call TryEnterCriticalSection on the realtime thread, and if it returns zero, you can skip trying to read that information and retry on the next loop.
3) As you probably already know, using real time priority in a thread is strongly discouraged and I'm not sure that all versions of Windows provides the same flexibility on multithreading (especially Win9x series) and you should expect lock-ups due to the realtime priority of your thread.
Besides that, if you're concerned about corruption in single read-write's of 32bit values, I'd like to remind you that in Win32 all 32 bit operations are guaranteed to be atomic, so there is no need for synchronization if you're just reading from or writing to an integer from multiple threads. There will be no problem if in one thread you are just reading an integer and in the other thread just updating it.
|
|
|
|
|
This is a fairly serious design issue. Windows is not a real time operating system, so you can't rely on it to do the right thing with regard to scheduling of threads in this way. The scenario you are describing with the thread being kicked off the CPU and struggling to get back on is 'priority inversion'.
Understanding the windows threading model is difficult, and it takes time. One of the simplest ways to think of it is that the main thread (what I believe is your 'normal' thread) does nothing but handle the message pump (event queue). Messages in the main thread are dealt with in two ways, synchronously (PostMessage) or asynchronously (SendMessage). PostMessage forces events to be dealt with immediately, SendMessage buffers the messages in a queue to be dealt with in FIFO order.
The main thread can only do one thing at a time, however it can be interrupted by another thread. If the main thread enters a critical section it prevents another thread from entering that region at the same time, until the main thread leaves the critical section. AFAIK another event having occured (a WM_TIMER message) is irrelevant because the timer message is buffered in the message pump.
Like the last poster recommended, I suggest that you don't bother changing thread priorities unless you can show that this provides a significant benefit at the end of the day - 'premature optimisation is the root of all evil'. It may be that with a single thread at priority 24 the main thread won't get any CPU or enough CPU to run the GUI.
2) rely upon the operating system doing something reasonable at a low level - like giving non-blocked threads a chance on the CPU in preference to blocked threads. This sounds like you are worried about 'deadlocks' but they generally occur only in situations where multiple resources are in contention.
Chris Hills wrote:
3) Will all 32-bit versions of Windows behave in the same way with regard to this possible problem?
Yes, although apparently their are kernels now available which sit on top of Windows that minimise this problem, but they are fairly expensive, and probably not redistributable. If you do need an operating system which can avoid this problem look at something like MaRTE[^]
Also, ensure that the frequency of WM_TIMER messages on the main thread occurs at the rate that you expect it too, especially with the priority of the main thread so high. From past experience WM_TIMER messages can only be set to arrive at a minimum of 10ms intervals, and even then I've seen that regularly blow out to 200ms. It may be more appropriate to poll the clock from the main thread and interpolate volumes between key-points.
If you can keep you head when all about you
Are losing theirs and blaming it on you;
If you can dream - and not make dreams your master;
If you can think - and not make thoughts you aim;
Yours is the Earth and everything that's in it.
Rudyard Kipling
|
|
|
|
|
I think you got this backwards:
"PostMessage forces events to be dealt with immediately, SendMessage buffers the messages in a queue to be dealt with in FIFO order."
I am pretty sure SendMessage dispatches message into the receiver's message queue immediately and PostMessage will add it to the queue.
|
|
|
|
|
Blake Miller wrote:
I think you got this backwards:
Whoops. Of course you're correct 
If you can keep you head when all about you
Are losing theirs and blaming it on you;
If you can dream - and not make dreams your master;
If you can think - and not make thoughts your aim;
Yours is the Earth and everything that's in it.
Rudyard Kipling
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
