Re: Keyboard response in a dialog, not the main window--thanks a lot - C / C++ / MFC Discussion Boards

Shay Harel4-Dec-02 10:15

4-Dec-02 10:15

Hi,

I have an application that adds lots of stuff into a list box.
How can I make sure that always the last item that was added will be displayed at the bottom of the list box without having to scroll to it ?

Thanks

Shay Harel

Re: List box scroll to bottom

Roger Stewart4-Dec-02 10:56

Roger Stewart

4-Dec-02 10:56

m_List.EnsureVisible( m_List.GetItemCount()-1, FALSE );

Roger Stewart
"I Owe, I Owe, it's off to work I go..."

Re: List box scroll to bottom

Shay Harel4-Dec-02 11:03

Shay Harel

4-Dec-02 11:03

Well, sounds great but.....

I dont see this method as a member function of CListBox .

Any more ideas ?

Shay

Re: List box scroll to bottom

Alvaro Mendez4-Dec-02 11:55

Alvaro Mendez

4-Dec-02 11:55

It's actually a member of CListCtrl. You may consider switching to that instead -- it gives you more options. But if you can't, try using SetCurSel to select the last item. I don't remember if it causes the list to be automatically scrolled.

Regards,
Alvaro

Well done is better than well said. -- Benjamin Franklin
(I actually prefer medium-well.)

Re: List box scroll to bottom

Roger Stewart4-Dec-02 13:36

Roger Stewart

4-Dec-02 13:36

You should start using CListCtrl instead of CListBox. It has more features and, personally, I think it is easier to work with.

CListBox:
m_List.SetCurSel(m_List.GetCount()-1);

Win32 (works in any version of MFC):
Here is the 'old school' Win32 macro way to ensure that the last item is displayed (MFC is just a wrapper around Win32 calls, mostly):

ListView_EnsureVisible( hList, ListView_GetItemCount(hList)-1, FALSE );

Also, the macros ListView_EnsureVisible() and ListView_GetItemCount() are defined in commctrl.h

'F1' can go a long way...

Roger Stewart
"I Owe, I Owe, it's off to work I go..."

Re: List box scroll to bottom

georgiek504-Dec-02 15:17

georgiek50

4-Dec-02 15:17

I think what you need is (win32) LB_SETTOPINDEX. I think that's what it's called anyway.

Keyboard response in a dialog, not the main window--thanks a lot

Sean_Yang4-Dec-02 9:59

Sean_Yang

4-Dec-02 9:59

I am a new programmer, can't figure out why the keyboard doesn't responds. I traced the following code, the doesn't enter the code corresponding to keyboard at all.
Here I attached how the dialog is triggered. Hopefully someone can help me figure it out. Thanks a lot.

int APIENTRY WinMain(HINSTANCE hCurrentInst, HINSTANCE hPreviousInst, LPSTR lpszCmdLine, int nCmdShow)
{
.....
while (GetMessage(&msg, NULL, 0, 0)) {
TranslateMessage(&msg);
DispatchMessage(&msg);
}

}

LRESULT CALLBACK MainWndProc (HWND hwnd, UINT message, WPARAM wParam, LPARAM lParam)
{
....
hwnddlg = CreateDialog(app_instance, "PARAMETER_WINDOW_DATA", NULL, (DLGPROC) Parameter_Window_Exper);
}

BOOL CALLBACK Parameter_Window_Exper(HWND hWnd, UINT Message, WPARAM wParam, LPARAM lParam)
{
switch (Message) {
case WM_CHAR:
switch(wParam)
{
case '1':
record_data_pair(1);
break;
case '2'://0x32:
record_data_pair(2);
break;
case '3'://0x33:
record_data_pair(1);
break;
default:
break;
}
return FALSE;
}
.....
return FALSE;
}

Sean

Re: Keyboard response in a dialog, not the main window--thanks a lot

RicoH5-Dec-02 1:35

RicoH

5-Dec-02 1:35

I think the problems lies in this part of your code...

hwnddlg = CreateDialog(app_instance, "PARAMETER_WINDOW_DATA", NULL, (DLGPROC) Parameter_Window_Exper);

