doudou

I don't know what's wrong with x64 version of AutoItObject as of 1.2.8.2, but 1.2.8.3 fork from AutoItMicro project works like a charm under 64 bit.

_AutoItObject_Startup() crashes immediatly executed under Autoit3_x64.exe (not under Autoit3.exe) with c0000005 (access violation): #include <AutoItObject.au3> _AutoItObject_Startup() Sleep(2000) _AutoItObject_Shutdown() Environment: OS: Win 10, 64 bit AutoIt: 3.3.14.2 AutoItObject: 1.2.8.2

I think you should post it to AutoItObject topic. By the way, in my environment (Win 10, 64 bit) _AutoItObject_Startup crashes only executed with AutoIt3_x64.exe, AutoIt3.exe works.

Sorry for late answer: this forum doesn't allow permanent subscriptions and I have no time for monitoring all topics. In case help still needed: First of all in order to use DDE communication your DDE server application must be up and running, Windows won't start it for you. Also, both client and server must be running in the same security context (unless NetDDE is involved, which is a science in itself), i.e. a server running as system service or with high privileges (Administrator) are not allowed to answer DDE calls from user land.

Sorry for late answer: this forum doesn't allow permanent subscriptions and I have no time for monitoring all topics. What was exactly your problem? Did you solve it?

Sorry, forgot to point that out. Actually all required files are on SF, I extended the leading post to remind people to look in Misc folder too.

This line is protection from TypeLibs that (illegally) declare methods of IDispatch/IUnknown as part of their own internal interfaces, if we don't ignore them here, we can end in an endless loop. Apparently uiautomationcore.dll is quite ill-programmed, what does OleView say on this topic?

You may try to load the interface in AIOWrapper directly by GUID, if it fails there again... well, that means that registry structures in Win7 don't match. I am planning to integrate AIOWrapper functionality into TypeLibInspector anyway, that is don't feel like spending much time on debugging. You are of course welcome to investigate and to share your findings.

This message is normal if interface or typelib isn't properly registered on the system, try a different one (use OleView or TypeLibInspector to find a valid interface)

Version 1.0.6 released. AIOWrapperGenerator has been improved too (thanks for suggestions, junkew).

To my knowledge OPC is an automation protocol for field hardware and has no relation to DDE... However, many OPC drivers offer DDE control interface, those can be most certainly handled through DDEML. Very often such OPC drivers give you COM or .NET API as well, which raises the question "Why bother with DDE then?" All in all OPC stuff is extremely vendor specific.

The second variant of your code looks completely broken, the first one below may be better point to start (anyway you said yourself, it's working). If you wish to receive callbacks from your server in an advise loop you must not disable them by passing $CBF_SKIP_ALLNOTIFICATIONS in _DdeInitialize(), please consult MSDN for possible values and their meanings. Further, it's been said here already: return $DDE_FACK (s. MSDN on DdeCallback) from OnDDE_AdvData() otherwise server would consider callback failed. There's absolutely no point for these calls (especially pointless: OnDDE_AdvData("","","","","")) being placed in client code, OnDDE_AdvData() is a callback function and is to be called by DDEML library and this only. Side note (looking at your 2nd post): don't free $hszService and $hszTopic before you are done with the DDE conversation, the same is valid for $hszItem as long as your client is exchanging data associated with it (i.e. keep it until the advise loop ends).

Try this: $xmlhttp = ObjCreate("Microsoft.XMLHTTP") $oXML = ObjCreate("Msxml2.DOMdocument.3.0") $oXML.async = False ; ---^ without this chances are good your xml haven't been parsed yet when you attempt to send it $XmlSourceDO="..\BEAST_DASHBOARD\ActivationReq.xml" $oXML.load ($XmlSourceDO) $xmlhttp.open ("post","https://IP:Port/services/CAPWsController",false) $xmlhttp.setRequestHeader ("Content-type", "application/x-www-form-urlencoded; charset=UTF-8") $xmlhttp.setRequestHeader ("Content-length", StringLen($oXML.xml)) $xmlhttp.setRequestHeader ("Connection", "close") $xmlhttp.setRequestHeader ("SOAPMethodName", "processRequest") $xmlhttp.send($oXML.xml)-----> gives an error in this line If($xmlhttp.readyState = 4) then $XMLResponse = $xmlhttp.responseXML.documentElement.text $XMLResponse= $xmlhttp.responseText EndIf MsgBox(1,"asddf",$XMLResponse)

res: protocol is IE specific and Flash obviously doesn't support it. Use FileInstall to extract your movie at runtime: FileInstall("C:\slide.swf", @ScriptDir & "\slide.swf", 1) If @compiled Then $oRP.Movie = @ScriptDir & "\slide.swf" Else $oRP.Movie = "C:\slide.swf" EndIf