Probleme, eine Win32-Applikation in MFC zu integrieren

FelixManke

Hi,

ich habe für die Uni eine Mini-3D-Engine geschrieben. Der Prof war leider nicht mit einer Win32-Applikation zufrieden und will jetzt eine MFC-Anwendung haben. Leider gibt es immer einen Laufzeitfehler, wenn ich versuche, die Bitmaps für die Texturen einzulesen. Ich weiß nicht, wieso. Folgendes geschieht im Programm: Ich lese die Texturpfade zusammen mit den Vertices aus einer Textdatei ein und übergebe den Pfad an folgende Methode. Der Fehler tritt beim "if(file)..." auf. Doch der Pfad stimmt laut Messagebox (z.B. data/tex1.bmp).

AUX_RGBImageRec *loadBMP(char *filename){
    FILE *file = NULL;

    if(!filename)
        return NULL;

    file = fopen(filename, "r");

    if(file){
        fclose(file);
        return auxDIBImageLoad(filename);
    }

    return NULL;
}//loadBMP

Was kann ich tun? Ich habe auch folgendes versucht, da dies in etwa die Art ist, wie mein Prof Bitmpas einließt (allerdings über einen OpenFileDialog, was für mich ja nicht in Frage kommt):

//Datei: BitmapLoader.h

#include "stdafx.h"
#include < vector >

using namespace std;

struct BitmapLoader{
    BITMAPFILEHEADER FH;
    BYTE IBytes[1200];                  //bytes for BitmapInfoHeader+Palette
    BITMAPINFOHEADER* pIH;              //pointer on BitmapInfoHeader
    BITMAPINFO* pI;                     //pointer on BitmapInfo
    std::vector< BYTE > pixel;    //dyn. array for pixel

    CArchive *ar;

    void loadBitmap(CFile *file)
    {
        memset(IBytes, 0, sizeof(IBytes));
        pIH = (BITMAPINFOHEADER*) IBytes;
        pI  = (BITMAPINFO*)       IBytes;

        ar = new CArchive(file, CArchive::load);

        ar->Read( &FH, sizeof(BITMAPFILEHEADER) );

        int nBytesInfo = FH.bfOffBits - sizeof(BITMAPFILEHEADER);
        int nBytesPixel = FH.bfSize - FH.bfOffBits;
        ar->Read( IBytes, nBytesInfo ); //BitmapInfoHeader+Palette

        pixel.resize( nBytesPixel );
        ar->Read( &pixel.front(), nBytesPixel );
    }//loadBitmap
};//struct

Das klappt allerdings auch nicht. der erste ar->Read(...) meckert, obwohl der Pfad auch hier stimmt!

HILFE!!!

Headhunter

Ich glaube dass ist eher ein Problem mit der MFC...
Ich verschiebs mal einfach

FelixManke

Ja, könnte sein.

Kann mir denn hier jemand weiterhelfen?

KXII

hallo

der fehler kann nicht beim if(file) liegen, da das nur eine abfrage ist und diese keine fehler verursachen kann.. es gibt eigentlich nur zwei möglichkeiten, entwerder ist der pfad doch falsch oder die auxDIBImageLoad funktion hat einen fehler. letzteres ist es mit grosser wahrscheinlichkeit nicht, so das ich darauf tippe, das es der falsche pfad ist.

kopier doch einfach mal die datei tex1.bmp in das arbeistverzeichniss des programmes, und nimm eine konstante als dateinamen. dann siehst du ja woran es liegt. falls das nichts nützt dann klammer die einzelnen anweisungen so lange aus, bis du die zeilen gefunden hast die den fehler verursachen.

meiner meinung nach sieht der code abschnitt fehlerfrei aus, so das ich dir nicht wirklich weiter helfen kann.

File *file=NULL; //erstellt eine variable und initialisiert sie mit NULL, hier kann der fehler auf gar keinen fall liegen, sowas funktioniert immer

