DialogBox wird nicht erstellt und Fenster friert ein, wieso?

MFK

T0bi schrieb:

Negativ!
wenn ich (DLGPROC) weglasse erscheinen folgende Fehler:

Nix "Negativ!".
Ist dir ein Laufzeitfehler lieber als ein Compilezeitfehler? Genau das erreichst du nämlich mit diesem Cast. Du verbietest dem Compiler die Typprüfung, also knallt's eben bei der Ausführung.

also daran scheint es net zu liegen.

Aua, aua.

Mit Casts lassen sich Compilefehler prima unterdrücken. Aber Casts sind nur ganz ganz ganz selten die richtige Lösung, um Compilefehler zu beheben.

Schau dir in der MSDN Library an, wie die Signatur der DialogProc aussehen muss.

WebFritzi

Hi T0bi! Wenn du den BCB benutzt, dann ist der Cast schon ganz richtig.

Was passiert, wenn deine DiaProc wie folgt aussieht?

bool CALLBACK DiaProc( HWND hDlg, UINT message, WPARAM wParam, LPARAM lParam )
{
   return false;
}

*D*Evil

Hmm wie wäre es wenn ihr mal einfach euch anguckt wie die DLGPROC momentan definiert ist?

INT_PTR DialogProc(HWND hDlg, UINT message, WPARAM wParam, LPARAM lParam)
{
    switch (message)
    {
        case WM_INITDIALOG:
            return (INT_PTR)TRUE;
        default:
            break;
    }
    return (INT_PTR)FALSE;
}

WebFritzi

Ich glaube nicht, dass das das (3x 'das' ) Problem ist...

T0bi

WebFritzi schrieb:

Hi T0bi! Wenn du den BCB benutzt, dann ist der Cast schon ganz richtig.

Was passiert, wenn deine DiaProc wie folgt aussieht?
bool CALLBACK DiaProc( HWND hDlg, UINT message, WPARAM wParam, LPARAM lParam )
{
   return false;
}

dann friert mein fenster trotzdem ein ... kommisch ich hatte doch schon mal nen dialog gemacht und da bgabs auch keine probleme, bis auf das ich casten musste

CodeFinder

WebFritzi schrieb:

Ich glaube nicht, dass das das (3x 'das' ) Problem ist...

Doch! Genau daran liegt es!

Mein Gott, ich geb den Hinweis, in der Hoffnung T0bi kommt selbst drauf, MFK erläutert das noch, (D)Evil gibt sogar den korrekten Code an und ihr laabert weiter son Müll. Sry, aber da fällt mir nicht mehr viel ein .

Vermeidet doch einfach diese unsinnigen Casts. *kopfschüttel*

T0bi

hae? *behnhof*

Ist eine Blume die keine Blätter hat nur ein Grashalm?

Scheinbar haben einige mehr Info's als ich.
Was passiert bei ersten Code, wenn bei "eingefrorenem" Fenster die ALT-Taste
gedrückt wird.

MfG

T0bi

*lol* ? dann erscheint die DialogBox.... aber wieso ?

Schreib mal BOOL, TRUE und FALSE statt der Kleinbuchstaben und es geht auch
ohne DLGPROC.

MfG

*D*Evil

Hmm ihr scheint ja auf einem ziemlich hohen geistigen Niveau zu sein. Vllt guckt ihr euch einfach mal meine Antwort an. Deine DialogProc muss so aussehen wie ich sie dir gepostet hab. Kannst du auch in der MSDN nachlesen.

T0bi

nein muss sie nich :P, ich hatte schon oeffters Dialoge gebastelt und sie haben bislang auch immer ohne deine möglichkeit funktioniert, doch irgendwie gehts net mehr ... -.- Borland is kaputt.

und es bringt auch nix wenn ich da true bool false ect klein oder groß schreibe ...grr... komisch find ichs ja des wenn das fenster gefreezed ist und ich alt druecke die DBox ershceint ...

Aus MSDN zu Dialogboxen:

char szItemName[80]; // receives name of item to delete. 

BOOL CALLBACK DeleteItemProc(HWND hwndDlg, 
                             UINT message, 
                             WPARAM wParam, 
                             LPARAM lParam) 
{ 
    switch (message) 
    { 
        case WM_COMMAND: 
            switch (LOWORD(wParam)) 
            { 
                case IDOK: 
                    if (!GetDlgItemText(hwndDlg, ID_ITEMNAME, szItemName, 80)) 
                         *szItemName=0; 

                    // Fall through. 

                case IDCANCEL: 
                    EndDialog(hwndDlg, wParam); 
                    return TRUE; 
            } 
    } 
    return FALSE; 
}

keksekekse

*freufreufreu* ich habe es jetzt auch kapiert, wie das mit dem Resourcencompiler von Borland geht

Ich hab die Lösung: Es liegt nicht daran, daß HINSTANCE hInst; nie initialisiert wird, es liegt auch nicht an szAppName[] = " Testing" mit Leerzeichen.

Die Lösung liegt in der WinProc():

/*case WM_PAINT:
    return 0;*/

Der Grund: Windows sendet die PAINT-Nachricht (d.h. der Clientbereich des Hauptfensters wird für ungültig erklärt) und die Reaktion ist ein mageres return 0;. Darum "friert" das Fenster ein, weil der Arbeitsbereich nie wieder für gültig erklärt wird.

Also entweder ganz weglassen oder

case WM_PAINT:
    hdc = BeginPaint(hwnd, &ps);
    EndPaint(hwnd, &ps);
    return 0;

T0bi

alter ich glaub es hackt... krasse sach wie lange hasten daran jetzt getüfftel... also bei mir gehts jetzs auch, also aller herzlichsten dank fuer den TIPP des Jahr 100's

Gruß und gn8 Tobi

*D*Evil

BOOL CALLBACK DeleteItemProc(HWND hwndDlg,
                             UINT message,
                             WPARAM wParam,
                             LPARAM lParam)

Das ist auch veraltet ...

TObi
Ist schon ziemlich dreist was du hier ablieferst. Solltest dir vllt nochmal überlegen was du schreibst ... man kann viele Sachen durch Casts beheben. Aber der einzigst richtige Funktionsrump besteht aus

INT_PTR DialogProc(HWND, UINT, WPARAM, LPARAM)

. Ob du das nun einsiehst oder nicht ... theoretisch kannst du auch aus nem Menschen auch nen Affen machen -.-

CodeFinder

@(D)Evil: Meine Meinung !

Wenn der Mercedes kein Benzin will, schreiben wir Diesel auf den Kanister ^^

Sehr Lustig dieser Thread, ich habe mich weggeschrien vor Lachen

Schieb mal WM_PAINT an, dann fährt der Diesel auch mit Benzin, beklopter geht es echt nicht mehr und mit dynamic_cast<*> kannst sogar im Tank pissen.

Wie schreibst du eigentlich Platform unabhängige Programme, mit castings ala (LINUX(UNIX(JAVA(MAC(FisherPrice)))))Windows

OK, spass beiseite
Regel Nr.1 - Keine Cast und drauf achten was der Compiler will
Regel Nr.2 - Gib dem Compiler was er will
Regel Nr.3 - Immer unötige Cast vermeiden

keksekekse

Der Kraftstoff im Tank kann noch soviel Oktan haben, wenn die Lenkradsperre (WM_PAINT) nicht gelöst ist, wirst Du nicht viel Spaß am Porsche haben.