Leaderboard

You need to use _Excel_BookClose example: #include <Excel.au3> Global $oWorkbook = _Excel_BookAttach("bom_for_job.xlsx", "FileName") If @error Then Exit MsgBox(4096, "Excel Book Attach Error", "Unable to attach to bom_for_job.xlsx") _Excel_BookClose($oWorkbook, True)

Since the files are only few hundreds lines, read the whole content of the files, and compare them, it will save you lot of code and complexity, like this : #include <Array.au3> #include <File.au3> #include <MsgBoxConstants.au3> Const $BaseFolder = "C:\2017_BASE\" Const $ModFolder = "C:\2017_MOD\" Const $TargetFolder = "C:\MERGE\" Local $FileList = _FileListToArray($BaseFolder, "*", $FLTA_FILES) If @error = 1 Then Exit MsgBox($MB_SYSTEMMODAL, "", "Path was invalid.") If @error = 4 Then Exit MsgBox($MB_SYSTEMMODAL, "", "No file(s) were found.") ;For $i = 1 To UBound($FileList) ;Short test For $i = 2 To 4 If FileExists($ModFolder & $FileList[$i]) Then If FileRead ($BaseFolder & $FileList[$i]) = FileRead ($ModFolder & $FileList[$i]) Then ContinueLoop FileCopy($BaseFolder & $FileList[$i], $TargetFolder & StringLeft($FileList[$i],StringLen($FileList[$i])-4) & "_BASE.txt", 9) FileCopy($ModFolder & $FileList[$i], $TargetFolder & StringLeft($FileList[$i],StringLen($FileList[$i])-4) & "_MOD.txt", 9) Else FileCopy($BaseFolder & $FileList[$i], $TargetFolder & $FileList[$i], 9) EndIf Next (untested) but you will get the idea

Version 901x (Jan 14, 2020) One minor functionality added : number of rows is now displayed just under the listview, it may be handy sometimes. Other minor changes included (natural sort speed improved)  Download link at the end of 1st post

