[woof]

Hello,

I have two questions for my little script (see CreateM3U):

1. I'm looking for a definition, what the limit for command line parameters is. I believe it's a operating system limit, not from AutoIt. Can anyone provide some information or links about this issue? I tried with something like below forty files and 1,5 K. Must I find the limit using trial and error?

2. I handle folders (for which text file lists are created) and also their subfolders using recursion. Now with NTFS file system it is possible to create directory junctions and with that create loops. Is there a way to handle this? In FAQ I found the recursion limit of 384 levels, is that the best solution to trust on?

Regards,
Thorsten

[ChrisL]

from the help file

Quote

Note : only 63 parameters can be return by $CmdLine[...], but $CmdLineRaw will always returns the entire command line.

[woof]

Hello,

Quote

from the help file

Quote

Note : only 63 parameters can be return by $CmdLine[...]

sad to hear this. I don't understand why there is such a limit, but I'm also unable to find this in the help file. Have tried the one from 3.1.0, updated to 3.1.1 and searched again with no result. "CmdLineRaw" is only found in "Running Scripts" and "History", but never with this limitation explained. I also seaerched for"63" without relevant success. Can anyone explain a bit more detailed? If this "63 parameters" limit applies, is it the only one or are there others maybe by operating system (which apply to $CmdLineRaw)?

Regards,
Thorsten

Edit: Also looked into online help of current beta with no success. But found this limits:
CMDLINE_MAXPARAMS - 64 - Maximum number of parameters.
CMDLINE_MAXLEN - 4096 - Each parameter can be this many characters.
Don't really understand the second one, can each parameter be that long? So a max of 64 times 4096 would be possible in theory?

This post has been edited by woof: 20 May 2006 - 04:12 PM

[Valuater]

Quote

So a max of 64 times 4096 would be possible in theory?

yes... in theory

8)

This post has been edited by Valuater: 20 May 2006 - 05:28 PM

[ChrisL]

woof, on May 20 2006, 03:57 PM, said:

Hello,
sad to hear this. I don't understand why there is such a limit, but I'm also unable to find this in the help file. Have tried the one from 3.1.0, updated to 3.1.1 and searched again with no result. "CmdLineRaw" is only found in "Running Scripts" and "History", but never with this limitation explained. I also seaerched for"63" without relevant success. Can anyone explain a bit more detailed? If this "63 parameters" limit applies, is it the only one or are there others maybe by operating system (which apply to $CmdLineRaw)?

Regards,
Thorsten

Edit: Also looked into online help of current beta with no success. But found this limits:
CMDLINE_MAXPARAMS - 64 - Maximum number of parameters.
CMDLINE_MAXLEN - 4096 - Each parameter can be this many characters.
Don't really understand the second one, can each parameter be that long? So a max of 64 times 4096 would be possible in theory?

I tried this on a folder with MP3's etc in.
When I drop the folder on it is works very nice but the playlists are only local to the folder is this correct? So I have a few recursive folders and each folder has it's own playlist. I thought I would get one playlist with all the files within all the recursed folders.

Also I dragged a selection of files onto the exe, I managed 31 files before I got an error, but this maybe related to the number of characters in the files, so then I chose some shorter file names and managed 37 files so I guess you do have an AutoIT limit issue and I'm guessing with the number of characters hitting the command line

[ChrisL]

Valuater, on May 20 2006, 04:49 PM, said:

yes

8)

Valuater, see my reply above I don't think you can get any where near that figure

[woof]

Hello,

yes, it's the intention of my tool to create a playlist for each folder.

I tried a bit myself and got the other way round a maximum of 99 parameters I can provide to a script (I only took a list of numers, from "01" to "99", and I use version 3.1.1), after that I got an error message ("Error: Recursion level has been exceeded - AutoIt will quit to prevent stack overflow"). So I'm not wiser as before, the only thing I know more now is that AutoIt itself seems to be the limit, not the operating system.

Regards,
Thorsten

