Solved

Application Modal Dialogs using Modeless Dialogs

Posted on 2002-03-24
20
1,084 Views
Last Modified: 2013-12-03
Note: I am using WTL, not MFC. I can understand MFC code but I would prefer a WTL or pure Windows answer.

I've got a long processing loop in my application and I would like to display a progress dialog while it's doing its stuff.

Here's the code simplified:

CProgressDlg dlg;
dlg.Create(hParent);
dlg.CenterWindow();
dlg.ShowWindow(TRUE);

while(/*there_is_work_to_do*/)
{
   FlushMessages(); /* message pump */
   if (dlg.m_bCancel) * set to true if the cancel button is pressed */
      break;
   
   /* do work here and loop again */
}

dlg.DestroyWindow();

Now this works fine, the code executes, the dialog is displayed nicely, but this dialog is a child of my main window and I would like to lock the main window until the work is completed, e.g. I would like the focus to stay on the dialog.

Note: I don't want it System modal, just application modal.

How should I change the code? I don't see how to use the DoModal since I need to run code and just update the progress window once in a while.

Thanks
0
Comment
Question by:mridey
  • 10
  • 10
20 Comments
 
LVL 23

Expert Comment

by:Roshan Davis
ID: 6893544
You can simply use like this
WTL also have DoModal functio for dialog

CProgressDlg dlg;
dlg.DoModal();

GOOD LUCK
0
 

Author Comment

by:mridey
ID: 6893566
No, it's the problem. If I use DoModal, the call doesn't return and I can't execute the work I need to do while the dialog is displayed. I am not using the dialog to get user input prior to the loop, I'm using the dialog to give feedback to the user while I'm processing their request.
In short, imagine there is a progress bar on the dialog and you're trying to update 100 records in a database.
You want first to display the progress bar then to loop through the 100 records and as you modify them, you update the progress bar. When you're finished (or if the user press cancel), you close the window and stop your work.

0
 
LVL 23

Expert Comment

by:Roshan Davis
ID: 6893595
You can simply use like this
WTL also have DoModal functio for dialog

CProgressDlg dlg;
dlg.DoModal();

GOOD LUCK
0
 
LVL 23

Expert Comment

by:Roshan Davis
ID: 6893596
So then u just set the ponter of the parent window to dialog
And the the dialog will call the public method of the parent

GOOD LUCK
0
 

Author Comment

by:mridey
ID: 6893629
Sorry I don't understand the last comment
0
 
LVL 23

Expert Comment

by:Roshan Davis
ID: 6893635
1. Add a public method in your Dialog class named SetParent.
2. Pass the parent window poiter to this dialog by this method
3. Add a public method in your parent class. In that method add, your codes that needed to process from the dialog.
4. call the DoModal
5. From the dialog call the parent windows public method through its parent (that already setted through the SetParent method) pointer.

GOOD LUCK

0
 

Author Comment

by:mridey
ID: 6893658
Ok, almost there. No problem doing this.
Just a quick question then, To trigger the call to the parent, I need to do it within a message currently processed by the dialog?
Something like:

OnInitDialog()
{
...

PostMessage(WM_USER ...)
}

OnUserMessage()
{
m_Parent->DoSomeWork()
}

