Finns det något sätt att med VB/VBA frigöra minne? Bakgrunden är att jag får en kraftig fördröjning i öppnandet av mappar med API:et ShellExecute om jag har både minnekrävande dokument (ca 2 Mb) öppna och har eller har haft ett DOS-fönster öppet. Jag misstänker att orsaken till fördröjninge ligger i minnehanteringen. Det kan ta upp mot ca tio sekunder att öppna mappen vid första försöket. Sen går det normalt. Fördröjningen sker inte när jag skickar valiga filer till samma API under samma omständigheter.

Jag har en gammal dator:
Windows 95
Cyrix 155 MHz processor
64 Mb RAM
1,7 Gb HD.

Lars, rörande din fråga angående att öppna ett dos-fönster. jag lyckades med det men får ett felmeddelande samtidigt. Detta kanske sporrar dig att finna en lösning?

<code>
On Error Resume Next
channelNumber = Application.DDEInitiate(app:="Cmd", topic:="Cmd")
On Error GoTo 0
</code>

OK, Pelle! Jag börjar fatta. Jag har undvikit DDE. Får ta fram böckerna, tänkarmössan och titta närmare på möjligheterna. Att köra ShellExceute och "find" som lpOperation-argument (som enligt MSDN är ett slags mappval) är i vart fall ingen bra ide. Sökfunktionen är slö i starten även manuellt, dock tar det inte 10 sekunder. Det blir studier några dar. Du får väl ägna dig åt övriga 9999 under tiden. Att öppna mappar har jag överlämnat åt VBA:s Shell och där sker inga fördröjningar och som sagt inte heller för oika typer av vanliga filer som skickas till ShellExecute (utom en sparad sökning (sagt med pipig röst)).

Minnesbesparning åstakommer du genom att dumpa gamla oanvända objekt med set o_namn = nothing, använd eventuella recordsets med clientsidan på servern och måste du hålla datat lokalt så använd getrows.

Jag vill ge API:et ShellExecute mer minne för att starta Windows sökfunktion och öppna mappar utan att stänga några program. Kommer inte din lösning att stänga programmen och kan jag komma åt annat än egna VB-applikationer? Behövs ett annat API för att loopa igenom alla applikationer.

När minnet är överbelastat verkar det ske en växling till diskminne och där uppstår (nog) den fördröjning som är själva problemet. Kör jag ShellExceute uppstår fördröjningen, oavsett om jag öppnar en sparad sökning med API:et eller om jag startar sökningen från Excel-VBA med <code>success = ShellExecute(hwnd, "find", Left(CurDir, 3), vbNullString, vbNullString, SW_SHOWNORMAL)</code>Startar jag däremot sökfunktionen manuellt från Start-menyn sker ingen fördröjning. Det är dit jag vill komma programmeringsmässigt.

Det är ju möjligt att det inte går, som Pelle antytt i ett annat sammanhang, att minnet är överbelastat och delar av minnet måste swappas till HD:n, vilket tar tid. Jag tänker bara att "Windows gör det på en gång, och då borde jag också kunna det". Kanske sökfunktionen på Start-menyn redan är inne i minnet sas och det är därför det inte tar någon tid när man startar den manuellt medan när man kör den via ett API-anrop från Excel-VBA, så måste mer "skrot", som tar tid laddas in? Det konstiga med hela problemet är att det bara är just DOS-fönster som förorsakar fördröjningen - ingenting annat.