OnInitDialog()

Is there a function for CDialogBar like OnInitDialog() or OnInitialUpdate() that is called after the dialog bar has been drawn where I can put initial values into the control in my override class of it? I temporarily did this in ShowWindow override, but I don't want it to do it EVERY time the window shows and hides, just the first time.

2nd part to the question, why do I get 0 for a height for the dlg bar when I get the rect for it from my OnIntialUpdate() of my view class?

CMainFrame* pFrame = (CMainFrame*)GetParentFrame();
CRect DlgBarRect;
pFrame->m_wndDlgBar.GetClientRect(DlgBarRect);
int BarHeight = DlgBarRect.Height();



This gives BarHeight to be 0, and is called from my view class.
Thanks..
Help on either is appreciated.

*DM*
AIM/AOL: Rais69
ICQ: 39184886
Email: [email protected]

1) I didn't use the CDialogBar, but I know that it is inherited from CWnd, so it should handle every Initialization function from there.
2) Even if you use ShowWindow override you don't need to initialize controls EVERY time the window shows and hides, you can write like this :

BOOL YourBar::ShowWindow( int nCmdShow )
{
static bool bFirstTime = false;
if (!bFirstTime)
{
MakeItitialization();
bFirstTime = true;
}
// etc.
}



It will work only the first time the function called.
3) The function GetClientRect() gets pointer to CRect, so you should write

pFrame->m_wndDlgBar.GetClientRect(&DlgBarRect);



to get data.

Jack.

Okay, on the 2nd part, I'm STILL getting 0 height. I use to use the address of operator all the time, then I saw some samples that didn't use it, so I stopped using it, and it's worked fine those times. I use it elsewhere and it's fine. But from my View class, it's still saying the Height() is 0. ????

*DM*
AIM/AOL: Rais69
ICQ: 39184886
Email: [email protected]

This is typical behaviour in MFC.
Usually, the Dlg Bar is created with size 0,0. then, the frame will ask all bars for new layout. then all bars are resized. to "good" sizes.

You can overwrite the OnSize message of your Dlg bar class (call base class implem), and wait until the first time you get a "useful" size.

If the size is necessary for some of your ops, you should to overwrite OnSize anyway.

Hope this helps
Peter

Usually, you only instantiate one dialog bar, but should you ever instantiate two of this class the 'static bool bFirstTime = false;' statement will cause the second instance of your class to *NOT* be initialized. To avoid this difficulty, the boolean can be made a member that is initialized to false in the constructor. This is pretty subtle and picky, but I've been tripped up on static's on too many times to count :-)

Do you do the GetClientRect stuff before or after the OnIntialUpdate of the base class? That probably does not matter, though, so ignore that question if you want to.

I am not familiar with overriding ShowWindow, but I override OnSize and I think I have had the same problem as you are having as far as getting zero size at OnIntialUpdate time. In my OnSize I check if nType == SIZE_RESTORED. The advantage of doing it this way is that I can handle the situation where the user re-sizes the window.

I need to do something similar, but with a regular dialog. I want the dialog to be displayed, and then begin processing some information. If I call a function to begin processing from OnInitDialog(), the window is never drawn until the processing ends...modal.

How do I get my processing started without having to press a button?

Thanks

If your process takes a long time, you should create a thread an do your processing there so the user can still use your app.

Call AfxBeginThread() on OnInitDialog() to do that.

The task is to do database inserts as it reads headers from files that are being FTPd to the server. CDaoRecordset is NOT thread-safe so this isn't possible. I could use ODBC, but this computer is going to be busy as it is. ODBC is much less efficient in this application.

thanks

You can call ShowWindow(TRUE) on the top of OnInitDialog() to show the window; but most of the controls will not be visible at this time. You can also setup a timer. Timer will kick off after the dialog box is ready for input (when it is visible). You can kill the timer the first time it gets called.

Using the timer works. Thanks.

Now, however, the function that the timer executes blocks the dialog. There is no way to press the OK button. In VB6, there is a DoEvents() call. This looks for button clicks etc and allows them to be handled. Is there an equivalent in VC++?

Thanks again.

This is because the timer is sharing the same thread with other message handlers. This is true with any other messages (including OnInitDialog and OnShowWindow). That's why creating another thread is more desirable.

If you are processing your stuff in a loop, you can call PeekMessage() and DispatchMessage() within the loop to give Windows a change to process other messages.

Example:

if (PeekMessage(&msg, NULL, 0, 0, PM_REMOVE))
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}

This will work well if each loop is fast, but it will appear sluggish if one of your processing takes a long time (such as updating a database).

If you are using NT 4.0, you can also use Fiber instead of Thread to simulate Thread.

I logged back in JUST to tell you to do what I see someone else has already done, recomend a thread just for the processing, which you can end once the processing is done. Someone beat me to the punch. <grin>

*DM*
AIM/AOL: Rais69
ICQ: 39184886
Email: [email protected]