orbs

@0Ethan0 thank you for reporting this, and apologies for the late reply. i'll address this issue shortly.

welcome to AutoIt and to the forum! i would begin by consulting the support of your app. you are probably not the first to encounter such a need, so explain the situation to them, they would probably come up with an official solution. they are paid to do so. that said, automatic login is probably doable in AutoIt, but it might fall short of the forum rules, so will not be discussed here.

@jmp. 1) you do not need to use _DateAdd() and thus the date format has no importance in this case. this is because you simply want to add a string to another string. 2) if you are concerned about the data omitting the time part (i.e. the HH:MM:SS part is missing), that is also a simple string check. 3) there are no error check methods in your snippet. you are not checking if $iwebdate (which you designate as integer, why?) actually contains valid data. 4) one cannot help but wonder about the reasoning for this. at least a few eyebrows were raised reading your topic i'm sure.

instead of using the local SYSTEM account, create a dedicated account with sufficient rights in both local target directory and server share. if this is a domain environment, that should be quite easy. if this is a workgroup, it is only slightly less simple - you'll need to create an account on the server and use it for the server access, while using the local dedicated account to run the task. you can make that account invisible in Windows logon screen, if that troubles you.

that's what i linked to in the above quote; not too obvious, apparently... still, this would come in handy once the program knows which file to load, with respective fields; and that is what the OP is asking, or so i think.

SQLite is a typical choice for simple apps, therefore i mentioned it, but merely as an example. of course any database will do the job. the point i'm trying to make is you should NOT load all files simultaneously to memory. only once the user has selected a file (by the five field criteria), that file is loaded and displayed. once the user is finished dealing with that file, dump the file from memory and load another one. as for displaying and working with a file, another option you have is not to load the file in your app, but summon the all-mighty Excel to do it for you. Excel is ideal for simple tabular displays (and for rather more complex ones also, if you are familiar with VBA), and you can pre-format a template to be visually appealing and functional for your needs. Excel user interface is highly - and i cannot stress "highly" enough - customizable. so, if you can manage the part where the user selects a file by the five field criteria, and you can display and work with the file, then what challenges are you still facing?

that one eludes me. what exactly do you mean by that? coding a treeview with known values should not be too hard. do you really need to display millions of records simultaneously? i doubt any human would find that useful. if you really do, there are solutions to that; but please try to explain exactly what is the user supposed to see and work with. now, if i understand correctly, the user is supposed to select which "Country","Profile","Region","Service" and "Source" they are interested to see, and your program should display the relevant file, with the rest of the fields? (or probably only the rest of the fields, because the first five are predetermined by the user). is this correct? if so, your solution is quite simple. create a single SQLite table with six columns, and for each input file, dump all rows but only the first five fields into that table, and in the sixth column, add the name of the file. so when the user selects the values for the first five fields, query the table to know which file to present, and load into memory only that file, to display in a listview, or suggest the user some additional filtering before displaying the file. one other, crude and simple but probably not the most efficient approach, is to simply dump the entire batch of files into a single table, with whatever columns required, leaving non-existent columns empty. then query that table according to users' needs. so, please be more detailed in your description of user interface, so we can suggest the better solution. a screenshot perhaps might prove helpful.

this is most definitely NOT the way to do it, and it wouldn't take more than a few calls to _AddToList() to figure out why. calling a function from within itself, as often called "recursion", is used in a different manner, for different reasons. NOT what you are doing. "Goto" is also a poor scripting strategy, and no wonder modern scripting languages (AutoIt included) do not support it altogether. the way to go is using a loop. 1) first, declare all your Local variables at the top of the functions (not whenever you first assign a value to them). 2) then, consider the code starting with this line: $sFileSelectDialog = FileOpenDialog('Select Session Files', $WorkingDir, 'Data Files (*.edl; *.shw)', 4) until the end of the function (excluding the last call to _AddToList(), which should be removed). 3) enclose all this section in a loop, like this: Do {the said section of code} Until {whatever condition you choose to end the function and return to the calling script, or False if you never do} also, don't have a Global variable $SetName declared inside a function _CreateShowFile(). and, as you have already discovered, if the user does not input anything in the inputbox, you'd have an invalid file name to work with. so test for valid input. flogging aside 🙂 , you might want to employ a few best practices . this is not an easy reading, especially for non-native English speakers; but it is worthwhile. i would highly recommend for start, give your variables meaningful names, and put comments wherever adequate. consider this: if in six months time you'd be revisiting that code, would you understand what's going on?

