|
I think you have horizontal and vertical confused. A horizontal scroll bar is on the bottom, and a vertical scroll bar is on the right. A horizontal scroll bar is not going to care how many items are in the list, and a vertical scroll bar is not going to care how long each item is. See the difference?
It sounds like you need to send the LB_SETHORIZONTALEXTENT message. Or if you are using MFC, call the SetHorizontalExtent() method.
"The pointy end goes in the other man." - Antonio Banderas (Zorro, 1998)
|
|
|
|
|
Hello again,
I tried to send a message like you told me,but still it's not working. Am I doing something wrong by calling:
SendMessage(hDlg,LB_SETHORIZONTALEXTENT,25,0);
Regards
Mirelutza
|
|
|
|
|
>SendMessage(hDlg,LB_SETHORIZONTALEXTENT,25,0);
SendMessage(hListBox,LB_SETHORIZONTALEXTENT,25,0);
Message has to go to the ListBox window.
|
|
|
|
|
Hi,
The handle to the list box is an int and in the SendMessage function the firs parameter si HWND, and even if I upcast the int to HWND it's not working...
The ListBox is in the hDlg window which is a dialog box. In the dialog box I have some more objects, so if I send the message to the Dlg window is not right.
I even tried to get the HWND parameter of the listbox with getdlgitem function and still it's not working.Do you have any sugestions...???
Tx
Mirelutza
|
|
|
|
|
Hi again...
I found the problem! It was because of the third parameter! So thanx for your help!!!
Mirelutza
|
|
|
|
|
How I can catch Return Key when the focus is in a CListBox control.
I tried with OnKeyDown() method but I can't catch it.
|
|
|
|
|
|
Hi there,
You could use PreTranslateMessage, e.g.
BOOL CMyDlg::PreTranslateMessage(MSG* pMsg)
{
BOOL bEatMsg = FALSE;
if (pMsg && pMsg->message == WM_KEYDOWN)
{
if (pMsg->hwnd == m_ctrlListBox.GetSafeHwnd())
{
switch (pMsg->wParam)
{
case 13:
bEatMsg = TRUE;
break;
}
}
}
return bEatMsg?TRUE:CDialog::PreTranslateMessage(pMsg);
}
Here's the function declaration:
public:
virtual BOOL PreTranslateMessage(MSG* pMsg);
Remember to put the declaration in your AFX_VIRTUAL(CMyDlg) macros so as not to confuse ClassWizard
Hope this helps,
Andy
|
|
|
|
|
I have a Pipe client which need to send data to the Pipe server. It used to send the data to screen via print statements. However, now it needs to use pipes to send data to another process (the server). I wish to change as little as possible on the orginial code. I don't want to have to go back and replace all of the print statements with WriteFile statements if it can be avoided.
|
|
|
|
|
So what is the problem?
Kuphryn
|
|
|
|
|
Write Your own Myprintf version and call writefile from that function and change printf to Myprintf. Copy printf from printf.c maybe available someplace
|
|
|
|
|
Can someone tell me if I have got this scheme correct for using Mutex's for controlling access to shared data (memory mapped) between two programs.
Each program creates the Mutex as follows:-
m_hMutex = ::CreateMutex(NULL,FALSE,"CSLSharedMemLock");
Each program uses the following procedure before read/write operations:-
<big>bool WaitForMutex(void)<br />
{<br />
<br />
<br />
if(m_hMutex)<br />
{<br />
if (::WaitForSingleObject(m_hMutex,INFINITE) == WAIT_OBJECT_0)<br />
{<br />
return true;<br />
}<br />
return false;<br />
}</big>
then we read data or write data and release the handle.
<big>ReleaseMutex(m_hMutex);</big>
and then
<big>CloseHandle (m_hMutex);</big>
The 2 programs (EXE and DLL) work OK without using the Mutex, but lock up as soon as I start to use a Mutex; i.e. never return from WaitForMutex in the EXE program.
I did check the value of the HANDLE and were as follows:-
In the DLL 0x00000084 and in the EXE 0x00000128 and the Mutex name is the same in both.
I want to protect the shared data, any comments?
|
|
|
|
|
Assuming you call CloseHandle() right after ReleaseMutex(), the mutex handle that is passed to WaitForSingleObject() is no longer valid.
Kuphryn
|
|
|
|
|
Does this mean that I hace to Create the Mutex again before doing another WaitForSingleObject?
So for each data access do I do the following
Create(M);
WaitForSingleObject
ReleaseMutex(m);
CloseHandle(m);
This that correct?
|
|
|
|
|
Call CloseHandle() when the process is done with the mutex such as right before the process terminates.
Kuphryn
|
|
|
|
|
Thanks, got it working, one other question, will the processing for protecting the data be under 100msec;
i.e. the time to:-
Create(m)
WaitForSingleObject(m)
ReleaseMutex(m)
I know is a very general question but an order of magnitude would be helpful.
I have a timer checking for new data, the rate could be 100msec to several seconds?
|
|
|
|
|
There is no need to create the mutex each time. Just create it once and close it when the process terminates or when it is no longer needed throughout the process lifetime.
Kuphryn
|
|
|
|
|
I am now confused!
If I create the Mutex, then when I go into my routine which I WaitForSingleObject, then I wait forever. This was my query.
But if I create it each time I go into my WaitForMutex routine, I get it; i.e. my program works. See updated WaitForMutex routine.
<big>bool WaitForMutex(void)<br />
{<br />
<br />
<br />
m_hMutex = ::CreateMutex(NULL,FALSE,"CSLSharedMemLock");<br />
if(m_hMutex)<br />
{<br />
if (::WaitForSingleObject(m_hMutex,INFINITE) == WAIT_OBJECT_0)<br />
{<br />
return true;<br />
ReleaseMutex(m_hMutex);<br />
}<br />
return false;<br />
}<br />
}</big>
My EXE uses CSLSharedMemLock for the Mutex and the libray (DLL) also uses CSLSharedMemLock as the Mutex name.
Sweep123 working from home!
grahamfff
|
|
|
|
|
Your EXE and DLL both need to call CreateMutex,
hMutex = ::CreateMutex ( 0, FALSE, "CSLSharedMemLock" ) ;
Now nobody owns the mutex but everybody has a handle to it.
So when you need the mutex call,
void EnterMutex ()
{
::WaitForSingleObject ( hMutex, INFINITE ) ;
}
Now you own it, and when you're done with it you must call ReleaseMutex
void LeaveMutex ()
{
::ReleaseMutex ( hMutex ) ;
}
I think your problem is probably a confusion over ownership. The two functions above are naturally wrapped up into the constructor/destructor of a class, and error returns handled by throwing exceptions, but that's another discussion really.
Paul
|
|
|
|
|
What you say makes sence, but in my situation if I call EnterMutex() then I have a long wait!!
I have checked that the DLL has released the mutex, so it should be 'unowned'.
Still confused!?!
Graham.
grahamfff
|
|
|
|
|
So you must have some sort of deadlock, the question is where, and I don't think we can help you here without all the code.
I think that a single thread can 'Wait' for a Mutex multiple times and the wait will always complete immediately. But each wait must be accompanied with a matching ReleaseMutex. Perhaps there's something like that but with insufficient releases happening in your code flow?
Paul
|
|
|
|
|
You only check the WAIT_OBJECT_0 returned from WaitForSingleObject(). Check for other possible return values.
Post the code that creates the mutex in the EXE.
Kuphryn
|
|
|
|
|
I noticed that whenever I use the "<<" bitwise left shift operator. The result value is incorrect. The bitwise right shift is correct. Whats up with this? Any ideas? ie 49<<3 should be 136, but I get 392.
Thanks
|
|
|
|
|
|
I assume he is taking it as 8bits and therefore the top bit falls off the end! 
Ant.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
