Mat

There is no way to have bit fields in AutoIt. Instead you'll have to use bitwise operators to extract required bits. It's not too tricky to do, but unfortunately it means you can't have the nice syntax we have use for structs at the moment.
For everyone else, the struct in the first post is actually only 1 UINT long, and the two fields are just single bits. That's a very different structure to what you have posted UEZ.

I did it for hotkeys here: '?do=embed' frameborder='0' data-embedContent>>
Maybe you can get some ideas looking at the source code for that.

On windows vista and above (which I think with the deprecation of windows XP it's now reasonable to assume unless you are still writing for a business), there is a TVN_ITEMCHANGED message.
The constants and structure required for this are not currently in the standard AutoIt libraries. I'll commit them when I get svn sorted out again, so the code below will break (re-declaration of constants) in the next beta.
#include <GUIConstantsEx.au3> #include <GuiTreeView.au3> #include <WindowsConstants.au3> Global $hTreeView Global Const $TVN_ITEMCHANGINGA = $TVN_FIRST - 16 Global Const $TVN_ITEMCHANGINGW = $TVN_FIRST - 17 Global Const $TVN_ITEMCHANGEDA = $TVN_FIRST - 18 Global Const $TVN_ITEMCHANGEDW = $TVN_FIRST - 19 Global Const $tagNMTVITEMCHANGE = $tagNMHDR & ";UINT uChanged; HANDLE hItem; UINT uStateNew; UINT uStateOld; LPARAM lParam;" Example() Func Example() Local $GUI, $hItem Local $iStyle = BitOR($TVS_EDITLABELS, $TVS_HASBUTTONS, $TVS_HASLINES, $TVS_LINESATROOT, $TVS_DISABLEDRAGDROP, $TVS_SHOWSELALWAYS, $TVS_CHECKBOXES) $GUI = GUICreate("(UDF Created) TreeView Create", 400, 300) $hTreeView = _GUICtrlTreeView_Create($GUI, 2, 2, 396, 268, $iStyle, $WS_EX_CLIENTEDGE) GUISetState(@SW_SHOW) GUIRegisterMsg($WM_NOTIFY, "WM_NOTIFY") _GUICtrlTreeView_BeginUpdate($hTreeView) For $x = 1 To 10 $hItem = _GUICtrlTreeView_Add($hTreeView, 0, StringFormat("[%02d] New Item", $x)) For $y = 1 To Random(2, 10, 1) _GUICtrlTreeView_AddChild($hTreeView, $hItem, StringFormat("[%02d] New Child", $y)) Next Next _GUICtrlTreeView_EndUpdate($hTreeView) ; Loop until the user exits. Do Until GUIGetMsg() = $GUI_EVENT_CLOSE GUIDelete() EndFunc ;==>Example Func WM_NOTIFY($hWnd, $iMsg, $iwParam, $ilParam) #forceref $hWnd, $iMsg, $iwParam Local $hWndFrom, $iIDFrom, $iCode, $tNMHDR, $hWndTreeview $hWndTreeview = $hTreeView If Not IsHWnd($hTreeView) Then $hWndTreeview = GUICtrlGetHandle($hTreeView) $tNMHDR = DllStructCreate($tagNMHDR, $ilParam) $hWndFrom = HWnd(DllStructGetData($tNMHDR, "hWndFrom")) $iIDFrom = DllStructGetData($tNMHDR, "IDFrom") $iCode = DllStructGetData($tNMHDR, "Code") Switch $hWndFrom Case $hWndTreeview Switch $iCode Case $TVN_ITEMCHANGEDW, $TVN_ITEMCHANGEDA $tNMTVIC = DllStructCreate($tagNMTVITEMCHANGE, $ilParam) ConsoleWrite(StringFormat("Item %i Changed, checked=%i\n", DllStructGetData($tNMTVIC, "hItem"), _GUICtrlTreeView_GetChecked($hWndFrom, DllStructGetData($tNMTVIC, "hItem")))) EndSwitch EndSwitch Return $GUI_RUNDEFMSG EndFunc ;==>WM_NOTIFY Mat

Works here with multiple files. 
Here's a zip of the exact files I've just tested with.
Does the firefox developer console show any errors?
Schdlr.zip

It's never actually documented what the return type is. It could change in the next release to something completely different, so any code you write that uses the return value for anything other than TimerDiff could be broken and it wouldn't even be mentioned in the changelog.
That's why Valik said to treat it as a handle: something which only has meaning internally.

Ok, you may not think it but you actually want to google "compiler construction" and get reading. Doesn't sound relevant but a lot of thought has gone into exactly what you are trying to do, and there are a lot of ways to do it. It's something I've been interested in for a long time.
I won't go into much detail because there are a lot of really good resources out there, only thing I'll say is that AutoIt is not a particularly good language for this, it's possible but you won't be able to do it that cleanly. Just to see how messy it would be I wrote a couple of very quick scripts for a lexer and parser. You could definitely do them better than that, but compare it to just how simple the same parser is written in another language, like C# or C++. ASTs are very well suited for use in OOP, you can have a generic branch or leaf class that has a method Evaluate or Simplify or whatever you want to do on the tree, and then all the different types of nodes can override that method. C# in particular was very easy to code this in.
All the examples above use a Top Down Operator Precedence Parser, which is a sortof recursive descent parser from a paper by a guy called Pratt. I love it, particularly for maths expressions (which is what I do mostly) it is very simple to implement initially, and then very easy to incrementally extend (something that is very important for big projects and testing). Again it lends itself very well to OOP rather than procedural programming.
Good luck. You've chosen a very interesting topic to look into, where you will learn a lot of techniques that will make you a better programmer, and a couple of bits of theory you will use elsewhere. Two years ago on one of my first paid jobs writing control software the guy I was working with couldn't understand why I knew all about finite state machines for example.
Do the research, if you need any specific help then send me a pm. I'm doing 60+ hours a week at university at the moment so I can't offer you much time, but I know from experience that a human can adapt their teaching to be more specific to an encountered problem, as opposed to a book which if you don't understand won't change how it explains something.
Speaking of books, the dragon book is what I read initially. It covered everything, including a lot of stuff I haven't really looked into like tools to do most of the stuff for you. It was definitely well worth getting, and is still sitting on my shelf next to some of the more chunky reference books now.

Make another file extension called .a3x64 or something, that is associated with the 64 bit interpreter.

So you want something like: "[^-,d.]". There I am matching anything that is NOT - or , or 0-9 or .

Hi BZC,
 
It seems you missed the Forum Rules on the way in.
 
In particular the following excerpt:
 

This does work though:
Local $a = [] Edit: Though UBound($a) returns 1 for that. What firefox suggested (Local $a[0]) works.

Here's a little trick to remove the entry from the taskbar without getting it to flash.
#include <GUIConstantsEx.au3> #include <WinAPISys.au3> #include <WindowsConstants.au3> #NoTrayIcon $hGUI = GUICreate("Form 1", 300, 200, -1, -1, BitOR($WS_CAPTION, $WS_SYSMENU), $WS_EX_DLGMODALFRAME, WinGetHandle(AutoItWinGetTitle())) $hIcon = _WinAPI_GetClassLongEx($hGUI, $GCL_HICON) _WinAPI_DestroyIcon($hIcon) _WinAPI_SetClassLongEx($hGUI, $GCL_HICON, 0) _WinAPI_SetClassLongEx($hGUI, $GCL_HICONSM, 0) GUISetState() Do Until GUIGetMsg() = $GUI_EVENT_CLOSE

Functions are not first class objects, as they cannot be created at runtime (yet). This is the first step towards possibly implementing that in the future. The correct term would be second class, in a similar way to C's function pointers.
A very common design pattern in other languages is a callback system like so: 
Local $a = [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] _EnumArray($a, MyCallback) Func MyCallback($v) ConsoleWrite($v & @LF) Return True EndFunc ;==>MyCallback ; Calls $Callback for each element in the array. ; If the callback returns FALSE then enumeration is stopped. ; Returns TRUE if the callback returned TRUE for all elements. Func _EnumArray($a, $Callback) For $i = 0 To UBound($a) - 1 If Not $Callback($a[$i]) Then Return False Next Return True EndFunc ;==>_EnumArray This is actually how the Enum* winapi functions work (though autoit handles this for you in WinAPI.au3 to return an array).
This functionality was available previously with Call() and passing string function names. Advantages of this system are:
AutoIt can check the functions for you, and fails with the correct error message if these are incorrect (e.g. incorrect number of parameters). AutoIt will also report an undeclared function name when you pass it to the function, rather than when you try and call it which could be somewhere further down the line making it difficult to trace the real problem. Works with obfuscator even if you use a variable rather than string literal. This is doing it properly. The main advantage you will see in every day use is that functions like HotkeySet can now take a function name as the second argument, rather than a string. This will report errors correctly as per point 2 above, though it appears that is not working correctly at the moment. I will report the bug now (assuming it is a bug as it means typos in keywords won't be reported as errors).
If I'm honest, the main reason I like this change is the last point above: This is doing it properly and using string function names was not a good design choice in the first place (though was probably a lot easier to implement).

PhoenixXL, I think the OP wants to be able to use the autoit info tool to detect the details of the button, but can't because of the group control.
There are a couple of options:
1: Hide the group. Just run this code before using the autoit info tool:
ControlHide("Autoit", "", "Button3") 2: Get a more powerful info tool. Spy++ allows you to see window hierarchies, which would make this very easy to do. Unfortunately Spy++ is a more advanced tool and is not quite as easy to do.
3: Do it manually. This is very complicated and probably not necessary, but look at _WinAPI_EnumChildWindows if you want to get the handles to all the children of a window.

Easy, 99.9% of the code is the same. Change the edit to a rich edit, change anything using GUICtrlGetHandle($Edit1) to just use the handle, change the message handler to use WM_RBUTTONUP because richedits don't send WM_CONTEXTMENU messages I seem to remember. Because you change the message you can't use $wParam like you are above, you probably want $hWnd instead.
Give this a try:
#include <GuiConstantsEx.au3> #include <WindowsConstants.au3> #include <EditConstants.au3> #include <GuiMenu.au3> #include <Constants.au3> #include <WinAPI.au3> #include <GUIRichEdit.au3> Global Enum $idOpen = 1000, $idSave, $idInfo $hGUI = GUICreate("Test", 300, 200) $Edit1 = _GUICtrlRichEdit_Create($hGUI, "", 10, 10, 280, 150, BitOR($WS_HSCROLL, $WS_VSCROLL, $ES_MULTILINE)) $hMenu = _GUICtrlMenu_CreatePopup() _GUICtrlMenu_AddMenuItem($hMenu, "Open", $idOpen) _GUICtrlMenu_AddMenuItem($hMenu, "Save", $idSave) _GUICtrlMenu_AddMenuItem($hMenu, "Info", $idInfo) GUISetState() $wProcHandle = DllCallbackRegister("_WindowProc", "ptr", "hwnd;uint;wparam;lparam") $wProcOld = _WinAPI_SetWindowLong($Edit1, $GWL_WNDPROC, DllCallbackGetPtr($wProcHandle)) While 1 $Msg = GUIGetMsg() Switch $Msg Case $GUI_EVENT_CLOSE ExitLoop EndSwitch WEnd GUIDelete($hGUI) DllCallbackFree($wProcHandle) Func _WindowProc($hWnd, $Msg, $wParam, $lParam) Switch $hWnd Case $Edit1 Switch $Msg Case $WM_RBUTTONUP _GUICtrlMenu_TrackPopupMenu($hMenu, $hWnd) Return 0 Case $WM_COMMAND Switch $wParam Case $idOpen ConsoleWrite("-> Open" & @LF) Case $idSave ConsoleWrite("-> Save" & @LF) Case $idInfo ConsoleWrite("-> Info" & @LF) EndSwitch EndSwitch EndSwitch Local $aRet = DllCall("user32.dll", "int", "CallWindowProc", "ptr", $wProcOld, _ "hwnd", $hWnd, "uint", $Msg, "wparam", $wParam, "lparam", $lParam) Return $aRet[0] EndFunc ;==>_WindowProc

http://xkcd.com/1171/
I've done stuff like this before for constants... Something like:
#include <Array.au3> Global Const $CONST_INT = 100 ; Good Global Const $CONST_HEX = 0xFFFFFF ; Good Global Const $CONST_FUNC = BitOR($CONST_INT, $CONST_HEX) ; Bad Global Const $CONST_UDF_WITH_HEXCHRS = AFC() ; Bad Global Const $CONST_NUMBER_NEG = -100 ; Good Global Const $CONST_MACRO = @ScriptDir ; Good Global Const $CONST_BOOL = True ; Good Global Const $CONST_NUMBER_DEC = 123.456 ; Good Global Const $CONST_NUMBER_SCI = 123e456 ; Good Global Const $CONST_NUMBER_DECSCI = 123.456e789 ; Good Local $sData = FileRead(@ScriptFullPath) Local $aSRE = StringRegExp($sData, '(?i)\$(\w+)\s*=\s*(0x[A-f]+|\-?\d+(?:\.\d+)?(?:e[\+-]?\d+)?|true|false|[\@\$]\w+)', 3) _ArrayDisplay($aSRE) Func AFC() Return True EndFunc ;==>AFC

Ok, so now I know what you wanted.

That's got nothing to do with inheritance, and you were confusing matters by talking about them as parent and child. If you'd stepped back one level and looked at the problem of "One class needs to access all the members of another class" then it really is much simpler.

In this case, try using it without the reference. You'll notice that even though the mother went and got her name changed, the son still calls her by her old name. That can create tension in a family, and some people who only knew the mother after she had her name changed may not know who the son is talking about.

More accurately the C++11 standard includes a regex library.

Have you looked at sregex_iterator?? Should mean only one call and then a for loop, but I have never actually used that library.