C / C++ / MFC

Re: Initializing a CProgressCtrl Object Inside CDialog :: MFC

15-Apr-02 16:24

Right now, I just want to get it working. To test it out, I want to update it ever 25 milliseconds.

Here is the code:

-----
CMyDialog mDlg;

for (int i = 0; i < 100; ++i)
{
mDlg.SetNewProgressPos(i);
::Sleep(25);
}

if (mDlg.DoModal == IDOK)
{}
-----
// void SetNewProgressPos(int newPos)
// {
// m_MyProgressBar.SetPos(newPos);
// }

The code above does not work though. The program crashes. The code that causes it to crash is this:

// m_MyProgressBar.SetPos(newPos);

I tried calling that function from inside the dialog box as well as outside. That line crashes the program both times.

Kuphryn

Diarrhio15-Apr-02 16:48

Re: Initializing a CProgressCtrl Object Inside CDialog :: MFC

15-Apr-02 16:48

Ok. I see what you are trying to do. You need to create a class for your dialog (by deriving from CDialog. Use Class Wizard), and do all of this in there. None of the controls for your dialog have been created when you are doing your loop. They don't get created until you call DoModal, and they get destroyed by the time DoModal returns. When I say created and destroyed, I don't mean the object gets destroyed. Rather, the Handle to the control that the progress control object wraps is destroyed. And you the functions that you are calling are thin wrappers to API calls using the Handle. Thus the crash.

So, as I said, create a class for your dialog. Add the control to the class using class wizard. Also add a button to the dialog, and add a button clicked handler. Then, when the button gets pushed, add your for loop in the button handler.

Hope that helps.

valikac15-Apr-02 16:58

Re: Initializing a CProgressCtrl Object Inside CDialog :: MFC

15-Apr-02 16:58

Yes! Thanks. Your pointer was key to the fix.

Is there a way to *interrupt* the progress? For example, let say the user wants to cancel out, but the program is still processing something and the progressbar is not at 100. Is there a way to implement a cancel button to exit completely?

Kuphryn

Diarrhio15-Apr-02 17:08

Re: Initializing a CProgressCtrl Object Inside CDialog :: MFC

15-Apr-02 17:08

Yes. There are a number of ways to do this, and most depend on the nature of the work you are computing.

The best choice would be to create a worker thread to accomplish the task you want to process, and if they cancel key gets pressed, just kill the thread. This will allow your UI to still be responsive while the task is being completed. But threading is tricky, and it sounds like you are newer to MFC and possibly C++.

Another possibility is avoiding creating your own dialog and just use one like Chris Maunder's found here: http://www.codeproject.com/miscctrl/progresswnd.asp

This is the simplest approach, but it isn't multi-threaded, and thus, your program will seem unresponsive until the point in your loop where you check to see if the cancel button was pressed. Then all you have to do is just break out of whatever loop you are using to do your work.

D

valikac15-Apr-02 17:30

Re: Initializing a CProgressCtrl Object Inside CDialog :: MFC

15-Apr-02 17:30

Thanks.

I have Prosise's book in front of me. I can implement a multi-threaded program, but it will take me some time and certain not in one night (maybe two weeks).

Having a progressbar inside a dialogbox is more complicated than I originally expected. If the progressbar does not get created until *after* a call to DoModal(), but then it gets unvalidated after DoModal() returns IDOK, there is no way to really update the progressbar from outside of the dialogbar.

For example, what if I were to instantiate a dialogbor inside view. I want to update the progressbar from view, not the dialogbar itself.

One last question, is there a way to enable/disable a button that is inside a dialogbox? I cannot get ClassWizard to map commandupdateUI for the dialogbox. That seems to only be valid for menu items in a toolbar.

Thanks,
Kuphryn

valikac15-Apr-02 18:04

Re: Initializing a CProgressCtrl Object Inside CDialog :: MFC

15-Apr-02 18:04

Okay. Prosise described a good way to enable/disable a control inside a dialog box. Here is the technique.

CWnd *pWnd = GetDlgItem(IDOK); // item you want to control
pWnd->EnableWindow(FALSE); // this will disable the control
pWnd->EnableWindow(TRUE); // this will enable the control

Kuphryn

Diarrhio15-Apr-02 18:50

Re: Initializing a CProgressCtrl Object Inside CDialog :: MFC

15-Apr-02 18:50

Exactly. That is a great book. It's where I got most of my MFC knowledge.;P

Diarrhio15-Apr-02 18:48

Re: Initializing a CProgressCtrl Object Inside CDialog :: MFC

15-Apr-02 18:48