if (!filename) return NULL;
//funktioniert immer für jedes filename, hier kann der fehler also auch nicht liegen

file=fopen(filename,"r");
//bringt nur einen fehler, wenn filename unültig ist. filename ist !=NULL, so das er entweder "" ist oder einen wert hat, der aber üngültig ist (auf was falsches zeigt z.b.: "c:\a12345\abc.xyz")

if (file){...}
//dieser teil funktioniert auch immer, da ja nur eine zahl überprüft wird (wie vorher)

...
fclose(file);
//bringt nur einen fehler wenn file ungültig ist, das hast du ja aber überprüft mit if(file) so das es dies auch nicht sein kann.

return(auxDIBImageLoad(filename));
//return ist es nicht! und da die funktion nach aussen hin eigentlich keine fehler verursachen sollte, würde ich sagen ist es sie auch nicht, aber darauf verlassen würde ich mich nicht. mach doch mal ein return(NULL) anstatt return(auxDIBImageLoad(filename)), dann siehst du ob sie es ist.

ich würde darauf tippen das es der dateiname ist. wenn ich solche "merkwürdigen" fehler habe, dann ist es zu 99% immer der dateiname, der entwerder nicht in anführungstrichen steht, oder auf eine datei weisst, die nicht existiert.

viel glück noch beim fehlersuchen

cu

Walli

Du benutzt anscheinend einen Pfad, welcher relativ zu dem deiner Exe-Datei ist... Bastle dir doch mal den ganzen Pfad zusammen... Anstatt "data/tex1.bmp" z.B. "C.\\Prog\\myprog\\data\\tex1.bmp". Den Exe-Pfad holst du dir über GetModuleFileName(...). Die Instanz über AfxGetInstanceHandle(...). Jetzt schneidest du den NAmen der Exe-Datei am Ende ab und hängst deinen Relativpfad daran...

Oliver

Wieso benutzt du CArchive?

mit CFile::Read kannst du doch auch einlesen...

FelixManke

Hi,

Also folgendes: Es stürtzt wegen einem falschen Pfad ab. Versteh ich aber nicht ganz, da das Textdokument, aus der ich die Pfade für die Bitmaps lese, im gleichen Verzeichnis liegt, wie die Textur. Und die Textdatei findet er. Wenn ich aber alles in absoluten Pfaden (c:/data/...) angebe, läuft's mit der AUX_RGB...-Methode.

Ich kompiliere und starte das Projekt aus dem VS.NET mit Strg+F5 (also debugmode ohne debugger). Wo muß denn dann der Ornder liegen? Soll heißen, wo ist denn das "root"-Verzeichnis? Ich dachte, im Arbeitsverzeichnis, so war's als Win32-Projekt vor dem Problem.

KXII

das "root" verzeichniss ist immer dort wo deine exe liegt/erstellt wurde und ausgeführt wird. diesen pfad kannst du in VC 6.0 unter Projekt/Einstellungen/Debug/Arbeistverzeichniss ändern.

wie hast du die verzeichnisstrenner angeben?

so?

"c:\\Test\\Data\\tex1.bmp"

oder so?

"c:\Test\Data\tex1.bmp" ?

die trennstriche muss man in c immer mit "\" angeben! genau wie die anderen sonderzeichen "\n" etc.

FelixManke

Hi,

ich glaube, dass beim Testen aus dem VS heraus ist der "root"-Pfad das Arbeitsverzeichnis. So war's zumindest, als ich eine Win32-Applikation schrieb. Ich habe die Pfade mit c:/data/... angegeben, funktioniert auch.

Unix-Tom

Das rootverzeichniss beim starten der Applikation über VC++ ist das Arbeitsverzeichnis. Also dort wo der Source ist.

Was sagt der Inhalt deiner VarnReturnwerte der Funktionen beim Debuggen?

[ Dieser Beitrag wurde am 19.11.2002 um 10:56 Uhr von Unix-Tom editiert. ]