[ChrisL]

Just dropping the parent directory on is cool though, and your limit is then 384 recursive directories deep. Can't see anyone having that many folders deep, and if they do they deserve for it not to work. ;)
Nice work

[woof]

Hello,

I tried a bit and found two limits:

The number of parameters is limited to 99 (in AutoIt version 3.1.1), this differs from AutoIt3 Beta Documentation, where CMDLINE_MAXPARAMS is declared as 64. Or is this stricter limit new to the beta version.

The total length of a command line can be around 2079 chars (on my Win2000 machine) including full drive and path and script exe name. For uncompiled script even less, a command line seems to be limited to 2006 chars in batch or at prompt. So this seems to be a limitation of the operating system (as in my initial post I would like to know of some official documentation on this). Again AutoIt3 Beta Documentation can't be right with it's mention of CMDLINE_MAXLEN as 4096 (whatever this limit applies on, the whole cmd or each item as "each parameter" implies). Maybe interally AutoIt may handle longer parameters, but the operating system will never deliver. Or is XP/2003/Vista better on this?

Is this strange documation already a bug? Should I report it?

Regards,
Thorsten

This post has been edited by woof: 21 May 2006 - 02:14 PM

[woof]

Hello,

now I found something about this in "v3 Bug Reports (Fixed)": Command-line-parameters (limitation) Autoit V3, FIXED 3.1.1.117.

But I'm not sure why the "fixed" applies there. But as I see really the limitation to 64 command line parameters is new to current betas. The length of command line seems to differ so on some systems 4K may be possible. And there is a difference on optained parameters and sent when starting somsting (RunWait etc.).

Also jpm said there, he'll "document in the 'Command line parameters' page the restriction" but obviously this has not happend yet.

Regards,
Thorsten

This post has been edited by woof: 21 May 2006 - 05:16 PM

[Confuzzled]

While it is important to know and understand the limits of the environment you are working within, prudent programming would dictate that approaching these limits should indicate an alternate strategy within your algorithms would be required so that you do not inadvertently hit the limits and your results become undefined.

[woof]

Quote

While it is important to know and understand the limits of the environment you are working within, prudent programming would dictate that approaching these limits should indicate an alternate strategy within your algorithms would be required so that you do not inadvertently hit the limits and your results become undefined.

That's what this thread was for, understanding what the limits are and what i can do about. But do you have an idea, what "an alternate strategy" could look like? Especially when it goes for operating system limits (with too long command line in total, which in most cases will be the first limit that applies when using my tool) a complete other way of communication between app and explorer is needed. Some kind of dropping zone instead of dropping to the icon? Are there examples of such?

Regards,
Thorsten

[Confuzzled]

Inter-process communication is a problem that can be solved in many ways. Semaphores/flags can be set in memory, temporary status files, registry entries, environment variables, etc.
In your example in your first post, if you are just trying to add files recursively into your playlists, just process the directory structure in a loop, calling a function repeatedly (not recursively), adding the file details to your playlist each time you hit another file.

This post has been edited by Confuzzled: 23 May 2006 - 06:23 PM

[woof]

Hello,

processing the files recursively is already working, the problem is the initial call of the program. By now the idea is to start it dragging a bunch of files and folders onto programs icon. That's where the operating system limit applies (or in rare cases the number of cmd line parameters of AutoIt itself). The tool should not be limited like "you cannot drop more than one folder or file to ...". So there is nothing like inter-process communication needed (or possible, I cannot replace explorer). Do you think, there are possible ways to receive mostly the same functionality without limitations of the command line? I'm new to this, how does drag and drop from explorer onto running programs work, like a drop area/a basket to drop files folders onto and use that as input for my tool? Any idea?

Regards,
Thorsten

[Geert]

[ code='text' ]    ( Popup )

#include <GUIConstants.au3>

