C / C++ / MFC

22-Jun-06 9:50

Hi,

I am new to the forum. I am working on VC++ programming without using MFC... the code goes as follows

<the following="" code="" is="" inside="" the="" callback="" function="" of="" a="" dialogbox="" and="" run="" when="" start="" button="" pressed="">

<br />
<br />
for (frm=0;frm<frames;frm++){ //Read and Process each frame<br />
<br />
sprintf(Messages, "Processing Frame... %d",frm+1);<br />
SendDlgItemMessage(hDlg,IDT_PROCESS_STATIC2,WM_SETTEXT,0,(LPARAM) Messages);<br />
SendDlgItemMessage(hDlg, IDP_PROCESS_PROGRESS, PBM_SETPOS, (WPARAM)frm+1,0);<br />
UpdateWindow(hDlg);<br />
<br />
<more processing code that has nothing to do with the dialog box><br />
}<br />

when the program runs the progress bar and the text gets updated when the dialog box is in focus. when I open another application or when I minimize the dialog box when it is running(i.e. when it looses focus) and then return back, it doesn't get updated. Can someone tell me what property of the dialogbox I might have missed...

Thanks,
Naresh.

David Crow23-Jun-06 3:40

23-Jun-06 3:40

When the application is obscured by another, and the for loop exits, does the progress bar and text update one last time? If so, this indicates your primary thread is too busy with the processing to handle the paint-related messages. You'll need to employ a secondary thread to do the processing so the primary thread can remain responsive.

"The largest fire starts but with the smallest spark." - David Crow

"Judge not by the eye but by the heart." - Native American Proverb

Shrinaresh23-Jun-06 5:15

23-Jun-06 5:15

There are other lines of code within the for loop which are not related to paint-related messages and they are getting executed when the application is obscured. As you say, the progess bar and text are updated for about a second or so before it stops. I probably should start a secondary thread. Which of them should I move to the secondary thread? the process or the paint related messages?

David Crow23-Jun-06 5:35

23-Jun-06 5:35

Shrinaresh wrote:
Which of them should I move to the secondary thread? the process or the paint related messages?

See here for a better understanding of "worker" threads.

"The largest fire starts but with the smallest spark." - David Crow

"Judge not by the eye but by the heart." - Native American Proverb

Shrinaresh23-Jun-06 8:19

23-Jun-06 8:19

Thanks for the link... I shall read that and get back to you. Meanwhile, I am having one more problem. After WM_DIALOG is sent and the DialogBox is initialized, i want a button to be triggered automatically and the control to be transfered to the statements written for the button. How can I do that.

David Crow23-Jun-06 9:06

23-Jun-06 9:06

Shrinaresh wrote:
After WM_DIALOG is sent...

Is this a user-defined message (UDM)?

Shrinaresh wrote:
...i want a button to be triggered automatically and the control to be transfered to the statements written for the button. How can I do that.

At the end of handling the WM_INITDIALOG message, post a message to the dialog. In the handler for that message, simply call the same function that clicking the button would call.

"The largest fire starts but with the smallest spark." - David Crow

"Judge not by the eye but by the heart." - Native American Proverb

Shrinaresh23-Jun-06 10:02

23-Jun-06 10:02

I meant WM_INITDIALOG. I am sorry. I tried posting the message within WM_INITDIALOG but the button is called even before the dialogbox is displayed and the processing starts... I want the button to be invoked after the dialogbox is displayed. How do I do that?

David Crow26-Jun-06 3:29

26-Jun-06 3:29

Show the WM_INITDIALOG code.

"The largest fire starts but with the smallest spark." - David Crow

"Judge not by the eye but by the heart." - Native American Proverb

Shrinaresh27-Jun-06 7:06

27-Jun-06 7:06

case WM_INITDIALOG:<br />
	SetDlgItemText(hDlg, IDT_PROCESS_STATIC2, "Waiting for input...");<br />
	SendDlgItemMessage(hDlg, IDP_PROCESS_PROGRESS, PBM_SETRANGE, 0, MAKELPARAM(0, frames)); <br />
	SendDlgItemMessage(hDlg, IDP_PROCESS_PROGRESS, PBM_SETSTEP, (WPARAM)1,0);<br />
	return TRUE;

