Custom Query
Results (118 - 120 of 3838)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #3071 | Completed | 4th example in Random() can be removed | guinness | guinness |
| Description |
As now the value will be returned without @error being set |
|||
| #991 | No Bug | 64 bit Rgistry Bug with New Scite and Autoit Mismatch | Jos | anonymous |
| Description |
This happens in the May 21 build of Scite When trying to access 32 bit apps This Registry information works when running inside of Scite but not once compiled by autoit HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall This registry information works when compiled with Autoit but not running inside of Scite HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall |
|||
| #1886 | Rejected | 64 or 128-bit numbers | anonymous | |
| Description |
I would like to see 128-bit numbers handled in AutoIt3. 128-bit numbers would be useful as a structure container for GUIDs. you could map out a $tagGUID onto a single 128-bit number and then simply use it, I would hope. 64-bit numbers are useful because the filesystem of windows uses 64-bit addressing. AND, if you request disk space from windows using GetDiskFreeSpaceEx() (for WinNT systems with kernel32.dll) or its fallback GetDiskFreeSpace() (for win9x/me systems), the former uses PULARGEINTEGER (ULARGEINTEGER) which is a structure that can be addressed using .QuadPart as a 64-bit unsigned integer. 64-bit integers are useful because of their sheer size/range. you can do PLENTY more with 64-bit numbers. make better calculators, etc. 128-bit would be even better. |
|||
