Programmieren mit C++

Borland C++

Oberflächen

Modale Dialoge

Mein modaler Dialog scheitert beim Preprocessing von Nachrichten. Warum ruft der Dialog nicht PreProcessMsg() auf?

Frage

Dialoge verwenden ihre eigene Nachrichtenschleife zur Bearbeitung anstehender Nachrichten. Aus dieser Schleife heraus wird jedoch niemals PreProcessMsg aufgerufen. Es gibt jedoch die Möglichkeit, den Dialog zu zwingen, die Nachrichtenschleife der Anwendung zu verwenden, indem die Methoden BeginModal() und EndModal() eingesetzt werden. Damit wird es ebenfalls möglich, Menüs und Accelator-Tasten in Dialogen zu verwenden.

Die erforderlichen Änderungen am Code sind in einer abgeleiteten Dialogklasse einzubauen. BeginModal() wird aus der Methode Execute() heraus aufgerufen:

Lösung

int MyDialog::Execute( void )   
{
  Create();

  if( !( TWindow::Attr.Style & WS_VISIBL )) {
    Show( SW_SHOW );
  }

  return GetApplication()->BeginModal(
              GetApplication()->MainWindow );
}

Beim Schließen des Dialogs muß sichergestellt sein, daß der korrekte Status mit EndModal() wiederhergestellt wird.

Methode Execute

void MyDialog::Destroy( int retVal )
{
  GetApplication()->EndModal( retVal );
  TDialog::Destroy( retVal );
}

void MyDialog::CloseWindow( int retVal )
{
  if( CanClose() ) {
     TransferData( tdGetData );
     Destroy( retVal );
  }
}

Fenster schließen

Die vorgestellte Methode funktioniert für normale Dialogfenster. Probleme gibt es jedoch, wenn der Dialog aus einem anderen Dialog heraus aufgerufen wird. In diesem Fall beendet der Aufruf von EndModal() den Modal-Status des Applikationshauptfensters, nachdem der untergeordnete modale Dialog geschlossen wurde und der Fokus an das Eltern-Dialogfenster zurückgeht.

Beseitigen läßt sich dieses Manko nur durch eine angepaßte Execute-Methode. Im ersten Teil der Methode wird das Fenster wie gehabt angezeigt.

int MyDialog::Execute( void )
{
  Create();
  if( !( TWindow::Attr.Style & WS_VISIBLE)) {
     Show( SW_SHOW );
  }

Wenn das Hauptfenster aktuell aktiv ist, kann es nicht in einer BeginModal/EndModal-Routine sein, so daß BeginModal() auf dem Hauptfenster ausgeführt werden kann. Ebenso wird das Hauptfenster verwendet, wenn der Dialog kein Elternfenster besitzt.

if (!Parent || 
      GetApplication()->MainWindow->IsWindowEnabled())
  {
    return GetApplication()->BeginModal( 
                                  GetApplication()->MainWindow );
  }
  else

Ist das Hauptfenster nicht aktiv, sollte es nicht erneut für eine BeginModal/EndModal-Schleife verwendet werden. Statt dessen sollte das Elternfenster des Dialogs als Anker eingesetzt werden:

  {
     return GetApplication()->BeginModal( Parent );
  }
}

Modaler Dialog aus Dialog

Warum stürtzt die TPrinterPrint()-Funktion ab, wenn eine Druckabbruch-Dialogbox erzeugt werden soll?

Frage

Die TPrinter-Klasse in Borland C++ Version 4.x erwartet, daß die Ressource verfügbar ist. Wenn statisches Linken zum Einsatz kommt, muß der Programmierer die Ressource in der RC-Datei einbinden.

Zur Abhilfe kann der Standard-Dialog eingebunden werden, damit nicht ein eigener neuer Dialog entwickelt werden muß. Dies erfolgt durch Einbinden von

#include 

in der eigenen Ressourcendatei. Alternativ kann printer.rc in die eigene RC-Datei kopiert werden, damit eine individuelle Anpassung erfolgen kann.

Lösung

Beim statischen Linken ist generell zu beachten, daß die nachfolgenden OWL-Dateien Ressourcen besitzen:

  • docview.h
  • listview.h
  • editfile.h
  • owlapp.h
  • editsear.h
  • printer.h
  • editview.h
  • slider.h
  • except.h
  • statusba.h
  • inputdia.h
  • validate.h

Anmerkung





Sachgebiet


© 2009-2012 by Alojado Publishing. Alle Rechte vorbehalten. Ausgewiesene Marken gehören ihren jeweiligen Eigentümern.
Mit der Benutzung dieser Seite erkennen Sie die Nutzungsbedingungen und die Datenschutzerklärung an. Der Betreiber übernimmt keine Haftung für den Inhalt verlinkter externer Internetseiten.
Seite erzeugt 2012-05-20 02:41:05 von textarchiv.alojado.de