now, if i add PostMessage(hDlg, WM_COMMAND, MAKEWPARAM(BN_CLICKED, IDB_PROCESS_START), LPARAM(hDlg)); before return TRUE; the button is clicked and the processing starts even before the Dialog Box is displayed... i tried SendMessage too, didnt work Frown | :(

David Crow27-Jun-06 9:52

27-Jun-06 9:52

Is the code that responds to the BN_CLICKED message in a separate thread?

"The largest fire starts but with the smallest spark." - David Crow

"Judge not by the eye but by the heart." - Native American Proverb

Shrinaresh27-Jun-06 16:10

27-Jun-06 16:10

No its in the same thread...

David Crow28-Jun-06 2:29

28-Jun-06 2:29

See my suggestion here about employing a secondary thread.

"The largest fire starts but with the smallest spark." - David Crow

"Judge not by the eye but by the heart." - Native American Proverb

get millisecond

LeeeNN22-Jun-06 9:22

LeeeNN

22-Jun-06 9:22

How can I get millisecond time? CTime::GetCurrentTime() only return second precise.
Thank you. Sigh | :sigh:

Zac Howland22-Jun-06 9:29

Zac Howland

22-Jun-06 9:29

Use ::GetSystemTime(SYSTEMTIME* lpSystemTime);

If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week

Zac

LeeeNN22-Jun-06 10:24

LeeeNN

22-Jun-06 10:24

Thank you. But how accurate can I trust it?

Zac Howland22-Jun-06 10:27

Zac Howland

22-Jun-06 10:27

Its only as accurate as Windows will let it be, and how accurate your system clock is set to. It updates itself about ever 10 milliseconds, if memory serves me correct.

If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week

Zac

David Crow23-Jun-06 3:42

msvc keeps recompiling all

23-Jun-06 3:42

Zac Howland wrote:
It updates itself about ever 10 milliseconds...

For Windows NT. For Windows 9x, it's much less accurate at 55ms.

"The largest fire starts but with the smallest spark." - David Crow

"Judge not by the eye but by the heart." - Native American Proverb

ehh22-Jun-06 9:11

ehh

22-Jun-06 9:11

hello,
for the last day or so, every time i make a change to any source file, the compiler (msvc 6) asks to make all .sbr files and the main .bsc file. i know they're up to date--i can see that from windows. i've tried turning on and off "generate browse info" and rebuilding all, but to no avail. any suggestions?
thanks,
edward

Re: msvc keeps recompiling all

PJ Arends22-Jun-06 19:52

PJ Arends

22-Jun-06 19:52

Check the date and time of your stdafx.h file and any files that it includes. One of these files probably has it's time set to some point in the future.

You may be right
I may be crazy
-- Billy Joel --

Within you lies the power for good, use it!!!

problem walking all over an array

pblais22-Jun-06 9:04

pblais

22-Jun-06 9:04

I have a strange problem.. Well, strange for me.

I have written a dll called APM_DLL.cpp and its header APM_DLL.h.
I am using this dll in a dialog app calle CAPM_CPDlg.cpp and CAPM_CPDlg.h.

I declare the dll in the dialog as a pointer as follows..........
In CAPM_CPDlg.h, I have the following:

#include "APM_DLL.h"<br />
<br />
class CAPM_CPDlg : public CDialog<br />
{<br />
// Construction<br />
public:<br />
	CAPM_CPDlg(CWnd* pParent = NULL);	// standard constructor<br />
<br />
	APM_DLL	*MYDLL;<br />

Then in CAPM_CPDlg.cpp, I do the following:

BOOL CAPM_CPDlg::OnInitDialog()<br />
{<br />
	CDialog::OnInitDialog();<br />
<br />
	// IDM_ABOUTBOX must be in the system command range.<br />
	ASSERT((IDM_ABOUTBOX & 0xFFF0) == IDM_ABOUTBOX);<br />
	ASSERT(IDM_ABOUTBOX < 0xF000);<br />
<br />
	CMenu* pSysMenu = GetSystemMenu(FALSE);<br />
	if (pSysMenu != NULL)<br />
	{<br />
		CString strAboutMenu;<br />
		strAboutMenu.LoadString(IDS_ABOUTBOX);<br />
		if (!strAboutMenu.IsEmpty())<br />
		{<br />
			pSysMenu->AppendMenu(MF_SEPARATOR);<br />
			pSysMenu->AppendMenu(MF_STRING, IDM_ABOUTBOX, strAboutMenu);<br />
		}<br />
	}<br />
	MYDLL = new APM_DLL;<br />

Don't ask me why, I inherited this code.

I have also have the following declaration inside APM_DLL.h.

byte    RxBuffer[256];<br />

Anyways... in the main app, I make a call like MYDLL->GetSomething(). GetSomething() stores values in RxBuffer[0..n]. Then when I want to access this in the main app, I use MYDLL->RxBuffer[0..n]. This has worked great until this morning when I did the following in APM_DLL.h

byte    ROM_Buffer[100];<br />
byte    RxBuffer[256];<br />

Now, if I put a break inside the actual dll and look at RxBuffer, it is ok. Then when I put a break in the main app right after MYDLL->GetSomething, MYDLL->RxBuffer is trashed. If I comment out the ROM_Buffer declaration, everything works fine inside the dll and out It only gets slammed if I compile the ROM_Buffer declaration. I have moved that declaration after the declaration of RxBuffer and ahead of a variable that I don't need to access from the main app. Everything seems to be working. But, I think this is only a band-aid and I am still walking over something important.

By the way... if I make ROM_Buffer[200], I get the following crash error

---------------------------
Microsoft Visual C++ Debug Library
---------------------------
Debug Assertion Failed!

Program: D:\Projects\Motorola\GS Iden APM\Software\Release\APM_CP.exe
File: dbgheap.c
Line: 1099

Expression: _pLastBlock == pHead

For information on how your program can cause an assertion
failure, see the Visual C++ documentation on asserts.

(Press Retry to debug the application)
---------------------------
Abort Retry Ignore
---------------------------

Any ideas and/or suggestions?

Regards
Pierre

Re: problem walking all over an array

Zac Howland22-Jun-06 9:27

Zac Howland

22-Jun-06 9:27

Chances are the problem is in the dll code since you are not doing any heap allocations in this code. I take it that APM_DLL is a class that is exposed from the dll (that is, it should have AFX_EXT_CLASS or __declarspec(dllexport) prior to the class name)? That being the case, what is it trying to do? The code relating to your GetSomething call would be helpful to debug your problem.

If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week

Zac

Re: problem walking all over an array

pblais22-Jun-06 10:21

pblais

22-Jun-06 10:21

wellllllll... I had all of what you wanted typed in here and i accidently clicked on one of the stupid adverts in the left collum and lost it all...

If you send me your phone number at pblais@comcast.net, I can call you with all the details...

Thanks

Re: problem walking all over an array

David Crow23-Jun-06 3:49