Hi.
I am unfortunately not good to learn from manuals, so i was looking for example code. But when we are at it, what is an oop?

Well i saw a few nice gui programs in autoit.

If it helps, I've dug around and there are various threads with examples using TTS [here], [here], [here], and [here].

The documentation on sound playing is [here]. A lot of this is fairly dated, so grain of salt and all that.

My story is almost the same, the difference only that I started with another language.
Autoit is good for autommating some tasks on your machine that would be hard to do it by hands and lets say write a quick - dirty tests for your real software, but other ways than that, I do not recommend it to learn. If you need something much powerfull and to be capable to write scripts with it, grab Python and yo will be fine.
If you still not convinced and decide otherwise, I shal say that GUI is slow, especially with NVDA, it's not cross platform as well (even if you think that will write software on Windows, but why to keep yourself guessing, it's better to take something that yo know for sure has great support and whatever).
You'll never be able to release something major as your creations to the public because of it's insecurity - high-compression of executables that antivirus software recognises as a malicious warme, and the other option - force your end-user to install Autoit interpretator is not acceptable either.
By staing on a topic, I can say that I wrote few scripts to bind my TTS (JAWS, NVDA and SAPI) to speak via jfw.JawsAPI, NVDAControllerClient32.dll and SAPI through obj_create if I remember them correctly. Few games by using bass.dll to balance / pan the sound and modivy the volume, etc. It has an access to TCP/IP, UDP socket connections and you can make some graphicks through the native Windows libraries, but all in all - pick another language.

It doesn't, you simply tell the struct which datatypes are stored within and it will simply reconstruct it and create the corresponding pointers if necessary. Why is it important how AutoIT3 handles its structs internally? It shouldn't bother you actually, such engines are ment to be blackboxed, means you know what to put into it and what you can expect to get out of it, but the internals shouldn't matter at all.
Best Regards.
Hijacker

@12, you can't. Pure and simple. Its closed source.
Also, calling functions from DLLs without C headers or language bindings is hard to get right. There is no type or parameter checking, no safety nets, no safety checks, no length validation, etc. You can call a function in a DLL that requires 10 parameters and only give it 6. Or you can give it none. Even in .NET it is difficult to do and I would highly discourage it unless you have no choice and you know what you are doing. There's a reason that this is the way it is -- your calling a DLL that may not be written in the language your programming in. The compiler and runtime have absolutely no idea how the function works nor do they have its code to look at. This is exactly when the saying "Anything to do with shared libraries is dangerous" rings true -- because it is. Even in Rust there is no "safe" way to do it -- you must use unsafe to make any DLL calls. BGT may require you to put the function signature in, but internally that's only so it can type-check your code. You can put an invalid signature in there too and it wouldn't be able to stop you. It would make the call and your only thing to do would be to hope to god that you wrote the signature right and you know the library in and out. You can look up functions in a DLL but you can't look up its signature.
The only way you could do that is if you had the debugging symbols, and since no library ships that unless its open source... good luck getting those.
Also, did I mention that calling functions from DLLs is messy as all hell, even when not using the win32 API? Even in Go -- which did its best to simplify the entire process -- its messy. Here's an example of me calling a Tolk function from its DLL (since there are no Tolk bindings in go):

import (
"golang.org/x/sys/windows"
"unsafe"
)

// loading code
var (
dll *windows.DLL
load *windows.Proc
unload *windows.Proc
hasSpeech *windows.Proc
hasBraille *windows.Proc
output *windows.Proc
speak *windows.Proc
braille *windows.Proc
isSpeaking *windows.Proc
silence *windows.Proc
)

func Load() {
dll = windows.MustLoadDLL("tolk.dll")
load = dll.MustFindProc("Tolk_Load")
unload = dll.MustFindProc("Tolk_Unload")
hasSpeech = dll.MustFindProc("Tolk_HasSpeech")
hasBraille = dll.MustFindProc("Tolk_HasBraille")
output = dll.MustFindProc("Tolk_Output")
speak = dll.MustFindProc("Tolk_Speak")
braille = dll.MustFindProc("Tolk_Braille")
isSpeaking = dll.MustFindProc("Tolk_IsSpeaking")
silence = dll.MustFindProc("Tolk_Silence")
load.Call()
}

func Unload() {
unload.Call()
dll.Release()
}

func Speak(text string, interrupt bool) {
str, err := windows.UTF16PtrFromString(text)
if err != nil {
panic(err)
}
speak.Call(uintptr(unsafe.Pointer(str)), uintptr(unsafe.Pointer(interrupt)))
}

And with return values:

// Same code context as above
func HasSpeech() bool {
r1, _, _ := hasSpeech.Call()
return *(*bool)(unsafe.Pointer(r1))
}

Can I say that this is correct code? No, I can't. I cannot guarantee that I am doing this properly. I know that the speak code is correct -- but that's only because I tested it, though with the interrupt variable thrown in there, that may have broken things. Here's how you might do that in C++ (calling the MessageBoxA function), raw win32 API:

#include <windows.h>

// We load user32.dll instead of taking advantage of the fact that windows.h already provides this for us
typedef int(*MsgBox)(HWND, LPCSTR, LPCSTR, UINT);

int main() {
// Load our library
HINSTANCE lib = LoadLibrary("user32.dll");
if (lib != NULL) {
MsgBox msgbox = (MsgBox)GetProcAddress(lib, "MessageBoxA");
if (msgbox != NULL) {
(msgbox)(NULL, "test", "test", 0);
}
FreeLibrary(lib);
}
}

Notice how here I have left out a lot of error checking. A fuller example can be found at https://docs.microsoft.com/en-us/window … ic-linking. In C# its a lot easier:

using System;
using System.Runtime.InteropServices;
// ...
[DllImport("user32.dll", CharSet = CharSet.Unicode)]
public static extern int MessageBox(IntPtr hWnd, String text, String caption, uint type);

But even then you need to correlate C++ types and C# types. And this doesn't take into account C++-based DLLs which could have classes (but more often than not have C interfaces).

@14, you could, but it would be way overcomplicated and not worth it. And disassembling it and finding the function signature? That's not exactly practical, now is it? That's what C headers, reference manuals and documentation are for. Disassembly is a drastic thing that will take quite a while to finish and should be a last resort thing.
That still doesn't help you in your "BGT remake" though. It just won't, either -- you will need to figure out a usable (please, no dictionaries...) approach to DLL calls.

@16, that's not going to work. You can't possibly handle every data type out there, and if you want this interface to be comfortable to use and not hackish then your going to need to return native types and allow the passing of native types. This is just another reason why I think this is a bad idea -- your attempting to overlay something that an operating system already provides you and only making it more complicated in the process.

@18, I don't know how AutoIt and BGT did it. As for Python... I honestly don't know. I haven't looked at the code to figure that out. What I do know is that when a DLL is loaded and you either use subscript notation or dotted notation (foo.bar() or foo["bar"]()) Python uses GetProcAddress or whatever the platform library calling interface uses to acquire the function and see if it exists. If Python does do argument checking and type checking then clearly I was wrong and just do not know how it would do that.

@20, I would need to look at the code. I have no doubt that its a complicated mess though.

@22, I thought so. Even in C++ you can only truly do type checking with classes with proper headers and good documentation. Really, the C++ side of things is really C; and with C, you have unreliable type casts. Its easy to mistype a paramter type and C will allow you to typecast to ti and then call it misproperly.