dpryan

@jchd Good point. I don't really need 4k blocksize support, but I'll look into that. It seems that this dos command will output the relevant info, but there might be an easier way to do it: wmic partition get BlockSize, StartingOffset, Name, Index @kylomas It's useful anytime you want to read raw data outside of a filesystem. Perhaps you had data on a SD card, but then you accidentally reformatted the drive and you want to recover the data. Or maybe you want to access data that isn't contained in a file. For example, what does the Master Boot Record (MBR) on your computer look like? According to the specification, it can be in one of two different formats, but always ends in 0x55AA for the "boot signature." To read your MBR, try this code (basically the same thing as the original post, but pointing to PhysicalDisk0 and displaying the first 512 bytes): #RequireAdmin #AutoIt3Wrapper_UseX64=n #include <WinAPI.au3> $sFileName = "\\.\PhysicalDrive0"; $iCreation = 2; OPEN_EXISTING $iAccess = 2; GENERIC_READ $iShare = 2+4; FILE_SHARE_READ + FILE_SHARE_WRITE $hFile = _WinAPI_CreateFile($sFileName, $iCreation, $iAccess, $iShare) If @error Or $hFile = Ptr(0) Then $str = "Could not open file "&$sfilename&@CRLF $str &= "Error: "&@error&@CRLF $str &= "Handle: "&$hFile MsgBox(0,"Error: _WinAPI_CreateFile",$str) Exit EndIf MsgBox(0,"Success: _WinAPI_CreateFile ","Handle: "&$hFile) _WinAPI_SetFilePointer($hFile,0); Beginning of file If @error Then MsgBox(0,"Error: _WinAPI_SetFilePointer",StringFormat("Could not move pointer. (Error %d)\n",@error)) EndIf Global $nBytesReceived $tBuffer = DllStructCreate("byte[512]") _WinAPI_ReadFile($hFile, DllStructGetPtr($tBuffer,1), 512, $nBytesReceived) If @error Then MsgBox(0,"Error: _WinAPI_ReadFile",StringFormat("Could not read file. (Error %d)\n",@error)) EndIf If $nBytesReceived<512 Then MsgBox(0,"Error: _WinAPI_ReadFile",StringFormat("Only %d bytes read.\n",$nBytesReceived)) Else MsgBox(0,"Results",Hex(DllStructGetData($tBuffer,1))) EndIf

I don't really know anything about this, but have you tried using #RequireAdmin?

Done. I justed edited my OP since the changes were minor. Note that the original code (with arbitrary read offset amounts) did work if you were to point to a file ("C:test.txt"), but not for raw filesystem and drive accesses (".C:" or ".PhysicalDrive2"). I changed the code to read a block of 512 bytes, and now it works.

I finally got this working. It looks like you need to read in multiples of the blocksize (512 bytes). Offsets must also be a multiple of the blocksize. For example, reading 1, 2, 511, or 513 bytes all fail. But reading 512 bytes works.

I'm trying to read raw bytes from a removable drive using the WinAPI functions (_WinAPI_CreateFile, _WinAPI_SetFilePointer, _WinAPI_ReadFile). Here is the MSDN reference for CreateFile and ReadFile. My removable drive is mounted at Z:. (But for testing you can probably used a fixed drive like C:. It gives me the same results.) After some trial and error, I was able to get the CreateFile function to return a (seemingly) valid handle. It seems to work correctly if I enter the drive like this: ".Z:", provided that the share mode includes read/write. (If I don't set the share mode like that, then the returned handle is zero for some reason.) Entering ".PhysicalDrive2" also seems to work, and is also a little more lenient on the share mode. The problem is that when I pass it to the ReadFile function, it reports zero bytes read and the data seems to be just zeros. Any ideas? #RequireAdmin #AutoIt3Wrapper_UseX64=n #include <WinAPI.au3> $sFileName = "\\.\C:"; $iCreation = 2; OPEN_EXISTING $iAccess = 2; GENERIC_READ $iShare = 2+4; FILE_SHARE_READ + FILE_SHARE_WRITE $hFile = _WinAPI_CreateFile($sFileName, $iCreation, $iAccess, $iShare) If @error Or $hFile = Ptr(0) Then $str = "Could not open file "&$sfilename&@CRLF $str &= "Error: "&@error&@CRLF $str &= "Handle: "&$hFile MsgBox(0,"Error: _WinAPI_CreateFile",$str) Exit EndIf MsgBox(0,"Success: _WinAPI_CreateFile ","Handle: "&$hFile) _WinAPI_SetFilePointer($hFile,0); Beginning of file If @error Then MsgBox(0,"Error: _WinAPI_SetFilePointer",StringFormat("Could not move pointer. (Error %d)\n",@error)) EndIf Global $nBytesReceived $tBuffer = DllStructCreate("byte[512]") _WinAPI_ReadFile($hFile, DllStructGetPtr($tBuffer,1), 512, $nBytesReceived) If @error Then MsgBox(0,"Error: _WinAPI_ReadFile",StringFormat("Could not read file. (Error %d)\n",@error)) EndIf If $nBytesReceived<512 Then MsgBox(0,"Error: _WinAPI_ReadFile",StringFormat("Only %d bytes read.\n",$nBytesReceived)) Else MsgBox(0,"Success: _WinAPI_ReadFile",StringFormat("Read %d bytes.\n",$nBytesReceived)) EndIf _WinAPI_CloseHandle($hFile) $sText = Hex(DllStructGetData($tBuffer,1,1),2);Just the first byte MsgBox(0,"Result",$sText)

The download link for this UDF isn't working for me. Can someone attach the au3 directly? (...instead of zip files of hyperlinks to broken websites)