If you specify 'NULL' as owner of this window, the Desktop will be the parent. However, since this dialogbox doesn't have it's own messageque it won't receive anything.

So, if you do it like this, it should work just fine.

hwnddlg = CreateDialog(app_instance, "PARAMETER_WINDOW_DATA", hwnd, (DLGPROC) Parameter_Window_Exper);
Where 'hwnd' is the handle from your main window (in MainWndProc)

Don't think you are, know you are...

Re: Keyboard response in a dialog, not the main window--thanks a lot

Sean_Yang5-Dec-02 7:03

Sean_Yang

5-Dec-02 7:03

Shall I declare a global HWND hmainwnd; and within the WinMain() function.

if (!(hwnd = CreateWindow ("MAINWINDOW", "1DoF Stepper Motor Haptic Device",
WS_OVERLAPPEDWINDOW,
0,0,
800, 150,
NULL, NULL, hCurrentInst, NULL)))
return (0);
hmainwnd = hwnd;//like this???

and then when triggering the dialog, I do
hwnddlg = CreateDialog(app_instance, "Experiment", hmainwnd, (DLGPROC) Parameter_Window_Exper);

But I did so, it doesn't work.
The sequence triggered is as following: Main->Dialog_Data->Dialog_Experiment. I want the Dialog_Experiment to respond my keyboard.

