Leaderboard

For quite some time now, I have had it in mind to redo and upgrade Cyberslug's GuiBuilder (also called AutoBuilder). Well, that time is finally here. Why you ask? {1} I have always preferred its no nonsense simplicity that allows you to get down and dirty with coding quickly, not hampered by other elements taking up screen space, etc. {2} It is the main reason I am still coding with AutoIt v3.3.0.0 ... the last supported version by GuiBuilder. Haven't others made attempts at updating GuiBuilder? And why not help them? {3} Yes they have. The latest probably being GuiBuilderNxt by jaberwacky, who I did assist to a minor degree. {4] While I have great respect for the work he did, and that done by others, they were not really working on the type of update I wanted. I just wanted an update, with very few extra bells & whistles. {5] I also want a version that I can maintain, that is written in a structure I understand more easily than it currently is. In short, I want it written in the style I code in. To do that, it is necessary that I set aside time, to dissect the last version of GuiBuilder (which was the one I updated to support AutoIt v3.3.0.0), so that I can more fully understand what is going on. In the past, my updates, have just been simplistic tweaks to existing code, without understanding anymore than I had to. This time, it will be entirely different. {6} I don't work well with the way other people code, and it will be enough of a struggle deciphering things as it is. But seriously, why not just use one of the existing GUI creators? {7} I am well aware of all those, but none have the simplicity and directness I want. Apart from basic GUI elements, I manually code everything or copy & paste from prolific examples I have built up over the years. I like to keep things simple, and that extends to less clutter on the desktop working environment ... less to look at. Is this project a collaborative one? {8} NO, not at this stage. It may become that, to some degree, if I get stumped by something. After I have finished the project though, it will be open to others to extend, so at that point it could become collaborative under a slightly different name ... remembering all the points I mentioned previously for my version - maintenance etc. Finally. {9} GuiBuilder or AutoBuilder as it was called at one point, was the very first GUI creator for AutoIt, which you can read about here. I would like to do justice to it and Cyberslug, the original creator, for it was a very important part of AutoIt when it first came out, and was for a very long time, part of the AutoIt install, even for a while after Koda was first included. When it was eventually superseded, I well remember Jon asking if anyone was willing to update it, so that it could be kept as part of the AutoIt install, but as an example only. Some time later, I tweaked it, so that it would work with AutoIt v3.3.0.0, but I didn't revamp the code, which was pretty much all over the shop, so ultimately it wasn't suitable as an example. So here's hoping. Especially as life has a habit of intruding and sending things awry. Wish me luck! P.S. It is my intention to report here from time to time, on how things are going .... maybe even provide some code, discuss difficulties, plans, methods, etc. Source.au3 (last version, Prototype 0.9, supports AutoIt v3.3.0.0 and Win XP) (no resources provided yet, just for reference) Screenshot of v0.9

Will test tomorrow and post the result

Seems this is a ROT13 encoding. just try one of the posted UDFs to translate: Jos

