jonesy

I had exactly the same issue. I have read the sticky about false positives, and this time it does appear to be quite specific to AVG 8 and AutoItSC.bin from version 3.3.0.0. Symantec AV 10.0.0.359 with an up to date Virus Definition file doesn't find a Virus in version 3.3.0.0. Temporarily, I have reverted to using 3.2.12.1 which AVG 8 doesn't flag as having the virus. Luckily I don't have that many that were compiled with 3.3.0.0. I suspect either a future update of AVG will stop flagging it as a Virus, or a new version of AutoIT will appear - both I hope! When this first arose back in 2006, it was definitely a major problem with the AV software, luckily it hasn't happened since. Whilst I fully accept there is no Virus in the file, could one of the developers please record somewhere the steps they go through to ensure the PC that compiles AutoIT is (and remains) free of any Malware. Please don't take this as a criticism, just a quest for knowledge. If you have an agreed set of procedures/processes for ensuring that the AutoIT C++ Source Code doesn't generate EXE files with malware attached, then the rest of us can learn and use that as a basis for creating AutoIT Scripts that aren't riddled with malware...

Thanks for providing the link to the Windows API Registry Functions. It forced me to re-read the Microsoft Documentation again. The Microsoft "GetPrivateProfileSection" Function suffers from the same 32K limitation which I assume is where the AutoIT limitation comes from. It is a bit of a pity that Microsoft didn't update this function for the Unicode version -> GetPrivateProfileSectionW. I did try writing some INI File Functions in AutoIT about a year ago, but with multiple large INI files the performance wasn't fast enough. So I gave up. With the release of a Unicode only version of AutoIT I was hoping the limitation would magically disappear. Oh well, it was nice to live in hope for a few hours...

Thanks for that. I had read this posting ages ago. From the wording of this and other posts, I thought it was related to Win9x, and since 3.3.0.0 doesn't support Win9x I thought it worth reminding everyone that this is still outstanding.

I know I'm not supposed to submit Bug Reports here, but you did ask.... Possible Bug: IniReadSection 32KB limitation The "Old Bug Reports" say this was fixed in 3.2.5.0, but it is still reproducible in 3.3.0.0 This link doesn't record it as being fixed -> http://www.autoitscript.com/autoit3/docs/a...og_complete.txt The 3.3.0.0 AutoIt3.chm file is the same as the On-Line Documentation -> http://www.autoitscript.com/autoit3/docs/f...ReadSection.htm which still says "Only the first 32767 chars are taken in account in an section due to Win9x compatibility." Version 3.3.0.0 is NOT compatible with Win9x. So either there is another reason for not reading more than 32KB, or this is a bug. There are other references to Win9x in the Help File, most notably on the "Introduction" page. Simplistic code to reproduce the problem: $INIFile=@ScriptDir & '\INIFile.ini' FileDelete($INIFile) For $i=1 To 2800 IniWrite($INIFile, 'Section', StringFormat('%05d', $i), StringFormat('%05d', $i)) Next $Array1=IniReadSection($INIFile, 'Section') MsgBox(0, 'IniReadSection', $Array1[0][0]) The MsgBox should Display 2800, but on my PC it Displays 2730.

I have clicked on the "Bug Reports and Feature Requests" link and I get to the new AutoIT Trac System. Unfortunately, I can't figure out how to login to submit a Bug Report. When I try and login I get redirected to a Trac Error page that says "Authentication information not available." Help...

Did you ever get this to work? I can get the VB script to work, but can't see what's wrong with the AutoIT script. Have you incorporated it into your Remote Administration Suite? (This is looking very impressive by the way). My requirement is to compare records of PCs built using Symantec iCommand, recorded in Active Directory and Centennial, and see which ones still exist and are still in use! I'm fairly happy with extracting the info from other sources, but getting the list of PCs from multiple OUs in 4 domains is a bit of a pain. The VB script shows it can be done. One extra bit of info I will need to track down is the last time the computer password (not user) was changed within AD. I can get a manual export using Hyena, but doing it programmatically would be great. Ideally I'd like to delete redundant computers, which will be the last stage. Lots and lots of requirements. I keep trawling the AutoIT forums, picking up bits here and there, and reading MSDN, but I've still not solved it yet. To give you some idea of the scale of my problem - I can find references to nearly 8,000 PCs, and yet we should only have less than 5,000. So which 3,000 PCs should be deleted? Get it wrong and up to 3,000 users could be complaining...

You may not be a professional programmer, but your coding style indicates you could/should be. Your English aint bad either! I was asking if you had more functions already coded before I started to write them myself, because I'm lazy at heart... I agree that if more functions were to appear in Support, rather than the Scripts & Scraps someone (everyone?) would point out the error of our ways... I agree that Object-programming in general is the way forward, but I'm not sure this is always the case. There are 3 problems with the COM approach to this problem: 1. Performance. It is noticeably slower to use COM to get at the list of Administrators on a P IV 2.8, compared to the almost instantaneous results when using the NetAPI. 2. The entries returned when using COM are not in the same form that the NetAPI call returns. I'm assuming (in my COM based script) that the information I cobbled together will work in all situations. Just because it works for me and my Domain setup doesn't mean it always will. 3. I'm not convinced that COM is the way forward. My understanding is that using .NET programming languages involves moving away from COM, although not OOP. Not sure of my ground here. I'm sure someone will put me straight - I just hope it doesn't hurt.

It sounds like you want to create a Copy Hook Handler to monitor changes in a folder. See: http://windowssdk.msdn.microsoft.com/en-us...y/ms649568.aspx I don't know if this can be done in Autoit, the only examples I've seen are in VC++ and Delphi