Well, that is what I was gonna ask you. You might want to the dialog to be modeless. You can still do that with a class derived from CDialog. Just call Create on the dialog instead of DoModal. After you call create, you can access all the controls in the dialog from outside the dialog itself (i.e. from the View). Be sure to create the dialog on the heap using new rather than creating it on the stack. You also have to destroy the dialog yourself when you are done with it. Also be sure to override OnOK and OnCancel in the modeless version of the dialog and comment out the calls to the base class version.

Dialogbars are also cool, but they don't sound like what you need. A modeless dialog should be just fine. Dialogbars also require a bit more overhead in your code.

Good luck

valikac16-Apr-02 4:50

16-Apr-02 4:50

Thanks.

I will continue using the modal for now. A modeless has more features like interactive with the view class in real-time. Since this is the first design, I will use the modal to keep everything simple.

Kuphryn

Re: Before or After

valikac16-Apr-02 12:46

16-Apr-02 12:46

Conventionally speaking, should the dialogbox (progressbar) comes first or the access data processing. In other words, when creating a progressbar inside a dialog box, should I begin data manipulation, which is what the dialog box will ultimately depend on to update the progressbar, *before* creating the dialog box or *after*? Either way, it looks like I will need to seen a message to the MainFrm or view after InitDialog() in the dialog box.

Kuphryn

BitBlt problem

Jack Handy15-Apr-02 15:26

Jack Handy

15-Apr-02 15:26

I have two questions...

First:
I'm having a hard time tracking down a problem in my app. I'm using BitBlt to render a bitmap from memory onto my dialog and after a while the images start getting painted onto the desktop and everything gets jumbled up. I checked all my GetDC()'s and made sure to I am ReleaseDC()'ing them and it seems ok on that note. If you have any idea why this might be happening please enlighten me!

Second:
Does anyone know of a freeware app that will tell you how much memory in bytes your app is using in realtime? Or is there a way this can be accomplished with the vc6 debugger?

Thanks,

Jack

To an optimist the glass is half full.
To a pessimist the glass is half empty.
To a programmer the glass is twice as big as it needs to be.

Paul M Watt15-Apr-02 18:51

Paul M Watt

15-Apr-02 18:51

First:

When you release the DCs, are you properly freeing your memory DCs and BITMAP objects as well?

Second:

There are a number of things that you can do with the _CRT set of debug functions to find memory leaks.

Checkout my Guide to Win32 Paint for Intermediates

Jack Handy15-Apr-02 19:12

Jack Handy

15-Apr-02 19:12

kilowatt wrote:
When you release the DCs, are you properly freeing your memory DCs and BITMAP objects as well?

The DC I am releasing is the dialog's dc.. like..

CDC *pDC = MyDialog.GetDC();
pDC->BitBlt(...);
MyDialog.ReleaseDC(pDC);

-Jack

To an optimist the glass is half full.
To a pessimist the glass is half empty.
To a programmer the glass is twice as big as it needs to be.

Paul M Watt15-Apr-02 20:08

Paul M Watt

15-Apr-02 20:08

Do you just have one memory DC and bitmap that stay loaded into memory then the entire time?

Checkout my Guide to Win32 Paint for Intermediates

Jack Handy15-Apr-02 21:20

Jack Handy

15-Apr-02 21:20

Yes, those are used as the source and the dialog's DC are used as the dest.

-Jack

To an optimist the glass is half full.
To a pessimist the glass is half empty.
To a programmer the glass is twice as big as it needs to be.

linker error cant find mfc42u.lib

Paul M Watt15-Apr-02 21:33

Paul M Watt

15-Apr-02 21:33

I figured that you were using a memory DC as the Source, I was just wondering how you were managing those resources. Could you post your code where this is being painted and I will see if everything is in order, or if you do not want to post it to the forum, email me and I will get back to you?

Checkout my Guide to Win32 Paint for Intermediates

15-Apr-02 15:15

Does anyone know why Visual C++
6.0 tells me this?

How do I find mfc42u.lib and how
do I tell Visual C++ 6.0 where it is?

That is if mfc42u.lib is not obsolete or
something ... if it is obsolete what has
replaced it?

As you can see I am a complete newbie.

Re: linker error cant find mfc42u.lib

Matt Newman15-Apr-02 15:25

Matt Newman

15-Apr-02 15:25

You must not have UNICODE libraries installed (thats what the u stands for). If you are running anything other that Windows NT, 2K, or XP you won't need to compile UNICODE because 3, 95, 98, and ME use MBCS not UNICODE. Check which build settings you are using. If you want to change the build just pop open project settings - linker and change _UNICODE to _MBCS

- Suspicious | :suss:

Matt Newman / Windows XP Activist Suspicious | :suss:

-Sonork ID: 100.11179:BestSnowman

†

Re: linker error cant find mfc42u.lib

15-Apr-02 15:40

Thanks man! That did it!

Understanding The Future of MFC

valikac15-Apr-02 14:56