Latest Beta

[MadBoy]

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

3.2.3.11 (28th April 2007) (Beta)

- Fixed: Binary() crashed when passed an array.

I think it will be time for a full release soon - the unicode version has been more stable than I expected considering the amount of changes.

Seems like you've got a lot of free time latly Good! Thanks for constant updates!

[GEOSoft]

Seems like you've got a lot of free time latly Good! Thanks for constant updates!

Now that he works for Microsoft he should have lot's of time.

[MadBoy]

Now that he works for Microsoft he should have lot's of time.

Does he?! Realy?!

[Jon]

3.2.3.12 (29th April 2007) (Beta)

- Changed: Removed restrictions on the maximum number of #include directives.

- Changed: Removed restrictions on the maximum number of DllOpen() handles.

- Changed: Removed restrictions on the maximum number of open files.

- Changed: Removed restrictions on the maximum number of hotkeys.

Also, a fairly extensive rewrite of the gui event queue, so check that your GUIs are OK.

[therks]

Wow, awesome, I was starting to worry about the hotkey one, as one of the programs I made/use is about to hit it's limit (what can I say, I don't like the mouse ). I always thought those file restrictions were Windows based (ie: Windows wouldn't let AutoIt have more than X open files), and I didn't even know about the #include limitation.

Will definitely have to test this one out.

*Edit: Removed quote. It's pretty obvious which post I'm referring to.

Edited April 30, 2007 by Saunders

[Jon]

Wow, awesome, I was starting to worry about the hotkey one, as one of the programs I made/use is about to hit it's limit (what can I say, I don't like the mouse ). I always thought those file restrictions were Windows based (ie: Windows wouldn't let AutoIt have more than X open files), and I didn't even know about the #include limitation.

Will definitely have to test this one out.

*Edit: Removed quote. It's pretty obvious which post I'm referring to.

They were all just lazy programming (by me) more than anything. It's much easier to do

char m_hotkeys[64];

than it is to write structures that can shrink and grow to any size. We're very lazy.

[GEOSoft]

They were all just lazy programming (by me) more than anything. It's much easier to do

char m_hotkeys[64];

than it is to write structures that can shrink and grow to any size. We're very lazy.

Now is it possible to remove the maximum number of elements in an array?

Just wondering.

[Jon]

Now is it possible to remove the maximum number of elements in an array?

Just wondering.

Oh, come on, it's 16 MILLION! Windows falls over way before you get near that anyway because it runs out of memory

[GEOSoft]

Oh, come on, it's 16 MILLION! Windows falls over way before you get near that anyway because it runs out of memory

Windows starts falling over when I start my computer and that's with 2G of RAM installed.

Actually if I remember correctly it was te limit on tray items that did give me a problem in one script a while back where the tray items were created dynamicly. No matter I don't use that script anymore. I replaced it with a treeview and dynamic treeview items in PX.

[Jon]

Advance warning: I'm removing the "Struct" keyword from the next betas and release. I'd "missed" its addition and only just spotted it and I don't quite agree with it's implementation as-is.

[PaulIA]

Advance warning: I'm removing the "Struct" keyword from the next betas and release. I'd "missed" its addition and only just spotted it and I don't quite agree with it's implementation as-is.

Are you removing the changes to DllStruct as well? Specifically, the ability to do:

$tBuffer = DllStructCreate("char Text[4096]")
$tBuffer.Text = "Hello world"

Because, I've got a loaded revolver pointed at my head if you do.

[Jon]

Are you removing the changes to DllStruct as well? Specifically, the ability to do:

$tBuffer = DllStructCreate("char Text[4096]")
$tBuffer.Text = "Hello world"

Because, I've got a loaded revolver pointed at my head if you do.

Hmm, I don't find that as "wrong", but it's part of the same codebase so for the moment... *BOOM*.

[PaulIA]

Hmm, I don't find that as "wrong", but it's part of the same codebase so for the moment... *BOOM*.

Before I rewrite a thousand API calls to revert back to using positional notation for DllStruct, should I wait a few beta versions to see what shakes out or are you fairly set on not using the current notation?

[GaryFrost]

Hmm, I don't find that as "wrong", but it's part of the same codebase so for the moment... *BOOM*.

All I can say is "ouch"

Had just recently changed over most of the includes that I support that are in the beta.

[Jon]

Ooo Jon is unpopular now Sorry!

I want to do a full release soon so don't want anything to be included that I'm not happy with. I think the . notation for accessing a previously created DllStruct is _somewhat_ acceptable. But the Struct keyword just really didn't feel right. I saw it in the changelog and assuming "oh cool, you can create a variant with named parts". I looked at the help file and saw that it was bound to DllStruct and was all "oh hell no". Having a _language_ keyword being completely bound to the operation of a single function isn't right IMNSHO.

My initial thinking after a few short hours is:

- Struct...EndStruct seems a decent enough addition but with normal AutoIt variants (not some random non-AutoIt datatypes).

- The . notation for accessing structs seems obvious enough. If Struct were implemented I'd go for that

- The . notation for accessing variables that have already been created with DllStruct. 50/50 on that.

The big worry - and something Valik pointed out in priv-devchat - is that without doubt people will use the Struct keyword together with the Dll specific types to create some hybrid datatypes that are vaguely documented and unsupported. They'll be used with other features in unsupported ways and then we get trapped when we try and change some behaviour that was undefined anyway. They'll definately be used outside of the scope of just being passed to DllCall.

[PaulIA]

Ooo Jon is unpopular now Sorry!

I want to do a full release soon so don't want anything to be included that I'm not happy with. I think the . notation for accessing a previously created DllStruct is _somewhat_ acceptable. But the Struct keyword just really didn't feel right. I saw it in the changelog and assuming "oh cool, you can create a variant with named parts". I looked at the help file and saw that it was bound to DllStruct and was all "oh hell no". Having a _language_ keyword being completely bound to the operation of a single function isn't right IMNSHO.

My initial thinking after a few short hours is:

- Struct...EndStruct seems a decent enough addition but with normal AutoIt variants (not some random non-AutoIt datatypes).

- The . notation for accessing structs seems obvious enough. If Struct were implemented I'd go for that

- The . notation for accessing variables that have already been created with DllStruct. 50/50 on that.

The big worry - and something Valik pointed out in priv-devchat - is that without doubt people will use the Struct keyword together with the Dll specific types to create some hybrid datatypes that are vaguely documented and unsupported. They'll be used with other features in unsupported ways and then we get trapped when we try and change some behaviour that was undefined anyway. They'll definately be used outside of the scope of just being passed to DllCall.

Just 2 cents from somebody whose been using the new DllStruct syntax for awhile:

I don't use Struct...EndStruct at all in Auto3Lib. If this is the problem, you could take these keywords out altogether as far as I'm concerned. I did not find these to be "real world" friendly, so I defined all of the structs that I use like:

Global Const $tagTBBUTTON = "int Bitmap;int Command;byte State;byte Style;short Reserved;int Param;int String"oÝ÷ Ù*-«péÈçi0AQ4Î6Ëk¹Ën­æ¥Z½ëhv¬jëh×6$tButton = DllStructCreate($tagTBBUTTON)
$tButton.Bitmap  = $iImage
$tButton.Command = $iID
$tButton.State   = $iStates
$tButton.Style   = $iStyles
$tButton.Param   = $iParam
$tButton.String  = $iString

I don't agree that the new DllStruct notatation leads to any dangers that aren't already present. I can do the exact same thing with the old DllStruct that I can with the new one. The new syntax IMO is just easier to code and understand. The new syntax does not introduce any new data types that weren't in the old syntax as far as I can tell. Maybe I'm just missing the obvious here.

[GaryFrost]

I did the same as PaulIA, didn't use the Struct keyword either.

Question is if this is completely removed will the release contain the current beta includes or the current release includes?

My changes only affected the latest betas.

Gary

[Jon]

I did the same as PaulIA, didn't use the Struct keyword either.

Question is if this is completely removed will the release contain the current beta includes or the current release includes?

My changes only affected the latest betas.

Gary

I wrote a massive reply to PaulIA about why I thought it was bad but IE crashed and I'm too tired to rewrite...so anyway. The basic gist was i'm undecided on the dot notation working with DllStructCreate'd variables. I had a look at the underlying implmentation JP(?) did and it was quite elegant and any changes to DllStructGet/Set are automatically reflected -which sways me a little.

The release would contain the current beta includes as it's built from the same source tree so they need reverted to use DllStructSet/Get for now (as that will work whatever the final decision is). I had a quick scan of the includes but couldn't see any dot notation, whereabouts is it used?

[GaryFrost]

I wrote a massive reply to PaulIA about why I thought it was bad but IE crashed and I'm too tired to rewrite...so anyway. The basic gist was i'm undecided on the dot notation working with DllStructCreate'd variables. I had a look at the underlying implmentation JP(?) did and it was quite elegant and any changes to DllStructGet/Set are automatically reflected -which sways me a little.

The release would contain the current beta includes as it's built from the same source tree so they need reverted to use DllStructSet/Get for now (as that will work whatever the final decision is). I had a quick scan of the includes but couldn't see any dot notation, whereabouts is it used?

GuiCombo.au3

GuiEdit.au3

GuiIPAddress.au3

GuiList.au3

GuiListView.au3

GuiMonthCal.au3

GuiStatusBar.au3

GuiTab.au3

GuiTreeView.au3

[GaryFrost]

Using WinMerge I'm working on rolling back to beta 3.2.3.6 plus bug fixes since then.

Should have it tonight or tomorrow.

Need to have it done before I leave to be on your side of the pond.

Gary