C / C++ / MFC

20-May-04 6:43

Hi,
I'm trying to view some resultes in a list box and I can not see all of them because I do no have a horizontal scroll bar. I checked the horizontal scroll bar in the options of the List box, but still I get only the vertical scroll bar.
tx...

Mirelutza

David Crow20-May-04 9:20

David Crow

20-May-04 9:20

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)

Mirelutza20-May-04 10:28

20-May-04 10:28

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

*Dreamz20-May-04 18:38

*Dreamz

20-May-04 18:38

>SendMessage(hDlg,LB_SETHORIZONTALEXTENT,25,0);
SendMessage(hListBox,LB_SETHORIZONTALEXTENT,25,0);
Message has to go to the ListBox window.

Mirelutza20-May-04 21:16

20-May-04 21:16

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

Mirelutza20-May-04 21:44

Catch Return Key in CListBox

20-May-04 21:44

Hi again...
I found the problem! It was because of the third parameter! So thanx for your help!!!

Mirelutza

aturki20-May-04 5:39

aturki

20-May-04 5:39

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.

Re: Catch Return Key in CListBox

Iain Clarke, Warrior Programmer20-May-04 5:59

Iain Clarke, Warrior Programmer

20-May-04 5:59

Just a quick search on CodeProject for PreTranslateMessage finds a long list of
articles.
e.g. Keyboard messages/accelerators handling in MFC dialog based applications
[^].

Iain.

Re: Catch Return Key in CListBox

Andrew Quinn AUS20-May-04 6:06

Andrew Quinn AUS

20-May-04 6:06

Hi there,

You could use PreTranslateMessage, e.g.

BOOL CMyDlg::PreTranslateMessage(MSG* pMsg) 
{
	BOOL bEatMsg = FALSE;

	if (pMsg && pMsg->message == WM_KEYDOWN)
	{
		// is this our listbox?
		if (pMsg->hwnd == m_ctrlListBox.GetSafeHwnd())
		{
			// yes.. what was the key pressed?
			switch (pMsg->wParam)
			{
			case 13: // Enter
				// Do what you need to do...
				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

Use pipe without WriteFile Func

Anonymous20-May-04 5:39

Anonymous

20-May-04 5:39

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.

Re: Use pipe without WriteFile Func

valikac20-May-04 6:10

Re: Use pipe without WriteFile Func

20-May-04 6:10

So what is the problem?

Kuphryn

Member 42102520-May-04 6:32

Member 421025

20-May-04 6:32

Write Your own Myprintf version and call writefile from that function and change printf to Myprintf. Copy printf from printf.c maybe available someplace

Long Wait for a Mutex

sweep12320-May-04 5:27

sweep123

20-May-04 5:27

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 />
/* This procedure will wait for a Mutex before allowing any<br />
write access to the shared area. */<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?

valikac20-May-04 6:14

20-May-04 6:14

Assuming you call CloseHandle() right after ReleaseMutex(), the mutex handle that is passed to WaitForSingleObject() is no longer valid.

Kuphryn

sweep12320-May-04 6:21

sweep123

20-May-04 6:21

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?

valikac20-May-04 6:31

20-May-04 6:31

Call CloseHandle() when the process is done with the mutex such as right before the process terminates.

Kuphryn

sweep12320-May-04 6:36

sweep123

20-May-04 6:36

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?

valikac20-May-04 6:45

20-May-04 6:45

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

Grahamfff20-May-04 10:18

Grahamfff

20-May-04 10:18

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 />
      /* This procedure will wait for a Mutex before <br />
allowing any write access to the shared area. */<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

Paul Ranson20-May-04 10:34

Paul Ranson

20-May-04 10:34

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

Grahamfff20-May-04 10:45

Grahamfff

20-May-04 10:45

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