
113590
05.10.2013
FOR Schleifen und CALL Befehl für mich immer noch unverständlich
Hallo zusammen,
leider bin ich mit etlichen Veruchen der Suche immer noch nicht auf vernünftige Hilfe zu FOR Schleifen und der Benutzung von CALL gestoßen.
Soweit ich das verstanden habe, wird bei dem CALL Befehl (z. B.: CALL :TEST) in FOR Schleifen zu einem Programm Code gesprungen, welcher abgearbeite wird als ob man eine externe Batch Datei aufrufen würde und an die vorherige Stell woll CALL aufgerufen wurde zurück springt.
Das man am Ende des eigentlichen Programms ein GOTO :EOF einfügen soll leuchtet mir ein.
Aber woher weis das Script, wann ein Ende des mit CALL aufgerufenen Code erreicht ist.
Muss man nun hier auch ein GOTO :EOF einfügen damit CALL weis wann schluss ist und darf ich in diesem von CALL aufgerufenen Programmteilen dann den GOTO Befehl verwenden ohne die FOR Schleife zu schrotten?
Irgendwo habe ich auch gelesen, dass es beim SET Befehl hierbei auch etwas zu beachten gibt.
Aber leider finde ich den Link nicht mehr.
Aktuell habe ich dieses Problem mit einen Script um DDS Texturen automatisch auf bestimmte größen zu verkleinern.
Jedoch ist das Scipt aktuell nicht annähernd auf einem Stand um hier noch Präsentiert zu werden.
Hier ein Beispiel:
Vielen Dank und liebe Grüße Trecasim
leider bin ich mit etlichen Veruchen der Suche immer noch nicht auf vernünftige Hilfe zu FOR Schleifen und der Benutzung von CALL gestoßen.
Soweit ich das verstanden habe, wird bei dem CALL Befehl (z. B.: CALL :TEST) in FOR Schleifen zu einem Programm Code gesprungen, welcher abgearbeite wird als ob man eine externe Batch Datei aufrufen würde und an die vorherige Stell woll CALL aufgerufen wurde zurück springt.
Das man am Ende des eigentlichen Programms ein GOTO :EOF einfügen soll leuchtet mir ein.
Aber woher weis das Script, wann ein Ende des mit CALL aufgerufenen Code erreicht ist.
Muss man nun hier auch ein GOTO :EOF einfügen damit CALL weis wann schluss ist und darf ich in diesem von CALL aufgerufenen Programmteilen dann den GOTO Befehl verwenden ohne die FOR Schleife zu schrotten?
Irgendwo habe ich auch gelesen, dass es beim SET Befehl hierbei auch etwas zu beachten gibt.
Aber leider finde ich den Link nicht mehr.
Aktuell habe ich dieses Problem mit einen Script um DDS Texturen automatisch auf bestimmte größen zu verkleinern.
Jedoch ist das Scipt aktuell nicht annähernd auf einem Stand um hier noch Präsentiert zu werden.
Hier ein Beispiel:
....... FOR ..... CALL :HSIZE
.....
.....
GOTO :EOF
:HSIZE
SET HSIZE=!choice!
------ ENDE des Sprung Code ------
:VRESOLUTION
set choice=
set /p choice=V-Resolution:
for %%C in (256 512 1024 2048) do IF "!choice!" == "%%C" CALL :VSIZE
ECHO "!choice!" is not valid please try again
GOTO VRESOLUTION
------ ENDE des Sprung Code ------
:VSIZE
SET VSIZE=!choice!
SET PIXEL=!HSIZE! !VSIZE!
------ ENDE des Sprung Code ------
:AUTOMODE
ECHO PIXEL !PIXEL!
ECHO HSIZE !HSIZE!
ECHO VSIZE !VSIZE!
IF "!PIXEL!" == "AUTO" (......
------ ENDE des Sprung Code ------
Vielen Dank und liebe Grüße Trecasim
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 218593
Url: https://administrator.de/forum/for-schleifen-und-call-befehl-fuer-mich-immer-noch-unverstaendlich-218593.html
Ausgedruckt am: 19.04.2025 um 11:04 Uhr
14 Kommentare
Neuester Kommentar
Hallo Trecasim, willkommen im Forum.
GOTO :EOF oder EXIT /B beenden nicht nur den Hauptcode, sondern eben auch eine aufgerufene Subroutine. Wenn du das Ende nicht mit einem dieser Befehle spezifizierst, wird nach Batchmanier einfach mit der nächsten Zeile fortgefahren. Natürlich müssen diese Befehle nicht zwingend am Ende der Subroutine erscheinen, sondern dort wo die Bearbeitung abgebrochen werden soll (bspw. am Ende der Zeile 13 in deinem Code mit einem
GOTO crasht den Aufruf nicht unbedingt. So wie du es in :VRESOLUTION anwendest, ist das in Ordnung (bis auf besagte Zeile 13).
Grüße
rubberman
GOTO :EOF oder EXIT /B beenden nicht nur den Hauptcode, sondern eben auch eine aufgerufene Subroutine. Wenn du das Ende nicht mit einem dieser Befehle spezifizierst, wird nach Batchmanier einfach mit der nächsten Zeile fortgefahren. Natürlich müssen diese Befehle nicht zwingend am Ende der Subroutine erscheinen, sondern dort wo die Bearbeitung abgebrochen werden soll (bspw. am Ende der Zeile 13 in deinem Code mit einem
&GOTO :EOF
).GOTO crasht den Aufruf nicht unbedingt. So wie du es in :VRESOLUTION anwendest, ist das in Ordnung (bis auf besagte Zeile 13).
Grüße
rubberman
Hallo Trecasim,
schön wenn's klappt
Die Art, wie du Code einrückst, macht es zumindest mir ziemlich schwer dir zu folgen. Aber schließlich muss ich ja auch nicht damit klar kommen
Was mir aufgefallen ist:
Grüße
rubberman
schön wenn's klappt
Die Art, wie du Code einrückst, macht es zumindest mir ziemlich schwer dir zu folgen. Aber schließlich muss ich ja auch nicht damit klar kommen
Was mir aufgefallen ist:
- Variablenzuweisungen (bspw. FILEPATH) bei eingeschalteter verzögerter Variablenerweiterung (EnableDelayedExpansion) sind nicht ungefährlich. Hoffentlich hast du nie Ausrufezeichen im Pfad ...
- so etwas wie
IF NOT "!choice!" == ""
kannst du auch mitIF DEFINED choice
abwickeln.
Grüße
rubberman
Hallo Trecasim.
Grüße
rubberman
Das mit den Ausrufezeichen ist mir auch schon aufgefallen, aber wen ich des ändern möchte, müßte ich ja ständig EnableDelayedExpansion deaktivieren und aktivieren.
Nee. Letztlich am Anfang einmal mit DisableDelayedExpansion die Variablen aus dem übergebenen Argument setzen, dann EnableDelayedExpansion spezifizieren. Die Variablenwerte werden in die Subumgebung vererbt. Wenn ich jetzt noch einen minimalistischen VB Code finden würde um des Batch Fenster zu positionieren währe ich fürs erste fertig.
Erkläre mal genauer.Grüße
rubberman
Hast du das .NET Framework installiert? Dort hast du u.a. einen C# Compiler dabei.
*.bat
@echo off &setlocal
REM Pfade für Sourcecode und exe-Datei.
set "src="%temp%\movetoxy.cs""
set "movetoxy="%temp%\movetoxy.exe""
REM Suche csc.exe (C# Compiler).
set "csc="&pushd "%SystemRoot%\Microsoft.NET\Framework"
for /d %%i in ("v*") do (dir /a-d /b "%%~fi\csc.exe" >nul 2>&1 && set "csc="%%~fi\csc.exe"")
popd
if not defined csc (echo C# Compiler nicht gefunden.&pause&goto :eof)
REM C# Sourcecode schreiben.
>%src% (
echo(using System; using System.Runtime.InteropServices; class movetoxy {
echo([DllImport("user32.dll", EntryPoint = "SetWindowPos"^)]
echo(public static extern int SetWindowPos(IntPtr hWnd, IntPtr hWndInsertAfter, int X, int Y, int cx, int cy, uint uFlags^);
echo([DllImport("kernel32.dll", ExactSpelling = true^)] public static extern IntPtr GetConsoleWindow(^);
echo(public static int Main(string args^) {if (args.Length == 2^) {
echo(try {int x=int.Parse(args^); int y=int.Parse(args[1]^);
echo(return (0 == SetWindowPos(GetConsoleWindow(^), IntPtr.Zero, x, y, 0, 0, 0x0001^)^) ? 1 : 0;}
echo(catch {return 1;}} else {return 1;}}}
)
REM Compilieren, Sourcecode löschen.
%csc% /nologo /target:exe /out:%movetoxy% %src%
del %src%
REM Fenster verschieben.
%movetoxy% 10 10
echo %errorlevel%
REM Aufräumen.
del %movetoxy%
pause
rubberman
EDIT Rückgabewert von SetWindowPos verarbeitet.
Hallo Trecasim.
Amen
Manchmal glaube ich es macht sich keiner mehr Gedanken über Virensignaturen, statt dessen wird in einer Whitelist gesucht. Alles was dort nicht gefunden wird, wird angemeckert...
Grüße
rubberman
man was die heute alles als Virus erkennen. Voll nervig.
Da biste ständig am rumpfriemeln in der Ausnahme Liste.
Da biste ständig am rumpfriemeln in der Ausnahme Liste.
Amen
Manchmal glaube ich es macht sich keiner mehr Gedanken über Virensignaturen, statt dessen wird in einer Whitelist gesucht. Alles was dort nicht gefunden wird, wird angemeckert...
Grüße
rubberman