woof

Don't hurry, no need for a fast solution, my script basically works, I just want it nicer and want to try things. "C:\Programme\Multimedia\CreateM3U\test2.dll" (I renamed test file, but also in script), no network involved. I also tried "C:\test2.dll", no luck. Regards, Thorsten

Hello, not here (2000 SP4). Is there a way to "debug" a bit to find problems? Regards, Thorsten

Hello, sorry, I'm only part time on this problem at the moment. I tried so, I hope I got you right, dummy as "1", real animation as "2". No luck (download). Regards, Thorsten

Hello, for my script (CreateM3U) I tried to compile my resources to a dll and use them with AutoIt. I have a .avi which works great called from file system. Trying to call the .dll resource does not work, I don't understand why. Help file in GUICtrlCreateAvi indicates "The filename of the video. Only .avi files are supported.", but example refers to "shell32.dll" and works like charm. The "subfileid" in example is "150" and looking with Resource Hacker into shell32.dll shows the animation named also "150". In my self compiled dll (with Resource Hacker) it is named "4", but changing ani reference in example to this does not show my animation: $ani1 = GUICtrlCreateAvi (@ScriptDir&"\CreateM3U.dll",4,50,10)As I said, calling the .avi instead works with no problem even in example script, so I think it has no problems itself. Also the animation in .dll is played in Resource Hacker. (Download my dll.) What am I doing wrong, what's the point I'm missing? BTW, will there ever be a way to load a bitmap from .dll? GUICtrlCreatePic does not support something like that by now (no "subfileid"), am I right? Regards, Thorsten

Hello, after I was successful this way (after updating to latest beta version) I just want to add the solution to other problems of this code (in post #18). Replace $cmdFilesArray = StringSplit(StringTrimRight(GUICtrlRead($Edit1), 1), @LF) with this $tmp = StringStripWS(StringStripCR(GUICtrlRead($Edit1)),2) If StringInStr($tmp,@LF) Then $cmdFilesArray = StringSplit($tmp,@LF) Else _ArrayAdd($cmdFilesArray,$tmp) EndIf On my system the dropped filelist included linebreak as @CRLF, so @CR must also be removed. And I think instead of just removing one char on the right using StringStripWS($String,2) is more safe. The biggest problem is that StringSplit() does not return a one-element-array if no splitter is in string. Why? Regards, Thorsten

Hello, I strongly believe that is a bug. Because as I now updated to latest beta your former code (using edit form) now does as it should. So for that obviously the 3.1.1 is buggy ;-) To confirm to you: For me the list example also does not do multiple files... Regards, Thorsten

Hello, again: I take source code from post #18 here, save, double click, mark three files in explorer, drag and drop into edit form of the script window. In edit form only one filename is listed, I close the window and get a popup, where also only one filename is in array, and this filename is shorten by one on the right. I get no more than one filename in array, I get no @LF at the end of the only line I have. If this works for you, why not for me? Have you tested your own code? What OS (mine is Win2000)? Regards, Thorsten Addition: When I drop a second time, the first entry is replaced, only editing by hand leaves more than one filename/line in edit form.

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

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: #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

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

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

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

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

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

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