Latest Beta

[GEOSoft]

Question follows

From the help file >> IniReadSection()

Only the first 32767 chars are taken in account in an section due to Win9x compatibility.

Have these limits been removed yet?

[Valik]

Ini stuff shouldn't be touched unless it's a full rewrite to avoid the Windows API. All versions of Windows have a limit of some sort, it's just that XP is bigger, but XP is also not documented.

[GEOSoft]

Ini stuff shouldn't be touched unless it's a full rewrite to avoid the Windows API. All versions of Windows have a limit of some sort, it's just that XP is bigger, but XP is also not documented.

Thanks Valik. I was hoping that the character limit was higher than before.

[wraithdu]

I noticed in Beta 3.2.13.0 that the behavior of GuiCreate() with a parent specified has changed. In the latest production version, it creates a child GUI in the sense that it's always on top of the specified parent, but still it's own window. In the Beta, the child GUI is now really a child inside the parent GUI window. Was this an intended change, or should I submit it as a bug?

Sample code to show the difference -

#include <GUIConstantsEx.au3>
#include <WindowsConstants.au3>

$nGUI = GUICreate("Parent")
GUISetState()
$cGUI = GUICreate("Child", 100, 100, 10, 10, -1, $WS_EX_TOOLWINDOW, $nGUI)
GUISetState()

While 1
  $msg = GUIGetMsg()

  Select
    Case $msg = $GUI_EVENT_CLOSE
      ExitLoop
  EndSelect
WEnd

Exit

Edited June 10, 2008 by wraithdu

[Valik]

How about actually looking at the issue tracker *first* and seeing if there are already any similar bugs reported?

http://svn.autoitscript.com/trac/ticket/355

[wraithdu]

Sorry, I checked the Open tickets, not the closed. Didn't think anything would be reported and fixed already. My bad.

[Jon]

http://www.autoitscript.com/autoit3/files/beta/autoit

3.2.13.1 (10th June, 2008) (Beta)

Some more big speed improvements, especially with strings, and:

AutoIt:

- Added: New flag for StringSplit() to not return the count in element 0.

- Fixed #358: Install dir documentation cleaned up (thanks Zedna).

- Fixed #355: Child not visible beta regression. (Thanks Ultima)

- Fixed #366: AutoIt crash on bad syntax.

- Fixed #360: RunAs() under Windows 2000.

- Fixed #367: STDIO functions in compiled scripts work again.

- Removed #357: @AutoItUnicode macro.

UDFs:

- Added: _GUICtrlTab_ClickTab (Gary)

- Fixed #361, #362: _GUICtrlListView_InsertItem doc (Zedna)

- Removed: _StringSplit, no longer needed

- Added: _GUICtrlComboBoxEx_GetUnicode, _GUICtrlComboBoxEx_SetUnicode (Gary)

[GEOSoft]

Thanks Jon;

I really like this one,

- Added: New flag for StringSplit() to not return the count in element 0.

I wish it had always been that way but that's what evolution is all about.

[wraithdu]

Darn, wasn't fast enough. And this time I really did check the whole bugtracker.

_GDIPlus_Startup() returns the wrong boolean value when successful. GdiplusStartup() function returns 0 on success, so the last line of _GDIPlus_Startup() should be

Return $aResult[0] == 0

[Jon]

Thanks Jon;

I really like this one,

I wish it had always been that way but that's what evolution is all about.

To be fair, UBound() didn't exist at the time StringSplit() was written

[Valik]

Darn, wasn't fast enough. And this time I really did check the whole bugtracker.

_GDIPlus_Startup() returns the wrong boolean value when successful. GdiplusStartup() function returns 0 on success, so the last line of _GDIPlus_Startup() should be

Return $aResult[0] == 0

Then use the issue tracker, don't report it here.

[wraithdu]

Nag, nag...will do Just making sure I didn't mess up again.

Thanks everyone for the quick fixes and updates!

Edited June 11, 2008 by wraithdu

[GEOSoft]

Oooops! One more thing.

Has a 1 flag been added to StringRegExp() yet? I may have just missed it in the changes but I think it would be good to have. Just trying to keep functionality consistant.

[Jon]

Oooops! One more thing.

Has a 1 flag been added to StringRegExp() yet? I may have just missed it in the changes but I think it would be good to have. Just trying to keep functionality consistant.

No, I thought it was OK for a flag to enable the 0-based functionality we wanted, but a flag to enable the opposite seemed a little perverse.

[GEOSoft]

Thanks Jon;

I just noticed one of the changes that I'm a bit iffy about. What was the reason for changing the default Directory for

RunAs() and RunAsWait() to @SystemDir?

I'm not sure that this is a good move. If for example you are testing an app that creates files and something goes wrong, about the last place I would want stray files to show up would be in @SystemDir. I would much rather see them placed some place where they are easily found and removed.

[Jon]

Because of this: http://svn.autoitscript.com/trac/ticket/309

[GEOSoft]

Because of this: http://svn.autoitscript.com/trac/ticket/309

Thanks for the quick reply Jon.

I guess I can get started going through all my scripts and making sure that a working directory is specified. It probably should have been done in the first place instead of depending on the default anyway. I would have even prefered the root of the drive which as we know is also not a great place to put stray files but better than @SystemDir IMHO.

[Valik]

Yeah, you can blame this one on idiots, George. Since the introduction of RunAsSet() people have been saying "the function is bugged, it won't run" when all they have to do is specify a specific working directory the callee can access. We've already had 2 tickets on the issue since releasing 3.2.12.0. My suggestion was to make the working directory mandatory to make user's think about it, but Jon suggested using @SystemDir since it at least has read-only access for all users.

[GEOSoft]

Yeah, you can blame this one on idiots, George. Since the introduction of RunAsSet() people have been saying "the function is bugged, it won't run" when all they have to do is specify a specific working directory the callee can access. We've already had 2 tickets on the issue since releasing 3.2.12.0. My suggestion was to make the working directory mandatory to make user's think about it, but Jon suggested using @SystemDir since it at least has read-only access for all users.

I agree that, given the circumstances, a default working directory may not be such a good thing. On the other hand changing that could be another script breaker of rather large proportions. It's actually my own fault for not specifying a specific directory to begin with, but I'm sure a simple script will solve it in all of my existing scripts (RegExReplace coming up) because I only have a few RunAs*() calls. That may not hold true for everyone though.

EDIT: If I'm going to write a script to change these then I might as well have the same script check for any of the other functions that also use a default and change them too. Run(), RunWait() ShellExecute() &etc. I foresee where there is the posibility of this situation rearing its ugly head again at some point in the future and for the extra code it will take I might as well do the changes now.

Edited June 12, 2008 by GEOSoft

[Valik]

It can't be a major script breaker, RunAs() is new syntax already which was a script-breaking change so a further minor tweak to that can't be too significant over the initial change.

I kind of agree, I'll talk it over with Jon. I really think user's should think and choose their own directory in this case instead of letting AutoIt do it for them.