Menus update in LApplication

[j***@yahoo.com]

Hi,

I encounter trouble to update menus in my LApplication-derived app for
LSingleDoc-derived windows.
Each time I display a dialog box using this king of code:

void AnyFunc()
{
StDialogHandler theHandler(PPob_MyID, this);
LWindow* theDialog = theHandler.GetDialog();
theDialog->Show();
while (true) {
MessageT hitMessage = theHandler.DoDialog();
if (hitMessage == msg_Cancel) {
break;
} else if (hitMessage == msg_OK) {
// Do something
break;
}
}
}

when exiting this dialog using cancel or OK my app's menus are not
updated correctly, even by calling
LCommander::SetUpdateCommandStatus(true) plus
LEventDispatcher::UpdateMenus()...

The latter one ends up by calling MyApp::FindCommandStatus instead of
the topmost LSingleDoc-derived window's FindCommandStatus (that could
correctly update the menus).
Therefore if my doc contains an edit field the Edit menu is not
enabled...

The only way to update the menus is to switch to another app (using
cmd+tab or by clicking in another app's window) and switch back to my
app!

Does anyone know a trick to enforce correct menus updating?

Thanks in advance for your help...
Regards,
MacPorter.

[Michael Fielitz]

Hello,

Post by j***@yahoo.com
Hi,
I encounter trouble to update menus in my LApplication-derived app for
LSingleDoc-derived windows.
void AnyFunc()
{
StDialogHandler theHandler(PPob_MyID, this);
LWindow* theDialog = theHandler.GetDialog();
theDialog->Show();
while (true) {
MessageT hitMessage = theHandler.DoDialog();
if (hitMessage == msg_Cancel) {
break;
} else if (hitMessage == msg_OK) {
// Do something
break;
}
}
}
when exiting this dialog using cancel or OK my app's menus are not
updated correctly

[...]


just a guess: this second parameter to the StDialogHandler's ctor - are
you sure to pass a pointer to your application class as a
supercommander?
I think this affect the correct command handling/menu enabling
mechanism.

Michael

[j***@yahoo.com]

Hi,

thanks for your answering so fast... :-)

I even tried to cast the "this" pointer to LCommander (since my
LApplication-derived class does not have any supercommander) like this:

StDialogHandler theHandler(MyID, (LCommander*)this);
where "this" is my LApplication-derived class but without any success
either...

MacPorter.

Post by Michael Fielitz
Hello,
[...]
just a guess: this second parameter to the StDialogHandler's ctor - are
you sure to pass a pointer to your application class as a
supercommander?
I think this affect the correct command handling/menu enabling
mechanism.
Michael

[David Phillip Oster]

Post by j***@yahoo.com
void AnyFunc()
{

{

Post by j***@yahoo.com
StDialogHandler theHandler(PPob_MyID, this);
LWindow* theDialog = theHandler.GetDialog();
theDialog->Show();
while (true) {
MessageT hitMessage = theHandler.DoDialog();
if (hitMessage == msg_Cancel) {
break;
} else if (hitMessage == msg_OK) {
// Do something
break;
}
}

}
LCommander::SetUpdateCommandStatus(true);

Post by j***@yahoo.com
}

As i remember, the destructor for StDialogHandler cancels the menu
update, so you have to call SetUpdateCommandStatus() after the
destructor is run, hence the extra layer of { } .

Also, rather than passing "this", pass the window that should become
active after the dialog is dismissed. You may need to add a
FindCommandStatus to your dialog class that doesn't forward commands it
doesn't recognize.

All of this is off-the-top-of-my-head, untested, and based on memories
more than a year old. Hope it helps.

[j***@yahoo.com]

Post by David Phillip Oster

Post by j***@yahoo.com
void AnyFunc()
{

{

Post by j***@yahoo.com
StDialogHandler theHandler(PPob_MyID, this);
LWindow* theDialog = theHandler.GetDialog();
theDialog->Show();
while (true) {
MessageT hitMessage = theHandler.DoDialog();
if (hitMessage == msg_Cancel) {
break;
} else if (hitMessage == msg_OK) {
// Do something
break;
}
}

}
LCommander::SetUpdateCommandStatus(true);

Post by j***@yahoo.com
}

As i remember, the destructor for StDialogHandler cancels the menu
update, so you have to call SetUpdateCommandStatus() after the
destructor is run, hence the extra layer of { } .

No it doesn't.
What is more the call to SetUpdateCommandStatus is done long after the
dialog has been destroyed: I even put it inside my LDocument-derived
class's BeTarget to be sure but without any results...

Post by David Phillip Oster
Also, rather than passing "this", pass the window that should become
active after the dialog is dismissed.

No success either even by using UDesktop::FetchTopRegular() as
LCommander*...

Post by David Phillip Oster
You may need to add a FindCommandStatus to your dialog class that doesn't forward commands it doesn't recognize.

Perhaps this is the trick but finally I overcharged
LApplication::UpdateMenus in my app's class to
"UDesktop::FetchTopRegular" the "right" window to call a function of
mine to update the menu according to its own FindCommandStatus:
everything runs now fine...
Thanks for you help! :-)

Post by David Phillip Oster
All of this is off-the-top-of-my-head, untested, and based on memories
more than a year old. Hope it helps.

It's OK: thanks again for your help...