C / C++ / MFC

Re: Change IDR_MAINFRAME start coordinate

2-Feb-07 3:46

sortegrip wrote:
...the GUI must be centered in a full screen window.

So why not just call CenterWindow()?

"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15

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

sortegrip2-Feb-07 4:56

sortegrip

2-Feb-07 4:56

What would I center it against and where in my CView or CDoc would I do it?
I only have one window and in the center of that window I draw the GUI on the DC in OnDraw().

Re: Change IDR_MAINFRAME start coordinate

David Crow2-Feb-07 5:17

2-Feb-07 5:17

sortegrip wrote:
What would I center it against...

That all depends on the argument you pass to it. By default, it centers child windows relative to their parent window, and pop-up windows relative to their owner.

"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15

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

Destroyed Window

baerten2-Feb-07 2:21

baerten

2-Feb-07 2:21

I have a TabControl ( not the MFC one ) on my View.
In this Tab i have a huge number of Views.
If the User clicks in the Menu on "Customers" it opens the customers in this current Tab, if he
clicks on articles, so it opens the articles AND DOESN'T erase the Customers-View, because he can re-open the used-View with the old-state ...

So i need to close/delete all these views if the Tab closes...
In the "destructor" of the Tab i close all opened Views from this Tab

But if i close the whole application, it doesn't close the Tab ( which closes the Views )
It closes the Views, then the Tabs, then the TabControl

If he steps into the Destructor of the Tab, the Pointers of the Views are still there,
but their hWnd aren't valid anymore...

Now the question : How can i test, if a pointer on a View has a valid hWnd or if the object behind
the pointer is still deleted ?

It's certainly possible or not?

Thanks Rose | [Rose]

Mark Salsbery2-Feb-07 5:41

Mark Salsbery

2-Feb-07 5:41

if (::IsWindow(*pView))
// HWND is valid
else
// HWND is NOT valid

baerten4-Feb-07 21:40

baerten

4-Feb-07 21:40

Thanks for your answer.

But this dont work Sniff | :^)

Because the pointer is already 0xcdcdcdcd. If the pointer is 0x000000 i could test him on
if(View!=NULL) or can i test also on 0xcdcdcdcd ?
Is it a special-adress-value for deleted objects? Because if an instance is deleted, the pointer
sets to 0xcdcdcdcd ...

Thanks Smile | :)

Mark Salsbery5-Feb-07 5:19

Mark Salsbery

5-Feb-07 5:19

If your "views" or "tabs" are derived from CFrameWnd then they delete themselves when you call
DestroyWindow(). Therefore you should set the pointers to NULL so you can check them before
trying to use them.

It's up to you to track the lifetime of these objects. That means if any child windows of a
given window class are not CFrameWnd derived and are allocated with new then the child object
should be deleted - usually this is done in a WM_DESTROY handler of the parent.

To destroy a CFrameWnd derived window
pFrameWnd->DesstroyWindow();
pFrameWnd = NULL;

To destroy a CWnd derived window
pWnd->DesstroyWindow();
delete pWnd;
pWnd = NULL;

Mark Salsbery5-Feb-07 5:25

Mark Salsbery

5-Feb-07 5:25

And no, don't test on 0xcdcdcdcd - that's a debug value but there's no guarantee the CRT will
change a pointer to that value when it's deleted. It's up to the programmer to keep track of
all that Smile | :)

PumpMessage Question

Andy2022-Feb-07 1:26

Andy202

2-Feb-07 1:26

I am using a Tabbed Dialog (6 dialogs in total).

Now in some of these Tabbed Dialogs I need to wait for an external event, so I do the following:-

while(waiting)
{
   Sleep(100);           // Wait 100 ms
   ProcessMessages();    // Pump Message Queue
   CheckForEvent();      // Call the routine that will set waiting to false when OK
}

void ProcessMessages()
{
   CWinApp* pApp = AfxGetApp();
   MSG msg;

   while(PeekMessage(&msg, NULL, 0, 0, PM_NOREMOVE))
      pApp->PumpMessage();
}

But my question is 'Do I need to have a separate ProcessMessage in each of the Tabbed Dialogs' and are they a better way of doing this sort of processing.
Note I use a 3rd party API for the external event.

Many thanks,

Andy.

David Crow2-Feb-07 2:41

2-Feb-07 2:41

Andy202 wrote:
I need to wait for an external event...

So why aren't you using CreateEvent() and WaitForSingleObject()?

"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15

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

Andy2022-Feb-07 2:46

Andy202

2-Feb-07 2:46

Hi David, its just trying to gt something working (prototye) fast.

Are they problems with several ProcessMessages as the number of Tabbed Dialogs could go up to 20!

Cheers,

Andy.

David Crow2-Feb-07 2:56

2-Feb-07 2:56

Andy202 wrote:
Are they problems with several ProcessMessages...

Other than PeekMessage() being old and antiquated? Yes. If you happen to have (in the future) an active modeless dialog, there is no call to IsDialogMessage(). Is PumpMessage() dispatching its own messages?

While it's ultimately up to you as to how you want to handle event notification, I personally would not opt for this route.

"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15

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

Waldermort2-Feb-07 2:48

Waldermort

2-Feb-07 2:48

If I understand your code correctly, when the external event occurs, a message is posted/sent to the dialog. Is this correct? If so, you don't need keep calling PeekMessage(). GetMessage() will wait until there is a message in the que and only return if there is.

Also you say 'tabbed dialog' Do you mean a window with a tab control, or a series of windows? If you have one main window, which controls your dialogs, then you only need one message pump. If you are dialing with several windows, then create a "message only window" which handles the message pump and dispatches the message to the correct child dialog. Either way, you only need one message pump.