8
Wie ExePath zerlegen?
Programmiere gerade unter VB 6.0 an einer Anwendung für die ich den Start-Path der Exe brauche.
Ich kann mit ExePath unter VB 6.0 ja wunderbar die Exe incl. Startpfad auslesen. Leider wenn ich den Wert in eine String Variable einlese kann man den String nicht bearbeiten. So nette Sachen wie Left $ (ExecPath, 11) funktionieren einfach nicht. Hat Da wer einen Rat?
Private Declare Function GetModuleFileName Lib "kernel32" _
Alias "GetModuleFileNameA" _
(ByVal hModule As Long, _
ByVal lpFileName As String, _
ByVal nSize As Long) As Long
.
.
.
Retval = GetModuleFileName(hInst, ExePath, Len(ExePath))
MsgBox Left$(ExePath, Retval), , "Anwendungspfad"
datzielvar = ExePath
cut = Len(datzielvar)
cut = cut - 11
datzielvar = Left$(datzielvar, 106)
Private Declare Function GetModuleFileName Lib "kernel32" _
Alias "GetModuleFileNameA" _
(ByVal hModule As Long, _
ByVal lpFileName As String, _
ByVal nSize As Long) As Long
.
.
.
Retval = GetModuleFileName(hInst, ExePath, Len(ExePath))
MsgBox Left$(ExePath, Retval), , "Anwendungspfad"
datzielvar = ExePath
cut = Len(datzielvar)
cut = cut - 11
datzielvar = Left$(datzielvar, 106)
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 170457
Url: https://administrator.de/contentid/170457
Printed on: April 19, 2024 at 04:04 o'clock
8 Comments
Latest comment
Hallo,
ich kenn zwar nur VB.NET, aber gibt es in VB 6.0 nicht auch etwas wie Split, das den String bei den "/" zerlegt und als Array die Teile ausgibt?
Dann müsstest du nur noch alle Teile bis auf den letzten wieder zusammensetzen und fertig.
Mathe172
ich kenn zwar nur VB.NET, aber gibt es in VB 6.0 nicht auch etwas wie Split, das den String bei den "/" zerlegt und als Array die Teile ausgibt?
Dann müsstest du nur noch alle Teile bis auf den letzten wieder zusammensetzen und fertig.
Mathe172
@mathe172
Grüße
bastla
gibt es in VB 6.0 nicht auch etwas wie Split
Gibt es (VB 5.0 kannte das aber tatsächlich noch nicht) ebenso wie InStrRev(), aber wenn bei Micki schon ein Left() nicht funktioniert ...Grüße
bastla
Hallo Micki,
schön das es noch mehr Leute gibt die VB 6.0 nutzen.
Ich habe mit deinem Beispielcode für ExePath keinen Erfolg, bei mir kommt immer
eine leere Zeichenkette heraus.
Ich nutze bei mir jedoch "App.Path" um Pfade zu übernehmen und zu bearbeiten.
Vielleicht hilft dir das weiter.
Gruß
Xolger
schön das es noch mehr Leute gibt die VB 6.0 nutzen.
Ich habe mit deinem Beispielcode für ExePath keinen Erfolg, bei mir kommt immer
eine leere Zeichenkette heraus.
Ich nutze bei mir jedoch "App.Path" um Pfade zu übernehmen und zu bearbeiten.
Vielleicht hilft dir das weiter.
Gruß
Xolger
Hi !
Und wenn wir schon bei der Kritik sind:
Lieber TO, untersteh dich und komm bitte ja nicht auf die Idee, irgendwelche Dateien (z.B. Ini-Files, Datenbanken usw.) im gleichen Verzeichnis (z.B. unter C:\Program Files) wie deine Exe-Datei zu speichern. Das macht man schon seit längerer Zeit (mind. seit Windows 2000) im Benutzerprofil! Dann muss auch der arme Admin, der sich gezwungenermaßen mit deiner Anwendung herumschlagen muss, nicht mühsam die Schreibzugriffe deiner Applikation mit Sysinternals ProcessMon raussuchen und manuell die nötigen Rechte setzen, damit deine Applikation auch ohne Adminrechte (z.B. unter Windows XP) läuft. Die nötigen Pfade für das globale- bzw. lokale Benutzerprofil bekommst Du über entweder über die Systemvariablen (von M$ nicht empfohlen) oder über die API-Funktionen SHGetSpecialFolderLocation, SHGetSpecialFolderPath oder SHGetFolderPath. Nachzulesen hier.
mrtux
Zitat von @bastla:
Gibt es (VB 5.0 kannte das aber tatsächlich noch nicht) ebenso wie
nicht funktioniert ...
Gibt es (VB 5.0 kannte das aber tatsächlich noch nicht) ebenso wie
InStrRev(), aber wenn bei Micki schon ein Left()nicht funktioniert ...
Und wenn wir schon bei der Kritik sind:
Lieber TO, untersteh dich und komm bitte ja nicht auf die Idee, irgendwelche Dateien (z.B. Ini-Files, Datenbanken usw.) im gleichen Verzeichnis (z.B. unter C:\Program Files) wie deine Exe-Datei zu speichern. Das macht man schon seit längerer Zeit (mind. seit Windows 2000) im Benutzerprofil! Dann muss auch der arme Admin, der sich gezwungenermaßen mit deiner Anwendung herumschlagen muss, nicht mühsam die Schreibzugriffe deiner Applikation mit Sysinternals ProcessMon raussuchen und manuell die nötigen Rechte setzen, damit deine Applikation auch ohne Adminrechte (z.B. unter Windows XP) läuft. Die nötigen Pfade für das globale- bzw. lokale Benutzerprofil bekommst Du über entweder über die Systemvariablen (von M$ nicht empfohlen) oder über die API-Funktionen SHGetSpecialFolderLocation, SHGetSpecialFolderPath oder SHGetFolderPath. Nachzulesen hier.
mrtux
Also leider waren die bisherigen Beiträge nicht wirklich konstruktiv!
> Zitat von @bastla:
> ----
> Gibt es (VB 5.0 kannte das aber tatsächlich noch nicht) ebenso wie
> nicht funktioniert ...
Und wenn wir schon bei der Kritik sind:
Lieber TO, untersteh dich und komm bitte ja nicht auf die Idee, irgendwelche Dateien (z.B. Ini-Files, Datenbanken usw.) im
gleichen Verzeichnis (z.B. unter C:\Program Files) wie deine Exe-Datei zu speichern. Das macht man schon seit längerer Zeit
(mind. seit Windows 2000) im Benutzerprofil! Dann muss auch der arme Admin, der sich gezwungenermaßen mit deiner Anwendung
herumschlagen muss, nicht mühsam die Schreibzugriffe deiner Applikation mit Sysinternals ProcessMon raussuchen und manuell
die nötigen Rechte setzen, damit deine Applikation auch ohne Adminrechte (z.B. unter Windows XP) läuft. Die nötigen
Pfade für das globale- bzw. lokale Benutzerprofil bekommst Du über entweder über die Systemvariablen (von M$
nicht empfohlen) oder über die API-Funktionen SHGetSpecialFolderLocation, SHGetSpecialFolderPath oder
SHGetFolderPath. Nachzulesen hier.
mrtux
@mrtux
wo ich Dateien aus welchem Grund ablege hat nichts mit der Händelbarkeit für Admins zu tun sondern nur damit, dass ich da auf Vorgaben eines schon vorhanden Programms mit rekurieren muss!
> Zitat von @bastla:
> ----
> Gibt es (VB 5.0 kannte das aber tatsächlich noch nicht) ebenso wie
InStrRev(), aber wenn bei Micki schon einLeft()> nicht funktioniert ...
Und wenn wir schon bei der Kritik sind:
Lieber TO, untersteh dich und komm bitte ja nicht auf die Idee, irgendwelche Dateien (z.B. Ini-Files, Datenbanken usw.) im
gleichen Verzeichnis (z.B. unter C:\Program Files) wie deine Exe-Datei zu speichern. Das macht man schon seit längerer Zeit
(mind. seit Windows 2000) im Benutzerprofil! Dann muss auch der arme Admin, der sich gezwungenermaßen mit deiner Anwendung
herumschlagen muss, nicht mühsam die Schreibzugriffe deiner Applikation mit Sysinternals ProcessMon raussuchen und manuell
die nötigen Rechte setzen, damit deine Applikation auch ohne Adminrechte (z.B. unter Windows XP) läuft. Die nötigen
Pfade für das globale- bzw. lokale Benutzerprofil bekommst Du über entweder über die Systemvariablen (von M$
nicht empfohlen) oder über die API-Funktionen SHGetSpecialFolderLocation, SHGetSpecialFolderPath oder
SHGetFolderPath. Nachzulesen hier.
mrtux
@mrtux
wo ich Dateien aus welchem Grund ablege hat nichts mit der Händelbarkeit für Admins zu tun sondern nur damit, dass ich da auf Vorgaben eines schon vorhanden Programms mit rekurieren muss!
Hallo,
Wenn du ein Forum suchst, dass dir den kompletten Code gibt, bist du hier falsch. Wenn es dir wirklich nur darum geht, den String zu zerlegen und alles unnötige zu löschen,
dann lies dir doch noch mal ersten durch.
MfG,
Mathe172
Also leider waren die bisherigen Beiträge nicht wirklich konstruktiv!
Wenn du ein Forum suchst, dass dir den kompletten Code gibt, bist du hier falsch. Wenn es dir wirklich nur darum geht, den String zu zerlegen und alles unnötige zu löschen,
dann lies dir doch noch mal ersten durch.
MfG,
Mathe172
1. Ich hab mittlerweile einen ehm. Doz erreicht. Der hat mir gesagt warum das nicht ging.
Jetzt geht es und das reicht mir!
Jetzt geht es und das reicht mir!
Hi !
Der Meinung bin ich nicht. Du hast hier sehr wohl fachlich richtige Antworten erhalten.
Das muss ich auch oft, deshalb muss ich aber noch lange nicht die Fehler des Vorgängers übernehmen.
Was Du machst und nicht machst, ist natürlich deine Sache aber da ich mich bei meiner Admintätigkeit ständig mit solchem Softwaremüll herumärgern muss, erlaube ich es mir, ab und zu mal die Leute auf bestehende Windows Konventionen hinzuweisen, die man normalerweise (und aus gutem Grund) auch einhalten sollte.
mrtux
Der Meinung bin ich nicht. Du hast hier sehr wohl fachlich richtige Antworten erhalten.
Das muss ich auch oft, deshalb muss ich aber noch lange nicht die Fehler des Vorgängers übernehmen.
Was Du machst und nicht machst, ist natürlich deine Sache aber da ich mich bei meiner Admintätigkeit ständig mit solchem Softwaremüll herumärgern muss, erlaube ich es mir, ab und zu mal die Leute auf bestehende Windows Konventionen hinzuweisen, die man normalerweise (und aus gutem Grund) auch einhalten sollte.
mrtux
