Jag har en filhanterare i Excel. Om en fil inte hittas vill jag köra Start-menyns sökfunktion automatiskt med filnamnet som argument. Så långt har jag lyckats men om jag kört tex Edit.com eller Command.com innan jag skickar namnet på en saknad fil till ShellExecute, så tar det ca 15 sekunder innan sökfunktion startas, då i och för sig som den ska. Jag har stegat genom programmet och konstaterat att det är i API:n fördröjningen sker. Det spelar ingen roll om jag startat någon av COM-filerna med min filhanterare eller manuellt från Windows Program-meny, samma fördröjning sker ändå. I bägge fallen är det bara första gången API:n anropas som fördröjningen sker, därefter fungerar API:n felfritt. För övrigt hade jag samma problem när jag försökte skicka mappsökvägar till ShellExecute efter att COM-filer körts. Koden på modulnivå ser ut så här<code>Private Declare Function ShellExecute Lib _
"shell32.dll" Alias "ShellExecuteA" _
(ByVal hwnd As Long, _
ByVal lpOperation As String, _
ByVal lpFile As String, _
ByVal lpParameters As String, _
ByVal lpDirectory As String, _
ByVal nshowcmd As Long) As Long
Private Const SW_SHOWNORMAL = 1
Private Declare Function GetDesktopWindow Lib "user32" () As Long</code>Koden i den anropande rutinen ser ut så här<code> Dim hWndDesk As Long
Dim success As Long
Dim sFile As String
If MsgBox(Namn & " saknas på angiven plats" & Chr(10) & Chr(10) & "Vill du söka efter filen?", 35, "Fil saknas") <> 6 Then Exit Sub
hWndDesk = GetDesktopWindow()
success = ShellExecute(hwnd, "find", _
sFile, _
vbNullString, _
vbNullString, _
SW_SHOWNORMAL)
If Success < 33 Then
MsgBox "Kunde inte starta Windows sökfunktion", vbCritical, "Sök " & Namn
Exit Sub
End If
DoEvents
SendKeys Namn, True
SendKeys "{ENTER}", True</code>"Namn" är en variabel för namnet på den saknade filen. Jag har Excel 2000 och Windows 95. Är det någon som kan säga vad som är problemet och om och i så fall hur det kan åtgärdas?

mvh
Lars xl

Glöm frågan!
Nu när jag testar API:n uppstår inte problemet Kanske det beror på att jag startat om datorn eller vad vet väl jag? Fel har det i alla fall när jag utvecklade koden. Återkommer om felet uppstår igen

Jaha, och nu är felet tillbaka. Hjääääälp!

Kan ju bero på att aktuellsökväg ändras och windows måste söka fram Find. Find finns i windows systemkatalog(System32 på NT-system). Borde det inte vara bättre att ange dess exakta sökväg. Kan ju vara det.

Men varför skulle aktuell sökväg ändras endast i de fall när jag kört .COM-filer. I alla andra fall är det problemfritt. Dessutom fördröjs ibland även öppning av mappar efter körning av COM-filer. Ytterligare en konstighet är att problemet kommer och går. Just nu är det inget problem. Kan det vara så att något i systemet överbelastas när jag jobbat i VBA-gränssnittet.

Hur får jag fram sökvägen till Find. Det borde väl vara en API och jag behöver något som täcker Windows 95 och framåt och NT 4 och framåt?

Tror detta skall funka
<code>
Private Declare Function GetSystemDirectory Lib "kernel32" Alias "GetSystemDirectoryA" (ByVal lpBuffer As String, ByVal nSize As Long) As Long

Function SystemDirectory() As String
Dim lpBuffer As String
Dim lReturn As Long
Const MAX_PATH As Long = 255&
lpBuffer = String(MAX_PATH, 0)
lReturn = GetSystemDirectory(lpBuffer, MAX_PATH)
If lReturn > 0 Then
SystemDirectory = Left(lpBuffer, lReturn)
End If
End Function
</code>

Menar du att det skulle starta det jag vill: Start-menyns sökfunktion? Den enda fil som heter Find på hårddisken ligger i C:\Windows\Command och heter Find.exe. Din API returnerar bara C:\Windows\System. Hur ska jag starta sökfunktionen med det? Vid manuell körning (dubbelklick på ikonen) startas Find.exe i ett DOS-fönster, så det är väl det enda den klarar. Min ursprungliga fråga var kanske otydlig, så jag preciserar den ovan. Det är Start-menyns sökfunktion jag vill ha.

Den låg i System32 på XP.

Tror knappast att du behöver bry dig om sökvägen. Find är bara ett namn som talar om vad shellexecute ska göra, och har inget direkt samband med en fil.

Jag tror att det är fel i handtags-parametern. I VB skriver man Me.hwnd men det går inte i VBA för Excel. Jag har därför tagit bort Me - även i andra API-anrop - med framgång och bara skrivit hwnd eller GetForegroundWindow men det tycks vara fel väg, så jag skulle vilja ha tag på ett handtag till anropande Excel-instansens handtag. Vet någon hur man gör?

Det jag märkt är om man använder en felaktig sökväg till katalogen som Find ska starta i så funkar det inte(sFile i ditt exempel).
ShellExecute(0,'find', 'felaktig sökväg', Nil, Nil, SW_SHOWNORMAL);

Hur jag än prövar så är det körning av COM- och BAT-filer, som stör sökningen efter en fil och öppnning av en mapp med ShellExecute, dvs störningen sker på mappval där lpOperation är satt till explore sller find. Jag är dålig på operativsystem, så ursäkta min amatörmässiga beskrivning: När jag kör COM- och BAT-filer, så körs de i DOS-läge eller kanske det heter DOS-fönster, det är vad som är gemensamt, det är då störningen av ShellExecute uppstår och alltid bara en gång (en gång vid sökning och en gång vid öppning av en mapp), aldrig annars. Exekvering av dokument- och programfiler funger med andra ord utan problem. Finns det något sätt att få operativsystemet att släppa/koppla loss DOS-fönstren utan att stänga dem? Det verkar ju som om operativsystemet tar väldigt lång tid på sig för att fundera vad som ska göras, bara för att ett DOS-fönster är eller har varit öppet.

Nu tror jag mig ha märkt ytterligare en signifikant egenskap när *.COM- och *.BAT-filer stör ShellExecute. Det är när jag har en eller flera minneskrävande filer öppna i något program samtidigt med Excel. Det kan röra sig om ett dokument på närmare 2 Mb. När endast Excel tillsammans och några mindre program är öppna sker ingen fördröjning. Jag har en Cyrix 155 MHz-processor, 68 Mb internminne, Windows 95 och 1,6 Mb hårddisk.

Kan det var så att datorn - i fallen med relativt minneskrävande program - är näst intill totalt överbelastat och är det därför buggen uppstår och i så fall, går det att åtgärda programmeringsmässigt? Kan man tex se till att Excel eller ShellExecute får någon form av högsta prioritet för åtkomst av minne och processor? Kan man tex ta minne från DOS-fönster eller annat?

Varför uppstår fördröjningen bara när man har eller har haft ett DOS-fönster öppet och man skickar mappar till ShellExecute (fast bara först gången) och aldrig med vanliga dokument- eller programfiler?