DoModal() wirft im Host-Win10 return code -1 aber in VM Win10 funktioniert es.

[SamiD]

Hallo Zusammen,

ich bin habe in einer VM (VMWare) mit Windows 10 aufgrund von einer sehr alten MFC-Anwendung Microsoft Visual C++ 6 installiert und diese Anwendung mit einem Dialog-Modalfenster erweitert. In der VM funktioniert alles wunderbar, aber leider nicht im Host-Betriebssystem mit Windows 10. Die Methode DoModal() wirft unerklärlicherweise den return code -1. Ich kann mir das überhaupt nicht erklären. Hat schon mal jemand von euch so etwas gehabt?

Grüße,

SamiD

[Th69]

Hast du spezielle Controls in dem Dialog? Oder s.a. DoModal() kehrt mit -1 zurück, WARUM?
Evtl. helfen dir auch diese englischen Forenbeiträge:

• Why does MFC DoModal returns -1 ? What does -1 mean?
• DoModal returns -1 ?

[hustbaer]

Ich nehme an auf dem Host PC werden einfach bestimmte DLLs fehlen.
Verwendest du einen Debug Build am Host PC? Falls ja, versuch mal nen Release Build.

[Martin Richter]

Und was Sagt GetLastError?

[SamiD]

Hallo Zusammen,

vielen Dank für die Unterstützung. Ich werde eure Vorschläge durchgehen und dann Rückmeldung geben.

Gruß,

SamiD

[SamiD]

@Th69
Mein Dialogfenster besteht aus Edit, Combo, Button und MsFlexGridControl Elementen. Ob das speziell ist oder nicht kann ich leider nicht beurteilen, weil ich in dem Thema mit MFC und C++ noch ganz am Anfang bin. Ich denke mein Problem ähnelt dem Problem aus dem letzten von dir vorgeschlagenen Beitrag. Nur habe ich keine RichEdit Controls in meinem Dialog.

[SamiD]

@hustbaer Ja ich denke auch, dass es der Grund sein wird. Ich habe schon beide Builds (Debug und Release) ausprobiert. Beide funktionieren nicht.

[SamiD]

@Martin-Richter Ich habe die Methode GetLastError() wie in einem Stackoverflow-Beitrag vorgeschlagen, eingebaut:

CString FormatErrorMessage(DWORD ErrorCode)
{
    TCHAR   *pMsgBuf = NULL;
    DWORD   nMsgLen = FormatMessage(FORMAT_MESSAGE_ALLOCATE_BUFFER |
        FORMAT_MESSAGE_FROM_SYSTEM | FORMAT_MESSAGE_IGNORE_INSERTS,
        NULL, ErrorCode, MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT),
        reinterpret_cast<LPTSTR>(&pMsgBuf), 0, NULL);
    if (!nMsgLen)
        return _T("FormatMessage fail");
    CString sMsg(pMsgBuf, nMsgLen);
    LocalFree(pMsgBuf);
    return sMsg;
}

und bekomme diese Meldung als Antwort in einer MessageBox direkt nach dem Aufruf von DoModal():

"Der Vorgang wurde erfolgreich beendet"

Aber sagen tut es mir nicht viel.

[Th69]

Das heißt, daß kein Fehler vorliegt (also ErrorCode = 0) - was aber eigenartig ist?!

Das MsFlexGrid Control scheint aber in einer eigenen DLL zu sein: MSFLXGRD.OCX. Ist diese auf dem Zielrechner installiert (bzw. liefert du diese beim Setup mit aus, inklusive Registrierung als ActiveX-Komponente)?

[SamiD]

@Th69 Nach dem Kompilieren habe ich in dem Release-Ordner neben vielen obj-Dateien eine EXE-Datei. Diese EXE-Datei kopiere ich auf das Host-System und starte es. Was anderen mache ich nicht.
Ich habe jetzt geprüft und habe festgestellt, dass die MSFLXGRD.OCX auf dem Client-System unter C:\Windows\SysWOW64 vorhanden ist und auf dem Host-System nicht. Ich habe die Datei in den gleichen Ordner auf Host-System kopiert, hat aber leider zu keiner Verbesserung geführt. Habe ich irgendeinen Schritt ausgelassen bzw. wie liefere ich die Datei beim Setup aus mit der von dir genannten Registrierung als ActiveX-Komponente?

[Th69]

Verwende dazu den Terminalbefehl: regsvr32 msflxgrd.ocx

[SamiD]

@Th69 Super, danke dir. Jetzt geht es. Kann man das Ganze so konfigurieren, dass das Kopieren der OCX Datei und die Registrierung beim Programmstart (Ausführen der EXE-Datei) durchgeführt werden?

[Th69]

Nein, beim Starten ist es dafür dann zu spät. Wie schon geschrieben, solltest du dann ein Setup-Programm dafür erstellen, s. z.B. Bereitstellen einer Visual C++-Anwendung mithilfe eines Setupprojekts.

[SamiD]

@Th69 Vielen, vielen Dank.

Grüße,

SamiD

[SamiD]

@Th69 Ich hätte noch eine zusätzliche Frage. Bei uns liegt die Anwendung (exe) auf einem Server und diese wird von mehreren Clients aus über das Netzwerk aufgerufen. Reicht es wenn ich die MSFLXGRD.OCX auf dem Server ablege um die Anwendung richtig auszuführen oder muss die .OCX Datei auf jedem Client vorhanden sein?

[Th69]

Die muß natürlich auf jedem Client dann zugreifbar (+registriert) sein, denn dieser startet ja die Anwendung.
Technisch könnte diese OCX-Datei auch auf einem gemeinsam genutzten Verzeichnis liegen, aber dann müßte die PATH-Umgebungsvariable entsprechend auf jedem Client angepaßt werden (was ich nicht empfehlen würde).

Du könntest (alternativ zum Setup-Programm für jeden Client) z.B. eine Batch-Datei erstellen, welche (einmalig) das Kopieren und Registrieren übernimmt, sowie danach dann die Anwendung startet (und der Anwender startet dann diese Batch-Datei anstatt die Anwendung direkt).

[SamiD]

@Th69 OK, danke für den Vorschlag.