Here is another snippet I have for initialization... (I realized that in my previous attempts I was incrementing the struct incorrectly, but this should do it. ;Get InfCount For $i = 0 To $iCount - 1 $oIInArchive.GetProperty($i, $kpidIsDir, $isDir) If $isDir Then ContinueLoop $oIInArchive.GetProperty($i, $kpidPath, $sName) $sExt=StringTrimLeft($sName,StringInStr($sName,".",0,-1)) If $sExt<>"inf" Then ContinueLoop $iMax=UBound($a7z,1) ReDim $a7z[$iMax+1][10] $a7z[$iMax][0]=$sName $a7z[$iMax][1]=$i $iExtract+=1 Next ;_ArrayDisplay($a7z) $tIndices = DllStructCreate( "int["&$iExtract&"]" ) For $i = 0 To $iExtract-1 DllStructSetData($tIndices,1,$a7z[$i][1],$i+1) Next IArchiveExtractCallback_GetStream(0,$tIndices,0,0) $hResult = $oIInArchive.Extract( $tIndices, $iExtract, 0, $oIArchiveExtractCallback ) ConsoleWrite( "oIInArchive.Extract $hresult = "& _WinAPI_GetErrorMessage("0x"&Hex($hResult)) & @CRLF )

Iczer, The code in post 50 is definitely a minimum implementation which only supports the native 7z-format. A lot of the interface methods eg. $oIInArchive.Open() must be provided with a number of parameters. Some of these parameters are different for different archive types. Therefore, it's necessary to test more or less every single interface method for each archive format. It's far from enough to simply apply the proper archive GUID. Biatu, Interesting.

Look at the bottom of page 3 in the manual. There they show the definition of the data types, which are different than what you are using.

FrancescoDiMuro, Why do you need Jos? I can delete your code if you ask me nicely. M23

Looks like you got the structure definition wrong -- VDWORD realCapacityLow; // (Unit: sector) VDWORD realCapacityHigh; // (Unit: sector) is missing byte raid_index; also appears to be wrong.

Use @DocumentsCommonDir For all users.

@argumentum: Have a look at _Pool_SetTCPsocketOptions in my Pool environment, and the associated constants. Be careful not to confuse the size of the MTU with the size of the TCP buffer, which can hold multiple MTUs. I use: AFAIK, 1472 bytes is the max packet size on LAN. To be honest, my fading brain has trouble recalling where I derived the (multiple-MTU) buffer size of 0x4470h, but the way to figure it out for your system would be to repeatedly call setsockopt followed by getsockopt (to evaluate whether the call was successful) with ever larger buffer sizes, until it fails. EDIT: See also here and here. And see my _Pool_Client_Received for an example of how to deal with packet fragmentation. Hope this helps.

I wish you best of luck

I Think JohnOne means @AppDataDir (User Folder), @AppDataCommonDir is a System folder.

Hi, I recently used _WinAPI_GetProcessFileName, I noticed it uses GetModuleFileNameEx function to retrieve the path, and it requires PROCESS_QUERY_INFORMATION and PROCESS_VM_READ. Well, from Vista there is another function, QueryFullProcessImageName, which requires only PROCESS_QUERY_LIMITED_INFORMATION access rights, and it allows to retrieve some process which GetModuleFileNameEx can't get because of its requirements. Here is an example which shows the issue: #include <WinAPIProc.au3> $array = ProcessList() For $i = 1 To $array[0][0] If $array[$i][1] Then $output1 = _WinAPI_GetProcessFileName2($array[$i][1]) $output2 = _WinAPI_GetProcessFileName($array[$i][1]) If @error Then $output2 = -1 If Not ($output1 = $output2) Then If Not ($output1 = -1) Then ConsoleWrite($output1 & "--> _WinAPI_GetProcessFileName2" & @CRLF) If Not ($output2 = -1) Then ConsoleWrite($output2 & "--> _WinAPI_GetProcessFileName" & @CRLF) EndIf EndIf Next Func _WinAPI_GetProcessFileName2($iPID) Local $dwDesiredAccess = __Iif($__WINVER < 0x0600, 0x0410, 0x1000), $sPath = "" Local $aRet = DllCall("Kernel32.dll", "HANDLE", "OpenProcess", "DWORD", $dwDesiredAccess, "BOOL", False, "DWORD", $iPID) If @error Or $aRet[0] = Null Or $aRet[0] = 0 Or $aRet[0] = Ptr(0) Then Return SetError(-1, 0, -1) Local $hProcess = $aRet[0] If $dwDesiredAccess = 0x0410 Then $aRet = DllCall(@SystemDir & "\psapi.dll", "DWORD", "GetModuleFileNameExW", "HANDLE", $hProcess, "HANDLE", 0, "wstr", "", "DWORD", 65535) Else $aRet = DllCall("Kernel32.dll", "BOOL", "QueryFullProcessImageNameW", "HANDLE", $hProcess, "DWORD", 0, "wstr", "", "dword*", 65535) EndIf If Not (@error Or $aRet[0] = 0) Then $sPath = $aRet[3] DllCall("Kernel32.dll", "BOOL", "CloseHandle", "HANDLE", $hProcess) Return $sPath = "" ? SetError(-1, 0, -1) : $sPath EndFunc ;==>_GetProcessPath