I'm running Windows 7. I have an autorun.inf file on a removable drive that looks like this: [autorun] label=My Drive Label When I plug in that USB drive and open Windows Explorer, I see that drive properly labeled. It says "My Drive Label (G:)" next to the drive icon. However, I can't figure out how to read that label (without reading the ini file, of course). If I use DriveGetLabel("G:"), it returns the string that is stored when you right-click the drive and select properties and type in a label. I can't figure out how to make it return the label that is displayed in Windows Explorer. Any ideas?

@water: I like your idea of a workaround (for those that don't want to use the dll call method), but sometimes sleeping for several seconds isn't acceptable. I think better way of doing this would be to get @HOUR and @MIN and then @HOUR again and see if @HOUR changed. If so, get @MIN again. $hour = @HOUR $min = @MIN If ($hour <> @HOUR) Then $hour = @HOUR $min = @MIN EndIf @BrewManNM: You say the likelihood is very very small, but what is the probability of it happening? Say I'm using this to create an alarm clock. I'm checking the time in a small loop and when I reach a certain time, I set off the alarm. I don't want to wake up an hour early or an hour late. So say I'm sampling the time in a 20ms loop. That means that we will take a time measurement within 20ms of the clock ticking over at the critical moment. I have no idea how many instructions it takes to get the @HOUR or @MIN macros. Let's make something up and say there are 40 instructions between. If we have a 2 GHz processor, then I think the probability is somewhere in the range 40 instructions divided by (20ms * 2Ghz) = 1 in a million chance. Does that make sense? Of course, this is a very simplistic view with nothing else going on in the system. I don't know a lot about operating systems, but I think the scheduling of different processes and other operating system tasks might make it more likely that this problem happens. Also, I think it probably takes way more than 40 instructions to get the time in AutoIt, but I was trying to be conservative on the estimate.

Add these below the other includes: #include <WindowsConstants.au3> #include <GUIConstantsEx.au3> #Include <GuiComboBox.au3> #Include <GuiEdit.au3> Also, remove the line: Opt("colorMode", 0) ;- RGB Then I'm getting these errors: $prodata.Open("Provider=vfpoledb.1;Data Source=T:ERPProdata.dbc") $prodata.Open("Provider=vfpoledb.1;Data Source=T:ERPProdata.dbc")^ ERROR I don't have a T: drive on my computer, so you'll have to report from there...

Haha. You're right. I didn't check the source code. Here you go... Based on: http://msdn.microsoft.com/en-us/library/windows/desktop/ms724338%28v=vs.85%29.aspx MsgBox(0,"Time",_GetLocalTime()) Func _GetLocalTime() Local $tSystemTime = DllStructCreate("WORD wYear;WORD wMonth;WORD wDayOfWeek;WORD wDay;WORD wHour;WORD wMin;WORD wSecond;WORD wMilliseconds") DllCall('kernel32.dll', 'none', 'GetLocalTime','ptr', DllStructGetPtr($tSystemTime)) If (@error) Then Return SetError(1, 0, 0) EndIf $hour = DllStructGetData($tSystemTime,"wHour") $min = DllStructGetData($tSystemTime,"wMin") $sec = DllStructGetData($tSystemTime,"wSecond") $time = $hour+$min/60+$sec/3600 Return $time EndFunc

Okay, thanks. I guess the safer thing to do is pull a single time "object" (for example _NowTime) and then calculate the $hours+$min/60 from that.

I asked a somewhat related question, and ended up solving it with the help of monoscout999: I think perhaps you can modify the _GDIPlus_BitmapCreateFromScan0() function to create the base image that you want (see it at the bottom of monoscout999's code).

Is there a chance of obtaining the wrong time by using time macros? For example, say I read the time like this: $time = @HOUR+(@MIN/60) Suppose the current time is approximately 1:59am, but the clock is in the process of ticking over to 2am. The @HOUR macro returns 1, but then the clock ticks over and the @MIN macro returns 0. So that gives us a time of 1am instead of ~2am (1 hour too early). Alternatively, if the @MIN macro is read first, it could return 59. Then as the clock ticks over the @HOUR macro reads 2. So that gives us 2:59am instead of ~2am (1 hour too late). Is there any way to read the two macros at the same time?

That's kinda what I understood. I think the answer is to place the top left point of the Graphic Control in the right spot to make the bottom left point end up where you want, which is what my code (in earlier post) illustrates. If you want to change the coordinate system of the graphic to more of a "math" type coordinate system (+x to the right, and +y is up) then I think you'll need to do a little arithmetic on all of your "GUICtrlSetGraphic" function calls (or create a wrapper that modifies the arguments before passing them to the real GUICtrlSetGraphic function).

I'm not sure that I entirely understand your question, but I think you're asking how to place a Graphic control relative to some point (...call it X0,Y0). As I understand it, the width and height of your graphic control are predefined, and you want to place that rectangle above or below a certain point. If this is correct, then the code below might help. Else, please clarify your question... I didn't know that rectangles had a "direction." #include <GUIConstantsEx.au3> #include <StaticConstants.au3> #include <WindowsConstants.au3> $Form1 = GUICreate("Up/Down", 400, 400) $X0 = 200 $Y0 = 200 $WIDTH = 10 $HEIGHT = 100 $GraphicDOWN = GUICtrlCreateGraphic($X0, $Y0, $WIDTH, $HEIGHT, $SS_BLACKFRAME) GUICtrlSetBkColor(-1,0x99ffff) $GraphicUP = GUICtrlCreateGraphic($X0, $Y0-$HEIGHT, $WIDTH, $HEIGHT, $SS_BLACKFRAME) GUICtrlSetBkColor(-1,0xffff99) GUISetState(@SW_SHOW) While 1 $nMsg = GUIGetMsg() Switch $nMsg Case $GUI_EVENT_CLOSE Exit EndSwitch WEnd