Latest Beta

monoceres · November 9, 2009

Just to clarify, static will not be in the next stable, correct?

Valik · November 9, 2009

Correct. You won't see Static again until next year.

MvGulik · November 10, 2009

Any change #65 'Au3Check gives wrong error with Const ByRef params' will make it into the next final?

Valik · November 10, 2009

No.

Anteaus · November 13, 2009

- Added #837: FileFindNextFile() set @extended if a directory is returned.
Brilliant! Eliminates the need for calling FileGetAttrib when searching for files.

Just a suggestion for the team, as it stands the @extended flag treats junctions as directories. It might be better if it either treated junctions as NOT directories, or else set a different @extended value for junctions. That would make things a lot easier for Vista/7 users faced with those damn cyclic links inside profiles.

As things stand the only sure way to avoid endless loops in profile copy/backup ops is to perform a DLL call for each directory.

Valik · November 13, 2009

I think that is well beyond the scope of what FileFindNextFile() should do.

andygo · November 13, 2009

hello, just downloaded the beta 3.3.1.5

if i try to download a file with inetget directly to d:\ the autoit crashes:

!>00:09:01 AutoIT3.exe ended.rc:-1073741571

if i choose a subfolder, everything is fine.

Problemsignatur:
  Problemereignisname:  APPCRASH
  Anwendungsname:   dvbs549.01beta.exe
  Anwendungsversion:    3.3.1.5
  Anwendungszeitstempel:    4af35031
  Fehlermodulname:  ntdll.dll
  Fehlermodulversion:   6.1.7600.16385
  Fehlermodulzeitstempel:   4a5bdb3b
  Ausnahmecode: c00000fd
  Ausnahmeoffset:   0002dece
  Betriebsystemversion: 6.1.7600.2.0.0.256.1
  Gebietsschema-ID: 1031
  Zusatzinformation 1:  cedc
  Zusatzinformation 2:  cedcabbd28669fd1230baace347c517c
  Zusatzinformation 3:  3b57
  Zusatzinformation 4:  3b5764752c946160ec172e9bb3b8b707

Edited November 14, 2009 by andygo

Anteaus · November 15, 2009

I think that is well beyond the scope of what FileFindNextFile() should do.

I agree, FileFindNextFile() in a scripting context should be a straightforward way to parse a directory. The issue is that if it parses into junctions as well as ordinary folders then from this point on, things cease to be simple.

As far as the default Vista/7 junctions are concerned there is no point in parsing them, and attempting to do so may lead to trouble.

The only case where someone might want their script to parse through junctions is if they've created some of their own, perhaps to other partitions. In my experience (do others agree?) this is a very rare situation, though.

Therefore I suggest that the default behaviour should be to NOT parse into junctions -or that it should be possible to identify from @extended when this is about to happen. Whichever is easier.

If it's not practical then I take your point, however I think it would be a very worthwhile improvement.

Valik · November 15, 2009

The only case where someone might want their script to parse through junctions is if they've created some of their own, perhaps to other partitions. In my experience (do others agree?) this is a very rare situation, though.

All my Windows XP systems have cross-volume junctions. :: shrugs ::

Therefore I suggest that the default behaviour should be to NOT parse into junctions -or that it should be possible to identify from @extended when this is about to happen. Whichever is easier.

It's not about ease, it's about doing what's sensible. You're suggesting we add overhead to every invocation to test for a rare scenario that will affect less than 1% of all users.

Jon · November 15, 2009

To be fair, Vista and later have a junction within the user profile that turns into a cyclic spiral when you try and keep going down a level. So don't be too quick to write off working with junctions.

And it's something like local appdata and not something massively obscure ;(

Not saying it's needed in the command in this topic, but it's quite a nasty problem when it bites and it's not expected.

Michel Claveau · November 17, 2009

Hi!

Vista and later have a junction

Junctions exists since W2K (but more used with Vista & 7)

Valik · November 17, 2009

Hi!
Junctions exists since W2K (but more used with Vista & 7)

We know. Jon's point is that Vista and later have a junction in the profile.

Valik · November 22, 2009

AutoIt v3.3.1.6 (Beta) Released:

AutoIt:
- Added: DllStructSetData() and DllStructGetData() index parameter now supports the Default keyword.
- Added #1270: GuiSetIcon() now finds suitable large and small icons.
- Fixed #1285: Reverted revision 5025 and all it's bad changes to the way numbers are handled.
- Fixed #1288: Documented how DllStructSetData() and DllStructGetData() work with arrays when omitting the index parameter.
- Fixed #1300: DLLs could unload when calling DllCall() with an invalid function.
- Fixed #1295: Unicode to ANSI conversion was crashing in certain situations.
- Fixed #1294: Fixed AutoIt deadlock when using the following functions with hanged windows: WinGetTitle, WinSetTitle, WinGetText, WinFlash, WinSetOnTop
- Fixed #975: Backgrounds of controls on tabs should be less likely to corrupt.
UDFs:
- Fixed #1287: _Debug functions were blocking input.
- Fixed #1276: _TicksToTime() incorrectly rounded seconds up.
- Fixed #1277: Resource clean-up in example script for _GDIPlus_ImageGetGraphicsContext.
- Fixed #1304: _GDIPlus_BitmapLockBits() now correctly takes a Width and Height parameter instead of a Right and Bottom.
- Fixed #1290: Invalid Left coordinate when using _GUICtrlTreeView_DisplayRectEx().
- Fixed #1296: _GUICtrlTreeView_ClickItem() could click outside the control's parent window.
Aut2Exe:
- Fixed #1283: Added new option /x86 to force a 32-bit build and re-added /unicode which also forces a 32-bit build.
Au3Check:
- Fixed #1299: Using single quotes in #include now works again.