And if so, can I just pump all messages inside DoSomeWork() with the usual PeekMessage/DispatchMessage loop to ensure that the user interface remain active (so that the dialog can be moved & canceled and the appllication doesn't appear non-responsive.)

Thanks

0
 

Author Comment

by:mridey
ID: 6893660
Ok, almost there. No problem doing this.
Just a quick question then, To trigger the call to the parent, I need to do it within a message currently processed by the dialog?
Something like:

OnInitDialog()
{
...

PostMessage(WM_USER ...)
}

OnUserMessage()
{
m_Parent->DoSomeWork()
}

And if so, can I just pump all messages inside DoSomeWork() with the usual PeekMessage/DispatchMessage loop to ensure that the user interface remain active (so that the dialog can be moved & canceled and the appllication doesn't appear non-responsive.)

Thanks

0
 
LVL 23

Expert Comment

by:Roshan Davis
ID: 6893664
Don't post message to the parent,
Just call the Function using parent pointer...

Roshmon
0
 

Author Comment

by:mridey
ID: 6893673
I meant to say that the dialog would post a message to itself (to get out of the OnInitDialog processing). One way or another I need to be in the middle of processing a dialog message when I call the parent function and since the processing of that message could take many many minutes, I need to process the message loop while inside the message of the dialog called by DoModal ...
All this in fact because there is no OnIdle processing within a Modal Dialog.
0
Find Ransomware Secrets With All-Source Analysis

Ransomware has become a major concern for organizations; its prevalence has grown due to past successes achieved by threat actors. While each ransomware variant is different, we’ve seen some common tactics and trends used among the authors of the malware.

 
LVL 23

Expert Comment

by:Roshan Davis
ID: 6893692
>> can I just pump all messages inside DoSomeWork() with >>the usual PeekMessage/DispatchMessage
>>loop to ensure that the user interface remain active

No, No use
that can process the parent messages while in do modal....

If it is a large processing u can either put that into a thread, or call the function from the dialog instead of calling entire loop.

That is u can use PeekMessage, and Dispatch for the Dialog window.....
So Do the looop in dialig instead of parent wiindow

Roshmon
0
 

Author Comment

by:mridey
ID: 6893702
Thanks, I'll try a few options tomorrow (it's getting late in Australia).
0
 
LVL 23

Expert Comment

by:Roshan Davis
ID: 6893709
Okay
0
 

Author Comment

by:mridey
ID: 6895219
Using DoModal doesn't work in this case, at least not the way I tried it.
This is the code I used for testing:

in the main frame, activated by a menu command:

CProgressDlg dlg;
dlg.DoModal(hParent);

then the class definition

class CProgressDlg : public CDialogImpl<CProgressDlg>
{
public:
    enum { IDD = IDD_PROGRESS };

    BEGIN_MSG_MAP(CProgressDlg)
        MESSAGE_HANDLER(WM_INITDIALOG,OnInitDialog)
        MESSAGE_HANDLER(WM_USER,OnUserMsg)
        COMMAND_ID_HANDLER(IDCANCEL, OnCancel)
    END_MSG_MAP()

    bool  m_bCancel;
    CProgressBarCtrl m_progress;
    CStatic m_text;

    LRESULT OnInitDialog(UINT /*uMsg*/, WPARAM /*wParam*/, LPARAM /*lParam*/, BOOL& /*bHandled*/)
    {
        m_progress.Attach(GetDlgItem(IDC_PROGRESS));
        m_text.Attach(GetDlgItem(IDC_TEXT));
        m_progress.SetRange32(0,100);
        m_progress.SetPos(0);
        m_progress.SetStep(1);
        m_bCancel = false;

        PostMessage(WM_USER);

        return TRUE;
    }

    LRESULT OnUserMsg(UINT /*uMsg*/, WPARAM /*wParam*/, LPARAM /*lParam*/, BOOL& /*bHandled*/)
    {
        for (int i=0; i<100; i++)
        {
            FlushMessages();
            if (m_bCancel)
                break;
            Beep(1000,100);
        }
        EndDialog(0);
        return 0;
    }

    LRESULT OnCancel(WORD /*wNotifyCode*/, WORD wID, HWND /*hWndCtl*/, BOOL& /*bHandled*/)
    {
        m_bCancel = true;
        return 0;
    }
};

The dialog never appears on the screen. I get the series of Beeps as expected then the DoModal returns but the FlushMessages function doesn't help in handling the dialog messages. this is its code:

bool FlushMessages()
{
    MSG msg;
    while(::PeekMessage(&msg,NULL,NULL,NULL,PM_NOREMOVE))
    {
        if (msg.message != WM_QUIT)
        {
            ::GetMessage(&msg,NULL,NULL,NULL);
            ::TranslateMessage(&msg);
            ::DispatchMessage(&msg);
        }
        else
            return true;
    }

    return false;
}

Should I be using something else to process the dialog messages in the middle of the processing of the WM_USER message? Such as calling a DialogProc() directly for each message?

Looks like I'm going to have to start a work thread in the processing of the WM_INITDIALOG message and synchronise the two so that the cancel button kills the work thread and the work thread terminate the DoModal when it finishes its work.

I would have preferred to avoid the multithreaded architecture.

Thanks
0
 
LVL 23

Expert Comment

by:Roshan Davis
ID: 6895596
Hi

y u posting message to the same dialog, instead of calling the function directly ?

Roshan Davis
0
 

Author Comment

by:mridey
ID: 6895611
I'm still trying to understand what you mean by 'Calling the function directly'. It has to be called from somewhere.
So what I tried was to get the dialog during INITDIALOG to post itself a message, to be able to get out of the INITDIALOG processing and then when the WM_USER is being processed by the dialog to to the bulk of the work.
I have in the example above simulated the call to my parent function by replacing it with a Beep().
What happends is that during the processing of the WM_USER message, even with the FlushMessage() function, the application is not processing messages, the dialog is not displayed ... but I get the series of Beeps. Once the loop is completed, the DoModal returns (since the loop terminate with an EndDialog(0). )

So the question remains: How can I get a lot of processing done while the modal dialog is dislayed and if it's done inside a message of the dialog, how do I maintain the message pump to get Paint and mouse movements processed.

Marc
0
 
LVL 23

Expert Comment

by:Roshan Davis
ID: 6895616
Only peek and dispatch messages of the dialog.
Add a method in dialog, and call by its name. U r Posting the message to the same dialog itself. Thats what i'm mentioned..

Roshmon
0
 

Author Comment

by:mridey
ID: 6895626
Yes, the code is aboe. I use:

PostMessage(WM_USER)

in OnInitDialog so the message is posted to the dialog itself.
Even if I add a method to the dialog, where would you call it from. I can call it from the main code (since that code is locked waiting for the DoModal() to complete). I can only call it from a message being processed.

Marc
0
 
LVL 23

Accepted Solution

by:
Roshan Davis earned 100 total points
ID: 6895634
U can do some trick way like this

CYourDlg::OnPaint()
{
    static bool bFirstTime = false;
    if (!bFirstTime)
    {
          bFirstTime = true;
          //Call ur function
    }
}

So the dialog will be visible, otherwise i think there may be a queue wait for the SHOWWINDOW

Try this

GOOD LUCK
0
 

Author Comment

by:mridey
ID: 7058166
Thanks for the help.
0

Featured Post

What Should I Do With This Threat Intelligence?

Are you wondering if you actually need threat intelligence? The answer is yes. We explain the basics for creating useful threat intelligence.

Join & Write a Comment

This tutorial is about how to put some of your C++ program's functionality into a standard DLL, and how to make working with the EXE and the DLL simple and seamless.   We'll be using Microsoft Visual Studio 2008 and we will cut out the noise; that i…
If you have ever found yourself doing a repetitive action with the mouse and keyboard, and if you have even a little programming experience, there is a good chance that you can use a text editor to whip together a sort of macro to automate the proce…
This is Part 3 in a 3-part series on Experts Exchange to discuss error handling in VBA code written for Excel. Part 1 of this series discussed basic error handling code using VBA. http://www.experts-exchange.com/videos/1478/Excel-Error-Handlin…
Polish reports in Access so they look terrific. Take yourself to another level. Equations, Back Color, Alternate Back Color. Write easy VBA Code. Tighten space to use less pages. Launch report from a menu, considering criteria only when it is filled…

757 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

19 Experts available now in Live!

Get 1:1 Help Now