$Form1 = GUICreate("Drop files in me", 620, 440, -1, -1, -1, $WS_EX_ACCEPTFILES)
$Edit1 = GUICtrlCreateEdit("", 10, 10, 600, 400)
GUICtrlSetState($Edit1, $GUI_ACCEPTFILES)
GUISetState(@SW_SHOW)
While 1
    $msg = GUIGetMsg()
    Select
        Case $msg = $GUI_EVENT_CLOSE
            ExitLoop
        Case Else
        ;;;;;;;
    EndSelect
WEnd
Exit

[woof]

Hey, I'll have to try this later but it looks like I'll love it ;-)

Thanks,
Thorsten

[woof]

Hello,

okay, I believe I'm far to stupid, but what is my problem here? I can only drop a single file, on multiple files only the first is accepted:

[ code='text' ]    ( ExpandCollapse - Popup )

#include <Array.au3>
#include <GUIConstants.au3>

$Form1 = GUICreate("Drop files in me", 620, 440, -1, -1, -1, $WS_EX_ACCEPTFILES)
$Edit1 = GUICtrlCreateEdit("", 10, 10, 600, 400)
GUICtrlSetState($Edit1, $GUI_ACCEPTFILES)
GUISetState(@SW_SHOW)
Dim $cmdFilesArray[1]
While 1
    If GUICtrlRead($Edit1) <> "" Then
        _ArrayAdd($cmdFilesArray,GUICtrlRead($Edit1))
        GUICtrlSetData ($Edit1,"")
    EndIf
    $msg = GUIGetMsg()
    Select
        Case $msg = $GUI_EVENT_CLOSE
            ExitLoop
        Case Else
       ;;;;;;;
    EndSelect
WEnd
_ArrayDisplay($cmdFilesArray,"Here they are")
Exit

OS: Win2000, AutoIt: 3.1.1

How are multiple files received? Are they multiple lines in the input or are they events added one by one (queued together with GUI messages)? Neither is working in this sample. Is this documented in detail anywhere in help file?

Regards,
Thorsten

[Geert]

Maybe this will help you:

[ code='text' ]    ( ExpandCollapse - Popup )

#include <Array.au3>
#include <GUIConstants.au3>

$Form1 = GUICreate("Drop files in me", 620, 440, -1, -1, -1, $WS_EX_ACCEPTFILES)
$Edit1 = GUICtrlCreateEdit("", 10, 10, 600, 400)
GUICtrlSetState($Edit1, $GUI_ACCEPTFILES)

GUISetState(@SW_SHOW)
;~ Dim $cmdFilesArray[1]
While 1
;~   If GUICtrlRead($Edit1) <> "" Then
;~       _ArrayAdd($cmdFilesArray,GUICtrlRead($Edit1))
;~       GUICtrlSetData ($Edit1,"")
;~   EndIf
    $msg = GUIGetMsg()
    Select
        Case $msg = $GUI_EVENT_CLOSE
            ExitLoop
        Case Else
        ;;;;;;;
    EndSelect
WEnd

$cmdFilesArray = StringSplit(StringTrimRight(GUICtrlRead($Edit1), 1), @LF)

_ArrayDisplay($cmdFilesArray, "Here they are")
Exit

[woof]

Hello,

sorry, I don't understand. First, why "StringTrimRight", the filename in array the has ".mp" instead of ".mp3".

Second, I still get only one/first filename. Not only in array, also in edit form only one filename is shown.

Is there anywhere some kind of documentation, what format of drag and drop files I should receive? Geerts soluition says it's a simple text list with one line per file (as he suggests StringSplit). But I only get the first name, not a multiline text...

Regards,
Thorsten

[Geert]

Using StringSplit and @LF as delimiter, the last variable in the array wil be empty. That's why I used StringTrimRight: to erase the last character in the string which in my test was a LineFeed.

You should get an array with all files listed!

What do you mean with "not a multiline text..."
The content of the Edit control is a multiline text. Thats why I used StringSplit!

Geert

This post has been edited by Geert: 25 May 2006 - 10:59 AM