system vs. ShellExecute

[Net-srac]

Tach ihrs,

ich hab mittels vieler += einen laaangen befehl mit vieeelen parametern in einen CString "befehl" geschrieben (im Visual C++).

dann hab ich einfach system(befehl); gesagt, und er hat ihn ausgeführt.

Wir kann ich denn sowas mit shellexecute machen? ich hab schon in der MSDN geschaut, verstehe es aber nicht.

Thnx4Help

[Klotzkopp]

ShellExecute hat den großen Vorteil, dass es mit Anwendungen verknüpfte Dateien und URLs 'ausführen' kann.

ShellExecute( NULL, "open", "calc", NULL, NULL, SW_SHOWDEFAUL );

started den Taschenrechner,

ShellExecute( NULL, "open", "bla.doc", NULL, NULL, SW_SHOWDEFAULT );

öffnet die Datei mit Word,

ShellExecute( NULL, "open", "http://www.google.com", NULL, NULL, SW_SHOWDEFAULT );

started den Browser usw.

ShellExecute startet allerdings nicht den Kommandozeileninterpreter (command/cmd), daher funktioniert

ShellExecute( NULL, "open", "dir c:\\", NULL, NULL, SW_SHOWDEFAULT );

nicht, weil dir ein interner Befehl ist, der in den Kommandozeileninterpreter eingebaut ist.

In dem Fall kann man aber den Umweg über eine .bat-Datei gehen.

[Net-srac]

angenommen ich hab jetzt ein programm, das durch viele parameter erst richtig arbeitet kann ich das dann auch in eine CString schreiben und dann da rein bauen?

Also so hier:

CString prg="C:\programme\mmc97\ftd c:\sandbox\text.txt as20000 t.anthf.w.text.txt u=me";

ShellExecute( NULL, "open", prg , NULL, NULL, SW_SHOWDEFAULT );

Weil genau das funtzt bei mir net.

[Klotzkopp]

Die Parameter musst Du getrennt angeben:

CString prg="C:\\programme\\mmc97\\ftd";

CString param ="c:\\sandbox\\text.txt as20000 t.anthf.w.text.txt u=me";

ShellExecute( NULL, "open", prg, param, NULL, SW_SHOWDEFAULT );

[beron]

Also, du führst etz sicherlich folgende Codezeile aus:

ShellExecute( NULL, "open", prg, param, NULL, SW_SHOWDEFAULT );

Deine 1. CStringVariable heist prg,

die solltest du aber nicht direkt übergeben,

übergib stattdessen mit .GetBuffer(0) einen Zeiger

auf's erste Element deines CStrings,

das sieht dann so aus:

ShellExecute( NULL, "open", prg.GetBuffer(0), param.GetBuffer(0), NULL, SW_SHOWDEFAULT );

Ist sicherer!

bye

JO

[Klotzkopp]

Original geschrieben von ffGebaeck

übergib stattdessen mit .GetBuffer(0) einen Zeiger

auf's erste Element deines CStrings,

Ist sicherer!

Das ist, mit Verlaub, Quatsch

GetBuffer gibt einen Zeiger zurück, der nicht const ist, mit dem man also in den String schreiben kann. Das ist hier nicht nötig, weil ShellExecute den String nicht ändert.

Letztendlich ist GetBuffer unsicherer, weil der zurückgegebene Zeiger Änderungen des Strings erst ermöglicht, auch wenn diese sich erst dann auswirken, wenn man ReleaseBuffer aufruft. Wenn man das nicht macht, dann ist GetBuffer sinnlos.

[orsino]

Original geschrieben von Klotzkopp

ShellExecute startet allerdings nicht den Kommandozeileninterpreter (command/cmd), daher funktioniert

ShellExecute( NULL, "open", "dir c:\\", NULL, NULL, SW_SHOWDEFAULT );

nicht, weil dir ein interner Befehl ist, der in den Kommandozeileninterpreter eingebaut ist.

In dem Fall kann man aber den Umweg über eine .bat-Datei gehen.

so gehts

ShellExecute(NULL, "open", "cmd", "/k dir c:", NULL, SW_SHOWNORMAL );

[Klotzkopp]

Original geschrieben von orsino

so gehts

ShellExecute(NULL, "open", "cmd", "/k dir c:", NULL, SW_SHOWNORMAL );

Jau, aber nur unter NT/2000/XP