The following changes are script breaking changes:

Some of the following features are deprecated. Deprecated features are no longer documented but continue to work. Deprecated features will be removed after version 3.3.2.0. It is strongly recommended that scripts relying on deprecated features be updated to work with the new behavior. Some features have already been removed and will be noted as such.
AutoIt:
ShellExecute() and ShellExecuteWait() no longer use the "open" verb by default. See the remarks section for those functions for more details.
The return value of InetGet() has changed. It is important to read and understand the changes because it is possible to leak resources if InetGet() is used incorrectly.
InetGet("abort"),@InetGetActive and @InetGetBytesRead are now deprecated. The following list shows the new functions used to access the old behavior:
InetGet("abort") - Calling the new InetClose() function with a handle returned from InetGet() will abort a download.
@InetGetActive - Calling the new InetGetInfo() function with no parameters returns a count of active downloads.
@InetGetBytesRead - Calling the new InetGetInfo() function with a handle returned from InetGet()will return the bytes read (and more) for a download.
The FtpBinaryMode option set with AutoItSetOption() has been removed. Now InetGet() takes a flag to specify the transfer mode.
The URLDownloadToFile() alias for InetGet() has been removed.
AdlibEnable() and AdlibDisable() are deprecated. See the new functions AdlibRegister() and AdlibUnRegister().
OnAutoItStart() is deprecated. See the new pre-processor statement #OnAutoItStartRegister.
OnAutoItExit() is deprecated. See the new functions OnAutoItExitRegister() and OnAutoItExitUnregister().
The AutoItSetOption() option OnExitFunc has been removed. See the new functions OnAutoItExitRegister() and OnAutoItExitUnregister().
GUICreate() with $WS_EX_MDICHILD has been fixed to be relative to client area as documented.
ProcessWait() now returns a PID instead of 1 on success.
WinWait(), WinWaitActive(), WinActivate(), WinActive() and WinMove() now return an HWND instead of 1 on succes.
The macro@YDAY now uses the range 001 - 366 instead of 1 - 366. This makes the macro more consistent with other languages (like C/C++) and more consistent with all other date related macros which return strings with leading 0s to pad the length.
RegEnumKey() and RegEnumVal() now return an empty string instead of an error message.
UDFs:
The last optional parameter for _StringBetween() has been removed.
_StringAddThousandsSep() has been removed. There are too many opinions on what this function should do and too many revisions of this function have been made.
_SQLite_SaveMode() has been renamed to _SQLite_SafeMode().

This release is not digitally signed.

Discuss the beta here.

Report issues here.

Download here.

Valik · November 22, 2009

Aut2Exe:
- Fixed #1283: Added new option /x86 to force a 32-bit build and re-added /unicode which also forces a 32-bit build.

i can't see this checkbox in the aut2exe gui ?

Where does it say a new checkbox was added to the UI? Please try to read and *understand* what the feature does before you make comments on it. Edited November 22, 2009 by Valik

Melba23 · November 22, 2009

Hi,

Small problem with MenuConstants.au3 in the new Beta 3.3.1.6 - 2 of the Const values have an additional 0.

; New MenuConstants values
Global Const $MIM_APPLYTOSUBMENUS   = 0x080000000  ; should read 0x80000000

Global Const $MNS_NOCHECK       = 0x080000000  ; should read 0x80000000

If you remove the 0 between the x and the 8 for these 2 Consts all runs smoothly again.

M23

Valik · November 22, 2009

andygo, I don't particularly appreciate it when you delete your post after I've already replied to it. For one thing it makes the thread look retarded because part of the conversation is missing which means everyone who read that before I added your quoted text to my post were left wondering what I was talking about.

wraithdu · November 23, 2009

Is BitShift() working correctly in 3.3.1.6?

ConsoleWrite(BitShift(0xFFFFFFFF, 16) & @CRLF)
ConsoleWrite(BitShift(-1, 16) & @CRLF)
ConsoleWrite(BitShift(4294967295, 16) & @CRLF)

These all produce -1 for me. But shouldn't it be 65535 (0x0000FFFF)?

Valik · November 23, 2009

Negative one is the correct result. When doing a right-shift on a signed integer the vacated bits are filled with whatever value is in the sign bit. In all of the above examples the sign bit is set so all the vacated bits are set, too.

wraithdu · November 23, 2009

Thanks for the clarification. Is there a way to force an unsigned BitShift operation? C++ defaults to an unsigned operation when a number is given as an argument:

0xffffffff >> 16 = 0x0000ffff

Dolemite50 · November 23, 2009

"Added #1270: GuiSetIcon() now finds suitable large and small icons."

Can somebody please elaborate on that?

Sign In

Latest Beta

Recommended Posts

monoceres

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

Melba23

Valik

Valik

Posted Images

Valik

MvGulik

Valik

Anteaus

Valik

andygo

Anteaus

Valik

Jon

Michel Claveau

Valik

Valik

Valik

Melba23

Valik

wraithdu

Valik

wraithdu

Dolemite50

Recently Browsing 0 members

Browse

AutoIt Resources

Release

Beta