V3.0.102 Unstable Updated

[Jon]

Unstable updated:

Fixed problems with the mouse cursor staying "busy" on load and also fixed the GUISetCursor() function. The mouse cursor will stay as the one specified even if it is moved outside the GUI windows and back again.

(Note, it's not in the help file yet but the GUISetCursor() function uses the same IDs as MouseGetCursor() )

[Jon]

Updated:

3.0.102 (26th May, 2004) (Beta)

- Changed: Colors now default to the standard RGB format rather than the previous BGR format.

This affects PixelSearch, PixelGetColor, GuiCreateEx and GuiSetControlEx.

The "ColorMode" option has been added to allow old scripts to run with the old BGR mode, just

place this line at the top of your script to use the old method:

Opt("ColorMode", 1)

- Fixed: Mouse cursor problems and GUISetCursor()

I'll update the au3spy soon to give the RBG color, but the source is...er...missing so that might take a while

[Jon]

AutoIt Window Spy updated to show RGB and BGR colors.

[ezzetabi]

When we'll have a new STABLE ?

[Josbe]

Updated the unstable - fixed loads of memory leaks in the GUI (i think )

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

3.0.102 (24th May, 2004) (Beta)

- Updated: GUI code from JP's version 3.0.102.24 + Jon's fixes/changes

- Fixed: ToolTip() when the mouse is near the bottom of the screen

- Added: More command line params for Aut2Exe.exe: /nodecompile and /comp 0-4  (compression level, 4=best)

- Fixed: StringIsDigit()

- Fixed: Process... functions under NT4 unable to see certain processes (Cheers, AndrewL)

Thanks, David and Jon for the updates. (StringIsDigit)

Now, the BGR change, affects me.

Before, I thought that, the hex output was wrong in AutoIt.

Then, I saw others color's programs, and were displaying exactly like AutoIt's Hex output.

But now, the AutoIt's output is exactly like HTML's format.

For now, I think that I will use the "ColorMode" option for some scripts.

(I will adapt)

[Jon]

Now, the BGR change, affects me.

Before, I thought that, the hex output was wrong in AutoIt.

Then, I saw others color's programs, and were displaying exactly like AutoIt's Hex output.

What programs? I've never seen color expressed in hex as anything other than RGB. HTML, paintshop, photoshop, Amiga assembly language, etc..

[Jon]

When we'll have a new STABLE ?

When the GUI stuff is stable I guess (and the docs converted from Franglais ). I'm tweaking other stuff too, but it's pretty much the GUI holding things up.

[CyberSlug]

When the GUI stuff is stable I guess (and the docs converted from Franglais    ).  I'm tweaking other stuff too, but it's pretty much the GUI holding things up.

I've intended to work on that. I have misc notes that might be helpful in the docs.

[Josbe]

What programs?  I've never seen color expressed in hex as anything other than RGB. HTML, paintshop, photoshop,  Amiga assembly language, etc..

Ok, I know the HTML format, used in programs like Adope PSP, PaintShop, etc.

But, is possible that maybe is confused with this program that me been useful to capture colors (it's a mirror of my PixelFinder. haha)

I don't remember other one that it wanted to mention you.

[Jon]

Unstable updated.

JP has mentioned a few bugs too (in my reimplementation) but I've not got any details yet so just some general GUI fixes around control focus and mouse cursors.

When I've fixed the bugs JP has found then I'll look at improving the GuiMsg(0) mode and the message handling/queueing.

[Josbe]

@Jon: Do you think to publish a stable version soon?

(Only for curiosity)

[SlimShady]

@Jon: Do you think to publish a stable version soon? 

(Only for curiosity) 

When the Todo List is done...

Be patient.

[bcording]

I'll check in tomorrow then

[Josbe]

When the Todo List is done...

Be patient.

Of course, Slim.

I know the Todo list, but it's a curious question nothing more...(and also for GUI's documentation)

[Jon]

http://www.autoitscript.com/autoit3/files/unstable/autoit3/

Updated with the default button GUI stuff and other minor changes.

Things to note about the changes:

- The first control ID is now 3 to avoid conflict with system generated messages

- $GUI_DEFBUTTON state added for GuiSetControlEx()

Here is some example code to set the default button - notice that the default button is highlighted and triggered by ENTER even when focus is on the edit box

#include <GUIConstants.au3>

GUICreate("Extra Sessions",490,150,300,200);,0x80000000)
GUISetControl("button","B1",10,25,50,25)
GUISetControl("button","B2",70,25,50,25)
GUISetControl("button","B3",130,25,50,25)
GUISetControlEx(-1, $GUI_DEFBUTTON); Default button
GUISetControl("button","B4",190,25,50,25)
GUISetControl("button","B5",250,25,50,25)
GUISetControl("button","B6",310,25,50,25)
GUISetControlEx(-1, $GUI_FOCUS) ; Button with focus
GUISetControl("button","B7",370,25,50,25)
GUISetControl("button","B8",430,25,50,25)
GUISetControl("input","B9",230,65,200,50)
GUIWaitClose()
MsgBox("","",GuiRead(),2)

[SlimShady]

It's not possible to have a default button in each tab, right?

[Josbe]

http://www.autoitscript.com/autoit3/files/unstable/autoit3/

Broken link. I think that, it's an extra "3"

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

[CyberSlug]

Things to note about the changes:

- The first control ID is now 3 to avoid conflict with system generated messages

Minor point: This change affects the maximum number of controls you can create... It was 511; now it is 509. I suppose code sets the max index

GuiCreate("MyGUI")
$i = -1
Do
   $c = GUISetControl("button", "Button 1", 70, 30, 90, 70)
   $i = $i + 1
   If $c <> 0 Then ToolTip($c)
Until Not $c
MsgBox(4096,"Count",$i)

[CyberSlug]

I see that GUISetCursor in recent versions only affects the cursor when it is not over a control. (Cursor reverts to an arrow when over a control....)

However, I could really use the opposite behavior: cursor change when over controls and is a normal arrow otherwise.

Is this possible? Maybe a paramter could be added to GUISetControlEx (similar to the tooltip parameter)?

Edited June 6, 2004 by CyberSlug

[Jon]

Uunstable updated:

- GuiWaitClose return values changed

- Edit controls can notify when their contents are changed and then they lose focus

- Sleep() is no longer required when doing GuiMsg(0)

Dev stuff:

GuiMsg(0) and GuiMsg() use the same internal code now so they should work pretty much the same. And when using GuiMsg(0) if no messages are waiting (windows or GUI) then an automatic Sleep(10) is done for removing CPU load without sacrificing responsiveness.

Gui events are now queued so if you have say a couple of events in quick succession (edit notify followed by a button press for example) the autoit script will receive both messages in the order they were generated.

Edited June 6, 2004 by Jon