|
Hi.
I have a CDialog (modal) object. It serves as a progress dialog similar to the one that you see while waiting for EI to finish downloading. Inside the actual dialogbox is a CProgressCtrl object. Right now, the progress bar does not do anything. I tried initializing it like this:
m_MyProgressBar.SetRange(0, 100);
m_MyProgressBar.SetPos(0);
The program crashed when I add the code above. I did *not* create the object. The reason is I did not know the size of the object.
For example, this code comes from Prosise's book:
m_MyProgressBar.Create(WS_CHILD | WS_VISIBLE, rect, this, -);
I added a progressbar via Dialogbox Editor. I need to create the progressbar, but I do not know the actual rectangle of the progressbar I made using Dialogbox Editor.
How you to initialize a progressbar made using Dialog Editor?
Thanks,
Kuphryn
|
|
|
|
|
You don't need to call Create on an object that you added in the Resource Editor, the Framework does that for you automatically. Where are you getting the ASSERT's?
|
|
|
|
|
Okay. Thanks.
You were right. I did not have to create the progressbar. I did, however, override PreCreateWindow() and set the range and position of the progressbar.
Now I need a way to update it from my view class.
Kuphryn
|
|
|
|
|
When do you want to update it?
|
|
|
|
|
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
|
|
|
|
|
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.
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
Exactly. That is a great book. It's where I got most of my MFC knowledge.;P
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
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.
|
|
|
|
|
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
|
|
|
|
|
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.
|
|
|
|
|
|
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.
|
|
|
|
|
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
|
|
|
|
|
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.
|
|
|
|
|
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
- Matt Newman / Windows XP Activist
-Sonork ID: 100.11179:BestSnowman
†
|
|
|
|
|
|
Hi.
I had an interesting conversation with a programming (C++, Java, and soon, C#) professor at my college.
Background
----------
I am current practicing design and implementation using MFC. I am proficient with C++ and is gaining considerable experience with MFC.
Scenario
--------
I asked the professor if she teaches MFC in one of the upper-division programming courses I am planning to take next semester or the following semester. It is basically a couse on OOP C++, which I understand well now. I asked her if he teaches MFC. She says yes. However, I asked her aid who has taken that same course with her just an hour earlier, but he said there was no courses on MFC. The course that the professor teaches is more on OOP C++ concept.
Anyways, she went on to say that C# really interests her. So the conversation went on, but there was one thing that caught my attention. She said she *heard* that Microsoft is planning to *not support* MFC in the near future. What?
What is the future of MFC? Is C# affecting it at all?
I think C++ w/ MFC (or Win32 API) is the most powerful Windows programming tool.
Thanks,
Kuphryn
|
|
|
|
|
I can't see MFC disappearing anytime soon.
- Matt Newman / Windows XP Activist
-Sonork ID: 100.11179:BestSnowman
†
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
