CFindFile.FindFile bei Ordnernamen mit Punkten

[Coalminer]

Ich habe folgenden Code:

CFileFind cffFinder;

if(!cffFinder.FindFile(m_sProjPath))
	{
		AfxMessageBox("Project-Path wrong !");
		return(TRUE);

	}

Dieser Code soll eine Überprüfung machen ob ein vom User angegebener Pfad tatsächlich existiert.
Das funktioniert auch ganz gut.

Nur hab ich ein Problem:
Der vom User angegebene Pfad kann auch so aussehen:

C:\192.160.0.250

In dem Fall fuktioniert das so nichtmehr.
Wie schreib ich nun also ein Stück Code das prüft ob ein Ordner existeiert der auch Punkte im Namen enthalten darf ?

 

[uhu01]

Hy!

Ich habe gerade so ein ähnliches Problem, allerdings arbeite ich mit der WinAPI. Dort sieht der Code so aus:

BOOL CProjekt::IsValidPath( const std::string _path) const {
	WIN32_FIND_DATA w32fd;
	HANDLE hFind = FindFirstFile( _path.c_str(), &w32fd);
	if (hFind == INVALID_HANDLE_VALUE) {
		FindClose( hFind);
		return 0;
	FindClose(hFind);
	return 1;
}

Ich weis dass das nicht MFC ist, aber als Lösung im Notfall immer noch zu gebrauchen.
Das einzige Problem ist, das man bei Pfaden wie C:\ wenn kein Ordner angegeben wurde an _path noch ein *.* dranhängen muss, was aber auch nur funktioniert wenn es Dateien/Ordner auf dem Laufwerk gibt. Dafür suche ich gerado noch eine Lösung.

Wie gesagt, ist sicher nicht die erste Lösung zu der man greifen sollte wenn man mit der MFC arbeitet, aber im Notfall sicher zu gebrauchen.

mfg
uhu01

 

[Coalminer]

FindClose( hFind);

muss man das machen ?
das wird in deinem Fall doch nur ausgeführt wenn "hFind == INVALID_HANDLE_VALUE"

Wie gesagt, ist sicher nicht die erste Lösung zu der man greifen sollte wenn man mit der MFC arbeitet, aber im Notfall sicher zu gebrauchen.

Gibt es einen Grund WinAPI und MFC nicht zu mischen ?

 

[uhu01]

Hy!

MFC und WinAPI zu mischen kann einfach unübersichtlich werden, und geht gegen das Klassenkonzept der MFC. Aber funktionieren wir es auf jeden Fall.
Und beim Formatieren nach dem kopieren scheint eine Klamemr verloren gegangen zu sein. Die gehört hinter das return 0:

	WIN32_FIND_DATA w32fd;
	HANDLE hFind = FindFirstFile( _path.c_str(), &w32fd);
	if (hFind == INVALID_HANDLE_VALUE) {
		FindClose( hFind);
		return 0;
	}
	FindClose( hFind);
	return 1;

so gehört es.

Achja, wenn man den Code unter XP verwendet funktioniert das anhängen von *.* immer, da es auf jedem Laufwerk den Ordner "System Volumen Information" gibt. Für den Fall müsste der Code dan noch um ein if erweitert werden.

EDIT:
Hier der erweiterte, hab ich schon getestet

int IsValid( std::string _path) {
	std::string strFullPath;
	if( _path.length() == 3 && _path[1] == ':' && _path[2] == '\\')
		strFullPath = _path + "*.*";
	else
		strFullPath = _path;

	WIN32_FIND_DATA w32fd;
	HANDLE hFind = FindFirstFile( strFullPath.c_str(), &w32fd);
	if (hFind == INVALID_HANDLE_VALUE) {
		FindClose( hFind);
		return 0;
	}
	FindClose( hFind);
	return 1;
}

Geht warsch. noch etwas eleganter, aber es funktioniert.

mfg
uhu01

 

[Coalminer]

hm - jetzt hab ich schon das nächste Problem mit der Pfadangabe:

//Kopier den Inhalt des Projektoordners nach tmp_tar
	char cFileSourceDir[MAX_PATH] = {'\0'};								
	char cFileDestDir[MAX_PATH] = {'\0'};
	SHFILEOPSTRUCT ShellFileOP;

	sprintf(cFileSourceDir,"%s",m_sProjPath);
	sprintf(cFileDestDir,  "%s\\tmp_tar",cOrigDir);

	ShellFileOP.hwnd	= GetSafeHwnd();
	ShellFileOP.wFunc	= FO_COPY;
	ShellFileOP.pFrom	= &cFileSourceDir[0];
	ShellFileOP.pTo		= &cFileDestDir[0];
	ShellFileOP.fFlags	= FOF_NOCONFIRMMKDIR;

	SHFileOperation(&ShellFileOP);

Wenn in m_sProjPath ein Pfad mit Punkten im Ordernamen steht kopiert er den Ordner als Ordner (wie wenn man in Windows den Ordner mit der Maus auf ein anderes Laufwerk schiebt).

Wwenn keine Punkte im Pfadnamen enthalten sind nimmt er den Inhalt und kopiert ihn
(wie wenn man in Windows alle Dateien "in" einem Ordner markiert und dann diese verschiebt

Wie schaff ich es das er beide Ordner gleich behandelt ?

 

[uhu01]

Hy!

Da lass ich lieber mal die Leute ran die sich wirklich mit der MFC auskennen

mfg
uhu01

 

[Coalminer]

Da lass ich lieber mal die Leute ran die sich wirklich mit der MFC auskennen

Weiss jetzt nicht was du mir damit sagen willst...

aber genau deshalb bin ich hier !

 

[uhu01]

Hy!

Ich meinte das ich mit der MFC nicht gut genug auskenne um dir diese Frage zu beantworten.

mfg
uhu01

 

[Coalminer]

oje, Asche auf mein Haupt

das zweite Problem zieh ich zurück
jetzt geht alles

ich hab an anderer Stelle was falsch gemacht
der Source stimmt und funktioniert.