My code(simplified) is like this:should I change all NULL to hmainwnd?
~~~~~~~~~~~~~~~~~~~~~~~~~~~`
extern HWND hwnddlg;
int APIENTRY WinMain(HINSTANCE hCurrentInst, HINSTANCE hPreviousInst, LPSTR lpszCmdLine, int nCmdShow)
{
...
if (!RegisterClass (&wc)) {
MessageBox (NULL, (LPCTSTR) "WinMain(): RegisterClass() failed",
(LPCTSTR) "Error!", MB_OK | MB_ICONEXCLAMATION);
return(FALSE);
while (GetMessage(&msg, NULL, 0, 0)) {
TranslateMessage(&msg);
DispatchMessage(&msg);
}

return (msg.wParam);
}
------------------------------------------
LRESULT CALLBACK MainWndProc (HWND hwnd, UINT message, WPARAM wParam, LPARAM lParam)
{
...
hwnddlg = CreateDialog(app_instance, "PARAMETER_WINDOW_DATA", NULL, (DLGPROC) Parameter_Window_Data);
}
-------------------------------------------
BOOL CALLBACK Parameter_Window_Data(HWND hWnd, UINT Message, WPARAM wParam, LPARAM lParam)
{
...
DestroyWindow(hWnd);
hwnddlg = CreateDialog(app_instance, EXPER_INTRO_DIALOG, NULL, (DLGPROC) Parameter_Window_Exper);
}
-------------------------------------------
BOOL Parameter_Window_Exper(HWND hWnd, UINT Message, WPARAM wParam, LPARAM lParam)
{
case WM_CHAR:
switch(wParam)
{
case '1':
MessageBox(hmainwnd, "Happen?", "TEST Box", MB_OK);

record_data_pair(1);
break;
case '2'://0x32:
record_data_pair(2);
break;
case '3'://0x33:
record_data_pair(1);
break;
default:
break;
}
return FALSE;

}

Thanks
Sean

Re: Keyboard response in a dialog, not the main window--thanks a lot

RicoH5-Dec-02 7:37

RicoH

5-Dec-02 7:37

I don't think you have to declare a global variable.
This should do the trick (and if not, I'll need to see more of your code):

LRESULT CALLBACK MainWndProc (HWND hwnd, UINT message, WPARAM wParam, LPARAM lParam)
{
...
hwnddlg = CreateDialog(app_instance, "PARAMETER_WINDOW_DATA", hwnd, (DLGPROC) Parameter_Window_Data);
}
-------------------------------------------
BOOL CALLBACK Parameter_Window_Data(HWND hWnd, UINT Message, WPARAM wParam, LPARAM lParam)
{
...
DestroyWindow(hWnd);
hwnddlg = CreateDialog(app_instance, EXPER_INTRO_DIALOG, hWnd, (DLGPROC) Parameter_Window_Exper);
}
-------------------------------------------

You see, just give it the handle to the parent in stead of using NULL (which means the desktop)

Don't think you are, know you are...

Re: Keyboard response in a dialog, not the main window--thanks a lot

Sean_Yang5-Dec-02 8:33

Sean_Yang

5-Dec-02 8:33

I did so as you posted, but the child dialog (EXPER_INTRO_DIALOG) can't be displayed. I wonder if the problem now(not display at all) is because DestroyWindow(hWnd) has killed the parent dialog.

Anyway, I guess I can get my program done under your help.

Regards,
Sean

HELP! silly memory release problem( forJames.R.Twine)

smartptr4-Dec-02 9:46

smartptr

4-Dec-02 9:46

Hello gurus,
I have a similar question to what was discussed
here

Suppose I have a function to split a text file into 10 parts like (The first 9 parts are 90% of the total text and the last part contains whatever remaining).

When the dialog closes I have a memory leak problem related to pBuffer which I'm not releasing, as is expected. How and where do I free pBuffer?

the code goes like(not too commented)

BOOL CReadPercentDlg::ReadPercent(LPCTSTR strFileName)<br />
{<br />
HANDLE hTheFile;<br />
hTheFile = CreateFile(strFileName,GENERIC_READ|GENERIC_WRITE,FILE_SHARE_READ,NULL,OPEN_EXISTING,FILE_ATTRIBUTE_NORMAL,NULL);<br />
if(!hTheFile)<br />
	return FALSE;<br />
DWORD dwFileSize = ::GetFileSize(hTheFile, NULL );<br />
DWORD dw10Percent = (DWORD)( dwFileSize *.10 );<br />
BYTE *pBuffer = new BYTE[ dw10Percent ];<br />
<br />
    if( !pBuffer )<br />
    {<br />
        TRACE("Not enough mmemory");<br />
		return FALSE;//( ERROR_NOT_ENOUGH_MEMORY );<br />
    }<br />
	<br />
	DWORD dwStatus = 0;<br />
        DWORD dwRead = 0;<br />
	DWORD dwTotalRead = 0;<br />
//read each 10% section of a file<br />
	for(int i=0;i<9;i++)<br />
	{<br />
		<br />
            dwStatus = ::ReadFile( hTheFile, pBuffer, dw10Percent, &dwRead, NULL );<br />
		if( dwStatus != ERROR_SUCCESS )<br />
		{<br />
<br />
		}	<br />
	<br />
		//int nLen = strlen((LPSTR)pBuffer);<br />
		pBuffer[dw10Percent] = '\0';<br />
//		TRACE((LPSTR)pBuffer);<br />
		OutputDebugString((LPSTR)pBuffer);<br />
		dwTotalRead+=dw10Percent;<br />
	}<br />
<br />
	pBuffer[0] = '\0';	<br />
//-> cannot do next line ??<br />
//	delete pBuffer;<br />
	pBuffer = NULL;<br />
//now calculate whatever is remaining<br />
	DWORD dwLeft = 0;<br />
	dwLeft = dwFileSize - dwTotalRead;<br />
	if(dwLeft!=0)<br />
	{<br />
		TRACE("\nLeft %u",dwLeft);<br />
//		delete pBuffer;	<br />
//		pBuffer[0] = '\0';<br />
//		pBuffer = NULL;	<br />
<br />
		pBuffer = new BYTE[dwLeft];<br />
		if(pBuffer==NULL)<br />
			return FALSE;<br />
<br />
		dwStatus = ::ReadFile( hTheFile, pBuffer, dwLeft, &dwRead, NULL );<br />
		if( dwStatus != ERROR_SUCCESS )<br />
		{<br />
<br />
<br />
<br />
		}	<br />
		pBuffer[dwLeft] = '\0';<br />
		TRACE("\nLast :\n");<br />
		TRACE((LPSTR)pBuffer);<br />
		//where do I release pBuffer?<br />
		//the line below causes an assertion failure.<br />
		//memory check error at 0x004228B7 = 0x00, should be 0xFD.<br />
<br />
		//delete []pBuffer;<br />
		//	pBuffer = NULL;<br />
	}<br />
<br />
	//where do we free pBuffer?<br />
	//following line again causes <br />
	//memory check error at 0x004228B7 = 0x00, should be 0xFD.<br />
	//	delete[] pBuffer;<br />
	//but if I do not release pBuffer by now, I get a memory leak.<br />
	pBuffer = NULL;<br />
	return TRUE;<br />
<br />
}

Also, is there any better way to read in such percents of text files?

Thanks a lot in advance. Smile | :)

Looking for a lurking sig!

Re: HELP! silly memory release problem( forJames.R.Twine)

Christian Graus4-Dec-02 9:52

Christian Graus

4-Dec-02 9:52

smartptr wrote:
(The first 9 parts are 90% of the total text and the last part contains whatever remaining).

Smile | :)

smartptr wrote:
Also, is there any better way to read in such percents of text files?

If you used C++ file handling ( iostreams ), you could read into std::strings, which would clean up after themselves. Otherwise, you need to delete [] the buffer at the end of this function. There is no-where else to do it, you create it on the heap within this function, therefore once you leave this function, the pointer has leaked, you no longer have a reference to it.

Christian

No offense, but I don't really want to encourage the creation of another VB developer. - Larry Antram 22 Oct 2002

Hey, at least Logo had, at it's inception, a mechanical turtle. VB has always lacked even that... - Shog9 04-09-2002

Again, you can screw up a C/C++ program just as easily as a VB program. OK, maybe not as easily, but it's certainly doable. - Jamie Nordmeyer - 15-Nov-2002

Re: HELP! silly memory release problem( forJames.R.Twine)

smartptr4-Dec-02 9:56

smartptr

4-Dec-02 9:56

Thanks for your reply.

Can I make the buffer a member variable of the dialog class?(and when the dialog is closing:

delete pBuffer;<br />
pBuffer = NULL;

)
to avoid a memory leak?

Re: HELP! silly memory release problem( forJames.R.Twine)

Christian Graus4-Dec-02 10:33

Christian Graus

4-Dec-02 10:33

Sure - no problems at all, except that you need to delete [] pBuffer, not delete it, it is an array.

Christian

No offense, but I don't really want to encourage the creation of another VB developer. - Larry Antram 22 Oct 2002

Hey, at least Logo had, at it's inception, a mechanical turtle. VB has always lacked even that... - Shog9 04-09-2002

Again, you can screw up a C/C++ program just as easily as a VB program. OK, maybe not as easily, but it's certainly doable. - Jamie Nordmeyer - 15-Nov-2002

Re: HELP! silly memory release problem( forJames.R.Twine)

Navin4-Dec-02 10:37

Navin

4-Dec-02 10:37

smartptr wrote:
//where do we free pBuffer?
//following line again causes
//memory check error at 0x004228B7 = 0x00, should be 0xFD.
// delete[] pBuffer;
//but if I do not release pBuffer by now, I get a memory leak.

It could be that there is a memory problem elsewhere inthe code that is trashing something and causing the delete to fail. This line looks suspicious:

<br />
pBuffer[dw10Percent] = '\0';<br />

It looks like you are accessing the array beyond its end. You allocated it as having dw10Percent items, which means the highest index it can have is (dw10Percent - 1).

There may be other things like that, too, that are causing problems.

Even a broken clock is right twice a day.

Failed Serialize function

act_x4-Dec-02 9:37

act_x

4-Dec-02 9:37

I have an MDI application and I implement the serialize function to read data in . In case the File read is not a trusted file , how do i abort the process of displaying the view. i want the document to not show the view but to just display an error message. Thank you .

Problem with Dumping Object (new of MFC) and FreeLibrary

leander4-Dec-02 8:33

leander

4-Dec-02 8:33

I'm french, so I hope you will excuse me for my poor english.

I have an MFC application which load lot of DLL. In this Dll I make allocation with new, so It use the MFC checking system for leak memory.

And when I terminate my application, I free all my librairies with function 'FreeLibrary()'. But If I have some leak memory in a DLL the MFC Dumping Leak will display to me :
Dumping Object->
#File Error#, etc....
I don't have the FileName.

MFC can't find the name of the File (__FILE__) because the memory where the FileName where store was allocate in the DLL where the 'new' is made. So when I call the function 'FreeLibrary()' on my DLL, all memory which containt '__FILE__' were release.

So how can I do to see my memory leak even if i have call FreeLibrary ? (I must call function FreeLibrary() otherwise I will have lot of problems with my application).

Thanks you for reading my question.

Re: Problem with Dumping Object (new of MFC) and FreeLibrary

Nick Parker4-Dec-02 8:56

Nick Parker

4-Dec-02 8:56

leander wrote:
So how can I do to see my memory leak even if i have call FreeLibrary ? (I must call function FreeLibrary() otherwise I will have lot of problems with my application).

I am not biblically familiar with MFC as I had to lookup exactly what FreeLibrary() does. Anytime you use the new operator to allocate memory on the heap you will need to release it with the delete operator. It appears that the FreeLibrary *only* handles ref counting and will unmap the module from the address space itself, I would belive that you still need to handle the internal allocation/deallocation of memory yourself. Hope this helps. Smile | :)

Nick Parker

Not everything that can be counted counts, and not everything that counts can be counted. - Albert Einstein

Re: Problem with Dumping Object (new of MFC) and FreeLibrary

Ranjan Banerji4-Dec-02 9:26

Ranjan Banerji

4-Dec-02 9:26

Cant you turn off FreeLibrary, only for so long as to find the memory leak?

Also, Are the DLLs in debug mode? To completely debug the application, both your application and DLLs should be built in Debug mode.

Re: Problem with Dumping Object (new of MFC) and FreeLibrary

leander4-Dec-02 21:58

leander

4-Dec-02 21:58

I try to turn off the call() to FreeLibrary() to Debug my leak, but it's little complicate to do it, because I have static object how make allocation with a memory manager (only for malloc and free, not for new and delete). So if I don't call the FreeLibrary the destructor off my static object is not call, and i have some crash when I free my memory manager.

So for the moment, to debug leak, I remove the Freeliberary() and I don't release my memory manager to see the leak.

But I hope to find an other solution without changing some code to with memory leak.

My application and my DLL are compile in Debug with option "Multithread DLL"

Re: Problem with Dumping Object (new of MFC) and FreeLibrary

Alvaro Mendez4-Dec-02 9:34

Alvaro Mendez

4-Dec-02 9:34

I don't understand why failing to call FreeLibrary causes a lot of problems in your app. But that's what I would do: comment out the FreeLibrary calls (temporarily) and see if you can get a better reading on where the leaks are occurring.

If that doesn't work, let me know and I'll help you find the leaks the hard way. Dead | X|

Regards,
Alvaro

Well done is better than well said. -- Benjamin Franklin
(I actually prefer medium-well.)

drag on hDC

Nicolas Siatras4-Dec-02 7:28

Nicolas Siatras

4-Dec-02 7:28

Hello,
I have created a dll in c that can draw on a picture box. But the problem is that i need to be able to place new lines or rect or ellipses... using the mouse and also be able to move or resize them (using the mouse) after placement. Any ideas???

Thank you in advance
Nicolas Siatras

Drawing on a device independent bitmap

David F Zimny4-Dec-02 6:50

David F Zimny

4-Dec-02 6:50

Is there any way to create a device context that will let me draw on a bitmap that isn't necessarily the same format as the display device?

For example, if I created a 640 x 480 8-bit bitmap wit CreateDIBSection, could I somehow create a device context to draw text on the bitmap even if the primary display is 24-bit?

Re: Drawing on a device independent bitmap

Christian Graus4-Dec-02 9:55

Christian Graus

4-Dec-02 9:55

You need a DIBSection. To be honest, there is no reason I can see ever to use anything else. A DIBSection is a DIB, but it can be selected into a DC and drawn on with GDI functions as if it was a DDB.

Christian

No offense, but I don't really want to encourage the creation of another VB developer. - Larry Antram 22 Oct 2002

Hey, at least Logo had, at it's inception, a mechanical turtle. VB has always lacked even that... - Shog9 04-09-2002

Again, you can screw up a C/C++ program just as easily as a VB program. OK, maybe not as easily, but it's certainly doable. - Jamie Nordmeyer - 15-Nov-2002

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.