Leaderboard

Dana, Hence my comment about the construct being "an abomination" that "only works by pure luck". Why rely on the AutoIt parser when you can make it unambiguous with parentheses (do not agree that they are necessarily redundant) or by splitting the two statements (much better practice)? Booleans are tricky things and any coding shortcut is a recipe for disaster. Just make the code as simple as possible and there is much more chance of getting it right! M23

To avoid the headache from the next barrier you are likely to hit, you might also want to make sure you understand Network Address Translation and Port Forwarding.

Special Note: This is an official beta release but it is not digitally signed. Only Jon has the certificate used for digital signatures and the last time I checked I was not Jon. 3.3.7.21 (6th November, 2011 (Beta) The following changes are script breaking changes: Note: For all you whiny bitches, COM speed is almost as fast as 3.3.6.1. Thank all of you for the little faith you show in us. Report issues here. Download here.

I can clearly remember the similar situation in past when developers removed StringAddThousandsSep() from standard UDFs just because of too much bug fix requests. I use this (latest one) function in several of my current projects and hopefully its simple workaround to copy its sources from latest Autoit where this function is available. Anyway I think this is way to hell for Autoit if it will be cripled just because of bad mood of some developers. I hope situation will not be so bad anyway and I hope Valik won't ban me now for this post.

Do you read the things I write? Do you read the things you write? I've already explained at least twice now that the speed may be improved in the future. What more do you want? Should I delay the release of 3.3.8 by 6 months just so a few ungrateful whiny bitches who know fuck all about programming can have their precious "fast" COM code? If you do not like how the current version of COM works then use another language. It is clear to me that you either did not read all of my post(s), you failed to understand them or you are willfully misconstruing what I said. I'm not sure how you find it misleading when I give what is essentially a high-level overview of the implementation details of the problem and solution. Secure versions of ATL are the cause. The changes to AutoIt are the effect. Do not fuck with me on this subject any more. If all I can expect for all the hard work trancexx has put into getting COM working right is a bunch of bitching I will remove COM from the next version of AutoIt. I suggest all of you shut the fuck up and see what happens rather than being incessantly annoying about it. If any of you think this is a hollow threat then push me and you will see a new beta without COM within an hour of me seeing your post. I suggest none of you waste my time in pursuing this. End subject unless another developer has something else to say.

Oh no you didn't... <insert missing popcorn smiley>

Let's see what struct type is, why it's added and how to use it. struct is type identifier for parameters passed to DllCall() function and objects created with ObjectCreateInterface(). It tells AutoIt that parameter is to be interpreted as structure (composite type). Essentially x64 systems (100 years ago) brought the need for this kind of identifier. More specifically the need for non-compiled scripts to be equally runnable both with/thru 64bit and 32bit version of the interpreter. This is one of three main rules for every good AutoIt script. To show proper usage I'll use two examples. One is for struct* and other for struct. struct* is, as said already used when you want to pass structure pointer. Previously you would use ptr type and function DllStructGetPtr($tSTRUCT). Not to create confusion of some sort you can still use that method, only it's recommended that you do something like this: _Example1(64 + 262144, "Caption", "Some text to display.") Func _Example1($iFlag, $sCaption, $sText) ; Some sub-structures required by the main structure below. Don't let this catch your eye. Local $tTEXT = DllStructCreate("wchar[" & StringLen($sText) + 1 & "]") DllStructSetData($tTEXT, 1, $sText) Local $tCAPTION = DllStructCreate("wchar[" & StringLen($sCaption) + 1 & "]") DllStructSetData($tCAPTION, 1, $sCaption) ; Create the main structure Local $tMSGBOXPARAMS = DllStructCreate("uint cbSize;" & _ "hwnd hwndOwner;" & _ "handle hInstance;" & _ "ptr lpszText;" & _ "ptr lpszCaption;" & _ "dword dwStyle;" & _ "ptr lpszIcon;" & _ "dword_ptr dwContextHelpId;" & _ "ptr lpfnMsgBoxCallback;" & _ "dword dwLanguageId;") ; Fill it DllStructSetData($tMSGBOXPARAMS, "cbSize", DllStructGetSize($tMSGBOXPARAMS)) DllStructSetData($tMSGBOXPARAMS, "lpszText", DllStructGetPtr($tTEXT)) DllStructSetData($tMSGBOXPARAMS, "lpszCaption", DllStructGetPtr($tCAPTION)) DllStructSetData($tMSGBOXPARAMS, "dwStyle", $iFlag) ; Call passing struct for "struct*" parameter type Local $aCall = DllCall("user32.dll", "int", "MessageBoxIndirectW", "struct*", $tMSGBOXPARAMS) If @error Then Return SetError(1, 0, -1) Return $aCall[0] EndFunc Another example is using struct type. This is where the whole magic is seen. Without struct type you are forced to use different workarounds not to cause stack corruption when your code is run with interpreter of wrong bitness. Now you can elegantly push a blody structure as parameter: ConsoleWrite(WinGetTitle(_Example2(10, 10)) & @CRLF) Func _Example2($iX, $iY) ; Create structure Local $tPOINT = DllStructCreate("long x; long y") DllStructSetData($tPOINT, "x", $iX) DllStructSetData($tPOINT, "y", $iY) ; DllCall passing struct for "struct" param type Local $aCall = DllCall("user32.dll", "hwnd", "WindowFromPoint", "struct", $tPOINT) If @error Then Return SetError(1) Return $aCall[0] EndFunc Anyway, this is how different scenarios are handled: Parameter description: Parameter type: Action: - "struct" - dllstruct - accept and process sruct - "struct" - non-dllstruct - error is raised - "struct*" - dllstruct - pointer to dllstruct is read internally - "struct*" - non-dllstruct - parameter is taken to be dllstruct pointer As I said, the same thing applies to objects created with ObjCreateInterface, called InterfaceDispatch objects. Their description string can include struct and struct* type identifiers.