Search the Community

Hello, following my previous question, I have moved all potentially instable object interactions into Executes. But it Looks like "="-assignments to object Attributes cannot be done with Execute, only method calls. Using an "$obj = 1" construct, it compares (Eval) instead of sets (Execute) the value. I have tested multiple different combinations, using Execute and Assign, but it seems not to work with object Attributes. :-( Gives following Output: The assign Action using apply (a3) Fails, while assigning it directly, without Assign() works fine. The execute versions compare and do not assign, in both cases. Though, the "Execute" topic in the help file says it executes, not evaluates. I have found a similar, old thread, which explains this behavious but does not give a solution. https://www.autoitscript.com/forum/topic/110228-pass-object-property-as-a-variable/ Is there a way to assign to a com object's Attribute? Or is there anything new to this unexpected behaviour of Execute (at least compared to the help file description and Python's exec). Any help is appreciated, and thank you for all the help so far. Regards, Michael

I didn't want to necropost here: '?do=embed' frameborder='0' data-embedContent>> Using the XML wrapper in the link above (also attached here), how can I enumerate the names within a section in the XML file? Lets say I want to extract all of the setting names inside the below XML, I try using the function _XMLGetAllAttrib but there is no result. I was expecting that $a_names would contain the attribute names. #include <array.au3> #include <XMLDomWrapper.au3> Global Const $sConfigFile = @ScriptDir & "\test.xml" If Not FileExists($sConfigFile) Then $sErrorMsg = "Configuration File FolderMenu.xml Does Not Exist." & @LF & "Default Configuration File Is Used." & @LF MsgBox(4096, "", $sErrorMsg) EndIf If _XMLFileOpen($sConfigFile) = -1 Then $sErrorMsg &= "Error opening " & $sConfigFile & "." MsgBox(4096, "", $sErrorMsg) EndIf Global $a_Names[1] Global $a_Values[1] $a_Return = _XMLGetAllAttrib("SysSettings/SystemSpecific/MODEL/NICPowerSettings", $a_Names, $a_Values, "Setting") If @error = -1 Then MsgBox(4096, "Error", $a_Return) Else _ArrayDisplay($a_Names, "Names") _ArrayDisplay($a_Values, "Values") EndIf <?xml version="1.0" encoding="UTF-8"?> <SysSettings> <SystemSpecific> <MODEL> <NICPowerSettings> <Setting Name="PMARPffload" Value="*PMARPOffload,REG_SZ,0"></Setting> <Setting Name="PMNSOffload" Value="*PMNSOffload,REG_SZ,0"></Setting> <Setting Name="WakeOnMagicPacket" Value="*WakeOnMagicPacket,REG_SZ,0"></Setting> <Setting Name="WakeOnPattern" Value="*WakeOnPattern,REG_SZ,0"></Setting> <Setting Name="EEELinkAdvertisement" Value="EEELinkAdvertisement,REG_SZ,0"></Setting> <Setting Name="ReduceSpeedOnPowerDown" Value="ReduceSpeedOnPowerDown,REG_SZ,0"></Setting> </NICPowerSettings> </MODEL> </SystemSpecific> <Global> </Global> </SysSettings> Test.xml test.au3 XMLDomWrapper.au3

_FileFindEx Get More from File/Folder Searches (formerly _WinAPI_FileFind) Since it's always bugged me that the AutoIT implementation of 'FindFirstFile' and 'FindNextFile' only returned filenames and that extra calls had to be made to get file-size, attributes, short-names, and date/time of file creation,last-access, & last-modification which severely increased the amount of time it took to properly analyze the contents of a folder and it's files, I decided to create an alternative. This uses the same Windows calls as AutoIT, except it returns all the information that it rightfully should for each file found - including: File attributes (in numerical form, not a silly string format)Creation TimeLast-Access TimeLast-Write TimeFileSizeFilename (obviously)8.3 short name (if it is 1. different from the regular Filename and 2. if short-names haven't been turned offReparse Point info (if available)Now, the calling process is a little different, though for the most part not much is required to be altered in existing code. Basically, the attributes-check for folders is a numerical test, and when a folder is found, you *need* to test for '.' and '..' navigation (fake) folders. Also, the 'While' loop changes into a 'Do-Until' loop. Additionally, the first _FileFindExFirstFile() call returns a file, whereas FileFindFirstFile() doesn't (which never made sense to me). To convert times into a readable format, you'll need to pass the array to the _FileFindExTimeConvert() function. Optionally, you can get the _WinTimeFunctions UDF and call those functions using array index constants: $FFX_CREATION_TIME, $FFX_LAST_ACCESS_TIME, or $FFX_LAST_MODIFIED_TIME. Note all _FileFindEx* calls are done using a special array, though 'ByRef' for quicker performance. A nice application I found for this UDF was comparing files/folders - which is pretty easy using 64-bit filetime and file-size comparisons (no need for time conversion there). The ZIP includes 4 files: the _FileFindEx UDF, FileFindExTest, the license agreement (same as below), and _LinkedOutputDisplay. Please note that _LinkedOutputDisplay on its own is a mess - but its included as-is to help see a side-by-side comparison of the output from FileFindExTest. To get all the same information that _FileFindEx provides, the AutoIt functions below would need to be called: FileFindFirst/NextFileFileGetAttrib *** NOTE: This Fails to report on some attributes (Reparse Points, Sparse Files) ***FileGetTime *3 (one for each time - Creation, Last-Access, Last-Modified)FileGetSizeFileGetShortName (note: this provides a full path, rather than just a file name)Please note that for a fair time comparison, a clean boot is needed for each test due to O/S buffering after a scan. Between boots, the order of function calls in 'FileFindExTest' would need to be swapped. In first-run tests, _FileFindEx has consistently been quicker when gathering more than basic filename info. However, running the UDF in 64-bit mode on Vista+ O/S's results in slower performance, hence this note: *IMPORTANT* - Speed is severely affected on certain processors when the script is run in x64 mode. I therefore recommend running/compiling the code in both bit-modes beforehand to see what the speed difference is. On my machine I've found x86 is much faster, whereas x64 is much slower than AutoIt's search functions. Other's have so I'm guessing it must be how optimized the hardware architecture is at running x64 code. Update Log: Download the ZIP Here Ascend4nt's AutoIT Code License agreement: While I provide this source code freely, if you do use the code in your projects, all I ask is that: If you provide source, keep the header as I have put it, OR, if you expand it, then at least acknowledge me as the original author, and any other authors I creditIf the program is released, acknowledge me in your credits (it doesn't have to state which functions came from me, though again if the source is provided - see #1)The source on it's own (as opposed to part of a project) can not be posted unless a link to the page(s) where the code were retrieved from is provided and a message stating that the latest updates will be available on the page(s) linked to.Pieces of the code can however be discussed on the threads where Ascend4nt has posted the code without worrying about further linking.