you should not be needing to call _CreateShowFile() twice. i thought you wanted to avoid the need of asking the user for a SHOW file, so the MsgBox() section, along with the second call to _CreateShowFile(), becomes completely unnecessary. as for the second snippet, what does it do? you execute the same command whether $UpdatedFile is or isn't... if it's for debug, then skip the condition check and put only the MsgBox line immediately after you get the value from _CreateShowFile().

does your function already know the name of the desired .shw file, or are you willing to accept any file with the .shw extension as valid? also, the snippet you described that does not work, 1) where is it supposed to fit in your program? 2) the $UpdatedPath variable is Local to function _CreateShowFile(), so inaccessible to the calling script. either make it Global, or Return that variable from the function to the calling script. add this line as the last line of _CreateShowFile(): (just before the EndFunc line) Return $UpdatedPath and when calling the function from the script, line 36, do like this: $UpdatedPath = _CreateShowFile($ListView) (of course, declare a Local $UpdatedPath in _AddToList(), and use it later on.) these two statements combined, allow the value from _CreateShowFile() to be used in _AddToList().

have you noticed there is AutoIt internal function FileExists() ? i trust the other File* functions would come in handy too.

probably not, but it seems the safer approach, because if an error message is detected, you'd probably have to activate it anyway. first, are you certain the desktop does not go to screensaver/lock/sleep/hibernate? any of those will cripple your automation. second, instead of using Send() and MouseClick() use ControlSend() and ControlClick(), they are more robust. sounds like "normal" Windows system instability 😐 ... i'd make sure the workstation runs as small as possible amount of processes and services that are necessary for the automation, and i'd make sure i have more than enough RAM available. go ahead, that's how it works - if you're not sure, you test and see if it makes a difference. same as above. it may help, it may not, but you won't know until you test. absolutely no problem there. for me it's been a (perhaps long overdue...) habit to compile my code as 32-bit, because i'm never fully certain as to what environment my code may find itself running on, and 32-bit offers better backward compatibility.

thank you @Melba23 for this fine UDF, it has been very helpful! i've stumbled upon an issue, though. it took me a while to hunt it down, but it seems there's an issue when the GUI is created with the $WS_EX_LAYOUTRTL extended style. the issue is that the scrolling does happen, but the GUI is either not updated, or updated in a disordered fashion. to reproduce, add the said style to one of the examples in the zip file of the UDF. for example, in the file GUIScrollbars_Ex_Example_3.au3 (my favorite example), change line 5 from: $hGUI_1 = GUICreate("BEFORE", 500, 400, 100, 100) to: $hGUI_1 = GUICreate("BEFORE", 500, 400, 100, 100, Default, $WS_EX_LAYOUTRTL) and see what happens. the same modification applies to any example (and to my current project, naturally) as far as i tested. please have a look and see if you can put some sense into it 🙂 best regards!

@AGlassman, please do not rely on the engine to handle such things for you. if you need the function to return a specific @error value (or @extended, or return value) please put yourself in a habit to set it explicitly. it will save you a lot of trouble. in more ancient programming languages, when you declared a variable, you had to initialize it to zero, or it might contain some random value. this i find still to be a solid advice. and the help file does clearly state, "Unless SetError() is called, then @error will remain 0 when the function ends. This means that in order for @error to be set after a function, it must be explicitly set. "

in short, no. if a user is sophisticated and motivated enough, they will have your source code. as to how, that's beyond the scope of this forum, and naturally against the forum rules to discuss. but: what you can do is instead of selling (and halfheartedly protecting) your code, sell (and maintain) support for it. sure, they can have your code, but who's better than the author himself to provide support for it? support, may i remind, includes not only present aspects like bug fixes and user training, but also users requirements analysis, customization, feature requests, and in general - future aspects. in short, yes, and quite simply too. your AutoIt GUI can be fully customized. so, have a look at your desired expensive software - fonts, color scheme, controls layout, etc. - and mimic its appearance in your AutoIt GUI. P.S. welcome to the AutoIt forum!