Leaderboard

Introduction Since the introduction of ObjCreateInterface, AutoIt is able to create native, real objects. However, this is quite difficult for non-experienced users. This UDF here enables a "classic" syntax for declaring classes and instantiating objects from them. Before you ask: No, it is not just another preprocessor that's "faking" OOP syntax - this is the real deal. While it assists users with a more familiar syntax, objects are created at runtime. Care has been put into this UDF and it is in the authors interest to fix all bugs remaining and implement features as long as the result works in the Stable release of AutoIt. Features Define an unlimited number of classes.Create unlimited instances of objects.Create arrays of objects.Mix and match different data types in arrays (one or more elements can be objects).Define custom constructors and destructors.Pass an unlimited number of arguments to the constructor (even to all objects in one array at the same time).Automatic garbage collection.Compatible with Object-enabled AutoIt keywords (With etc.), optional parentheses on parameterless functions.Fully AU3Check enabled.IntelliSense catches class-names for auto-completion.Automatically generates a compilable version of the script.Non-instantated classes get optimzed away.Create C-style macros.Download Read the Tutorials - Download - Download (forum mirror) Please use the github issue tracker to report bugs or request features. Please read the tutorial before asking a question. Thanks!

In the moment there are two UDF's for serial communication: >Serial Port / COM Port UDF (needs comMG.dll) >Serial Communication using kernel32.dll The first UDF is very popular, but it has the disadvantage, that an unknown DLL needs to be used. The second UDF use the Windows API, but it has much less features. So, I decided to create an another UDF for my requirements. You can find the result here: http://www.autoitscript.com/wiki/CommAPI It is a further development of the second UDF and has (almost) all functions of the first UDF. Feel free to fix any existing bugs and to extend it with additional functions.

Danyfirex that won't work, you can't assign anything to a macro. You can use IniReadSection to get all of the usernames in the INI file in that section and loop through them to look for the @Username. Global $aUsers = IniReadSection("myinifile.ini", "Users") For $Loop = 1 To $aUsers[0][0] If @UserName = $aUsers[$Loop][1] Then ;do something here EndIf Next

simply this. @UserName=IniRead("Yourinifile.ini","USERS","USER01","")Saludos

Re: First question: Not when the actual script uses the console. It needs to read the running std stream to work correctly. If it would exit immediately, other users would only be able see the console output when the generated script exits (i.e. not real-time). But, Re: Sec. q.: Yes, didn't think about that. I'll add an option for that. (Or rather auto-detect if the user's script even uses the console at all).

ooh, looks interesting. I look forward ti trying it. Thanks.

You can use WinList() to see all current windows with title and handle. Like jguinch already stated, the handle would be an unique identifier and can be used with WinSetTitle to change the window title.

You can identify each window with its handle. Look at WinGetHandle in the help file.

You can write directly to the serial port(s) in Windows if all you're doing is sending text to it. Something like this: echo "text to send to COM1">COM1

You can always transform the array returned to be one based yourself,it's not that hard. In fact it's extremely easy as your code demonstrates, but it would eat up some processing time, which is why 1 based arrays are not a solution to your problem. I don't see how creating the array inside the function, with a count in 0, is any quicker at all, compared to doing one call to UBound and getting the count from it.

NO, please. No 1-based arrays anymore! This nonsense is already plaging enough UDFs.

Peggy, A couple of your requirements are unclear: - Every person eating a fruit, and each times one person can eat the same fruit (or random fruit): Does this mean that in each round several pairs can eat the same fruit or that only one pair may do so? - If the previous round fruits are finished, the remaining number can pick one randomly: So those with a smaller range from which to choose just repeat choices from that range until the end of the largest range? What if there are no unique (or double) choices left in the round after all the previous selections? What do they choose then? As to doing this for 100+ people, I think that you might begin to struggle. What exactly are you doing? If we get a better idea of the purpose of all this we might be able to offer a better solution. M23

You are reading the response in the wrong way. Here is an example, the helpfile contains some others. #include<WinHttp.au3> $hInternet = _WinHttpOpen() $hConnect = _WinHttpConnect($hInternet, 'snee.com') $sFirstName = "Jack" $sLastName = "Berk" $sSomeOtherURLEncodedVariables = "&a=123&test=void&foo=bar" $sPost = "fname=" & $sFirstName & "&lname=" & $sLastName & $sSomeOtherURLEncodedVariables $sResult = _WinHttpSimpleRequest($hConnect, "POST", '/xml/crud/posttest.cgi', '', $sPost) _WinHttpCloseHandle($hConnect) _WinHttpCloseHandle($hInternet) MsgBox(0, '', $sResult)