Try changing your FileOpen to this. $BaseFile = FileOpen($BaseFolder & "\" & $FileList[$i]) Unless there's a specific reason to use ANSI to read the file, you shouldn't need to use it. Also, the 8 specifies that the path will be created if it doesn't exist which in this case is not at all necessary.

_Excel_BookSaveAs

That's what I meant by the infinite loop. I'm wondering if that data just keeps cycling if its able to get it all. I think some of the other well I'm fairly certain other groups of data are either incomplete or just not able to grab them at the second it wants it. For whatever reason I had the module32next() fail but if I force it to continue I was still able to pull some information from it. It may have something to do with the data types in the struct tags. Those structs are finicky and it seems like int,char,ptr are the most reliable. Might simplify the tag to see if I can get more. Byte is seems to be most reliable but casting an int into a byte and trying to pull it back out as a binarytostring seems to break things. (Not in this just structs in general) Edit: ya the example I wrote isn't the greatest I will admit. It was just kinda quick and dirty. It was like 3am and I was just trying to get to some testing. I had a couple issues to iron out, just wanted to get it to the point where it was working and actually returning data. I been working all day so I really haven't been able to play with it. EDIT::!! I'd also like to point out in regards to some values that are either returning 0 or nothing at all, that some of the structs have values in the description that say as much. I just wasn't able to get down to the nitty gritty and let that fact be know in the script. I did cut some off if they were at the end of the struct.

I changed the example to speed it up: and it just gets lost I guess. PROCESS_ID = 0 forever ☹️

Hi everybody Even if they're not recent, both following links are interesting if you want to know how to improve speed in your listview control : https://www.autoitscript.com/forum/topic/67829-_guictrllistview_additem-much-slower-than-guictrlcreatelistviewitem/ https://www.autoitscript.com/forum/topic/132703-correct-way-to-clear-a-listview-solved/ Also LarsJ , in this thread, wrote what follows : "A general approach to listviews is to create listview and listview items with native functions due to speed and then use UDF functions for everything else." I'd like to add 2 comments based on the little experience I got with my "CSV file editor" script : 1) If the data you need to populate your listview is contained in an array, then do not use the native function GUICtrlCreateListViewItem() in a loop, but choose instead the function _GUICtrlListView_AddArray() This function, found in GuiListView.au3 and written by Paul Campbell & Gary Frost is optimized and its speed will be 3 times faster than a loop with many GUICtrlCreateListViewItem() needed to populate the listview. Why is it faster ? Because there's a loop on items & subitems, the loop is included in the function and the buffer involved is opened only once. That's the reason why the next release of "CSV file editor" will be based on _GUICtrlListView_AddArray() instead of GUICtrlCreateListViewItem(), which will allow to populate the listview 3 times faster during the import phase (tests done successfully on arrays of 1000, 10000, 36000 rows) 2) Now let's talk about deleting all items in a listview : => if you added your items with GUICtrlCreateListViewItem() then deleting thousands of items will take a lot of time because each control has to be deleted one by one in a loop, using GuiCtrlDelete() as explained by Gary Frost himself, here => if you added your items with _GUICtrlListView_AddArray() then deleting all items could be done in a snap, like this : $g_idListView = GUICtrlCreateListView(...) ; native-created listview $g_hListView = GuiCtrlGetHandle($g_idListView) _GUICtrlListView_AddArray($g_idListview, ...) ; populating listview (fastest way) _SendMessage($g_hListView, $LVM_DELETEALLITEMS) ; fast deletion + no id's leaks So, if you are sure that your listview items are not native, then you don't need to call _GUICtrlListView_DeleteAllItems() . Just Send the Message $LVM_DELETEALLITEMS and avoid the loop found in _GUICtrlListView_DeleteAllItems() which would inspect each item to know if it's native or not (you know they are not !) A worse idea would be to call _SendMessage($g_hListView, $LVM_DELETEALLITEMS) when all your items are natively created with GUICtrlCreateListViewItem() . Why is that ? Because though deletion appears fast on your monitor, AutoIt will not delete any of the thousands of items controls id's and you'll end with plenty of handle leaks. Have a look at BrewManNH's post, which explains the situation. And even if "we can have up to 64k control ids", imagine a user doing this in the same session : * 1st file imported in listview, 30.000 items, using GUICtrlCreateListViewItem() * Delete them all with _SendMessage($g_hListView, $LVM_DELETEALLITEMS), bad way * Now Autoit would (for example) assign a control id of 30.027 for any new control created * 2nd file imported in listview, 30.000 items, using GUICtrlCreateListViewItem() * Delete them all... and you already reached 60.000 id's all "alive" for AutoIt None of this happens the other way, which is : * 1st file imported in listview, 30.000 items, using _GUICtrlListView_AddArray() * Delete them all with _SendMessage($g_hListView, $LVM_DELETEALLITEMS), good way * Now Autoit would (for example) assign a control id of 27 for any new control created, great * 2nd file imported in listview, 30.000 items, using _GUICtrlListView_AddArray() * Delete them all... and your new controls id would still start at 27, no leak. My conclusion (for now) : _GUICtrlListView_AddArray() rules for both reasons described above

Don't you think this is simply a stupid question? You are asking the mugger whether he's dangerous. So you expect the honest answer here?

No! Wear a condom while coding. Seriously what do you believe the answer should be to such question?

Well you're in a real contentious mood today, aren't ya. I posted it in the AutoIT help section. If it ended up in a different section, maybe there's an issue with the site. But I think JLogan3o13 was probably just mistaken when thought he saw it in the Developer General Discussion area. It would be better if you did not directly contradict your forum users like that, please. Give us the benefit of the doubt, that perhaps we might actually be in a better position to know what we did, better than you do. I'm not trying to personally attack you or anyone. But it feels like you personally attacked me, so I'm getting defensive. You can choose not to believe me- fine. But please don't just flat out contradict me about something that I'm actually in a better position to know about. You need to consider that the moderators and developers on this site are just as capable of mistakes or having wrong information as we are. Again, thanks for the help everyone.