Thanks for the advice. I was aware of Scriptomatic and had downloaded it some time ago. I don't know where in Scriptomatic to find the com stuff for what I was trying to do, and it keeps crashing on this PC. I'll have to try again when I get back to work. Having said that, the com way of getting at this information is much slower than using the Network management functions. As I want to check on who has been added to the Local Administrators group on over 4,000 XP workstations, the faster the better.

Amel27 - thanks BRILLIANT! it works!!!! Now all I've got to do is try and understand the how & the why! There are loads more Network Management functions defined by Microsoft, and there are other requests on the Forum asking for help in using "netapi32.dll". Have you got any more of the Network functions that you have already created? I think an include file with (nearly?) all of them in it should be included with a future version of AUTOIT. When I couldn't get it to work, I tried to do the same as this but using OBJ/COM and ADSI. The code below works, but you have to cobble the name together as ADSI doesn't return it correctly. Your version using the Network Management functions is much faster. Now that I've seen a working version, I'll give up on the COM way of doing it. Once again thanks! $Members=_NetLocalGroup(@Computername, "Administrators") msgbox(0,"", $Members[0]) for $i=1 to UBound($Members)-1 msgbox(0,"", $Members[$i]) next exit Func _NetLocalGroup($HOST, $LocalGroup) Global $Members[1] $Administrators = ObjGet("WinNT://" & $HOST & "/" & $LocalGroup) $MemberList=$Administrators.Members for $Account in $MemberList $FullName=StringUpper(StringRight($Account.Parent, StringLen($Account.Parent)-8)) if (StringRight($FullName, StringLen($HOST)+1))=("/" & StringUpper($HOST)) then $FullName=$Account.Name else $FullName=$FullName & "\" & $Account.Name EndIf ReDim $Members[UBound($Members) + 1] $Members[UBound($Members) - 1]=$FullName next $Members[0]=UBound($Members)-1 Return $Members EndFunc

Hi joell, I posted a help request for a similar DLL call here -> http://www.autoitscript.com/forum/index.ph...c=34321&hl= but my one didn't work! So I was happy when "lod3n" directed me to this post. I don't dispute that it worked for you, but copying the source locally, I can't get it to work. I guesssed that using $netapi32 requires a $netapi32="netapi32.dll" entry, but I couldn't decide what to do with the next error. Can you tell me where I can get hold of the strToUnicode function. I know I'm being a bit thick, but how does the code cope with the buffer being created by the netapi32.dll and not AUTOIT. There are quite a few requests for help in using the Network Management Functions, I hope we are nearly there. (I edited this 'cos I can't spell!)

There is an undocumented switch with REGEDIT.EXE (on XP anyway, don't know about other OSs) that lets you export parts of the registry. Here is a working example: regedit /e c:\regfile.txt "HKEY_LOCAL_MACHINE\Software\microsoft\windows\currentversion\uninstall" Edited 'cos I kant shpell...

Help !!!!!!!!!!! Has nobody got a suggestion? This is driving me to distraction. Is it something that can be done, and I'm making a mistake? Is it something that can't be done, and I need to suggest it as an improvement in the Ideas Lab?

Hi, Eventually, I want to be able to use AutoIT to call any of the functions defined here: Network Management Functions I'm just starting out on trying to do this however, and the first function I want to call is this: NetLocalGroupGetMembers - I want to get hold of a list of Administrators on a PC. There does appear to be a problem however. If you call one of these functions to Retrieve Data then the documentation here on Network Management Function Buffers, states that "The system allocates the buffer for the returned information. The caller must pass a pointer variable to the function on input. On successful return, the pointer receives the address of the system-allocated buffer that contains the returned information.". So is it possible to call one of these types of functions at all? You cannot pre-allocate the Struct to receive the data, merely access it after calling the DLL. How can I do this? I know there are alternatives, using calls to external EXE files that have been recorded elsewhere, but that means ensuring the external EXE file is available etc. I'm sure that AutoIT should be able to do this, it is after all the best... I am using AutoIT v3.2.0.1 Here is the code I have got so far (There may be errors in the parameters as well - It doesn't work!!): $servername="\\dgx321" $localgroupname="administrators" $LOCALGROUP_MEMBERS_INFO_3="" $level=3 $prefmaxlen=255 $entriesread=0 $totalentries=0 $resumehandle=0 ; Make the DllCall $NET_API_STATUS=DLLCall("netapi32.dll", "int", "NetLocalGroupGetMembers", _ "wstr", $servername, _ "wstr", $localgroupname, _ "int", $level, _ "str", $LOCALGROUP_MEMBERS_INFO_3, _ "int", $prefmaxlen, _ "long_ptr", $entriesread, _ "long_ptr", $totalentries, _ "long_ptr", $resumehandle); if @error Then MsgBox(0,"","Error in DllCall " & @error); exit endif msgbox(0,"", "NET_API_STATUS [" & $NET_API_STATUS & "]" & @CRLF & _ "LOCALGROUP MEMBERS [" & StringLen($LOCALGROUP_MEMBERS_INFO_3) & "]=[" & $LOCALGROUP_MEMBERS_INFO_3 & "]")

Can anyone help me please. I want to be able to use AutoIT to control the Background Intelligent Transfer Service (BITS) on Windows XP Service Pack 2. I am aware of this posing by GregThomson -> http://www.autoitscript.com/forum/index.ph...st&p=142887 But it should be possible to control BITS without having to resort to using an external EXE. I have looked at the AutoIT COM examples, but they (nearly?) all relate to COM scripting. I can't see how to control BITS which is COM but it isn't scriptable. I don't need a fully developed solution, just something to get me started. Microsoft have documented BITS here http://msdn.microsoft.com/library/default...._start_page.asp Thank you.