sohfeyr

How did that work out for you?

Thanks ptrex! That really does mean a lot coming from you, and I'm glad you approve. I'm hoping that others will get interested and also post their projects or samples along these lines. I'm also considering eventually building a tutorial. I know a lot of people don't like .Net that much, but I get the feeling it is going to be around for the next few years, and getting increasingly common. If AutoIt can easily interact with .Net components and features, less development will have to be done to AutoIt itself to stay as widely useful as it is now. For those looking for ideas, these would all make really good projects: Using ObjEvent() with .Net eventsCreating a static object that can be accessed by multiple scripts / programs at the same time (yes, this is possible!)Create a COM wrapper for an AutoIt script using ConsoleWrite, StdInRead, etc. and use it in another kind of program. (Hint: use the System.Diagnostics.Process object)Use that COM wrapper to transparently run an AutoIt script as a Word, Excel or PowerPoint macro like it was an ActiveX object.Use a COM wrapper for an AutoIt script running as a service to treat that script like a libraryCreate a decorator object around a native .Net class and expose it's functionality to AutoIt. Suggestions include Drawing.Bitmap, System.Diagnostics.Trace and System.Diagnostics.TraceListener, System.IO.Ports.SerialPort, System.IO.FileSystemWatcher, and System.IO.Compression.GZipStream . (It is *insane* how many posts I see in the Help forum that could be answered with wrappers and decorators around these objects.)Try Microsoft.CSharp.CSharpCodeProvider.CreateCompiler().CompileAssemblyFromSource() - talk about powerful? Write and compile dynamic .Net applications with AutoIt logic via a COM object! (Also available in Microsoft.VisualBasic flavor)If all that doesn't give people ideas, then they have a serious lack of imagination. If anyone else can think of more, by all means post them. Potential is every bit as importent as actualization, and sooner of later it might actually get made!

I think Auto3Lib should use whatever is most recent, since that is what most everyone on the forums uses. In other words, I agree with how Paul has been operating to date. Sometimes it is helpful to remember that the common factor in all our problems is usually ourselves. If you're having compatibility problems, you may need to upgrade - I did.

This seems to be a recurring topic of interest, so I thought I'd share this COM object I wrote in VB .Net, called "ImgTool". It has functions that capture all or part of the screen directly to a variety of image file formats. (Yes, I know there are easier ways to do that - at least to bitmap - but I just wanted to give a non-trivial example.) To compile the attached source, you will need the .NET Framework 2.0 SDK or Visual Studio 2005. To run the following code, you just need the attached DLL file, which source is in the Zip. You'll notice that this only uses properties and methods; COM events (like for ObjEvent()) seem to take a little something extra I'm still working on, and at any rate were not needed for this sample. My main point in posting this was to show which attributes to use and how to register .Net types for COM interop. The .snk file in the source is needed to generate the type library, and is obtained using sn.exe. If $CmdLine[0]=0 Then Local $path=FileOpenDialog("Select a .NET assembly to register",@ScriptDir,"DLL files (*.dll)",1) If @error=1 Then Exit ;MsgBox(0, "Net DLL Registration", RegisterDotNetComponent($path) ;) Else RegisterDotNetComponent($CmdLine[1]) EndIf Dim $com = ObjCreate("ImgTool.ImgConverter") $com.Test() $com.ScreenShot("screen","c:\screen.jpg") ; Regexp: (?<mode>LT(?<m>RB|WH))\((?<L>\d+),(?<T>\d+),(?<W>\d+),(?<H>\d+)\) $com.ScreenShot("LTWH(50,50,100,200)","c:\ltwh.jpg") ; ArgumentException - check the RegEx MsgBox(0,1,$com.GetLastError()) $com=0 Func RegisterDotNetComponent($path) Local $text Local $regasm = "C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\regasm.exe" Local $regasmparams = ' "' & $path & '" /tlb' Local $gacutil= "C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\Bin\gacutil.exe" Local $gacutilparams = ' -i "' & $path & '"' $text = GetOutput("RegAsm", $regasm, $regasmparams) ;~ regasm "$path" /tlb $text &= @CRLF & @CRLF $text &= GetOutput("GACUtil", $gacutil, $gacutilparams) ;~ gacutil -i "$path" ConsoleWrite($text) Return $text EndFunc Func GetOutput($name, $path, $params) If StringLeft($params,1) <> " " Then $params = " " & $params Local $pid = Run($path & $params, "", @SW_HIDE, 7) ;~ regasm "$path" /tlb Local $out = StdoutRead($pid) Local $strout = $name & ":" & @CRLF & $out While $out $out = StdoutRead($pid) $strout = $strout & @CRLF & $out WEnd Return $strout EndFunc Edit: uploaded second zip file with the dll and tlb files ImgConv.zip ImgTool_dll.zip

Gladly, but I should tell you that because of the complexity of what I'm doing, I will probably end up doing most of my own COM objects in VB.Net 2. I hope to do some of the simpler items in WSC like you demonstrated but have yet to figure to how to force multiple instances to refer to the same COM object. (It can't be as simple as implementing a Singleton pattern like in Java, can it? I need to learn a lot more about vbscript constructors...) If someone wants to volunteer knowledge of how to implement an object to do that with WSC (as Valik described), it sounds like we'd all be interested.

Thanks! now I know on which side of the implementation to focus the research. It may not be as clean as having exported functions, but being able to wrap a script in a COM object could be very powerful, and for many purposes just as good.

That's certainly true. Guess we have to wait for a developer to get interested enough and find time to do it, after all. I do have another idea for how to expose the functionality of one script to another so that it acts like a library. Do you know of a way to have two scripts interacting with the same COM object at the same time? I've been pondering using ptrex's method of setting up a Windows Scripting Component and GUISetState() with a hidden window. The various functions in that library could get invoked using ObjEvent... except I can't figure out how to share a reference to such an object from another script to fire said events. What is the nature of the value returned by ObjCreate(), and is there any possible way to do what I'm talking about with the current build of AutoIt? (Yes I know this isn't the help forum, but as long as we're talking implementation maybe one or the other of us can come up with a way that is pragmatically similar to what has been previously discussed here. If you think it's too far off-topic I'll happily repost elsewhere.)

Thanks, it's nice to know what is involved... even without obstacles, I wouldn't expect it to be "trivial" work. I also appreciate that you don't like to make changes to the code except as bug fixes, and the compiler and runtime engine sound like dangerous places to operate - stuff breaks, after all. Is there any chance of that other idea working, or being modified in some way to work - sort of an in-memory variation of #include?

Short answer: Yes Long answer: Yes, please Uninformed alternative track that might have a similar effect, or at least lead to some interesting ideas: Another possibily that occurred to me was a UDF solution similar to what Outshynd and WSCPorts are doing here, except instead of targeting an external process the program would target itself using @AutoItPID or AutoItWinSetTitle() and WinGetHandle(). The code in your EXE could have directives to inject the A3x into the tokenized code portion of that same executable while it is running. (Think "The Blob".) Of course, I probably just demonstrated an enormous lack of comprehension about what exactly it is they are doing, how DLLs work, how compiled AU3 scripts are represented in memory, what exactly the AutoIt compiler does, the relationship between the AutoIt.lib and the rest of the file...

Valik, could you please describe the obstacles involved? It's a design consideration that puzzles me anew every time I do something in AutoIt, and I'd love to hear your take on it from a technical perspective. Being nowhere near your level of expertise, I can't pretend to be able to do anything with the information except learn - but I like to think that's a noble enough goal? At the same time, I realize this may come close to some of your "top-secret" code (like how you get around restricted memory, the compiler of course, and possibly even the DLLCall secrets) so if there are security issues involved... well, I'll be disappointed, but I'll understand. Probably the most profound thing I've learned from these forums is how many people are out there wanting to use good ideas for bad purposes.

Guys, I think wOuter is more likely to pay attention to things happening at http://www.autoitscript.com/forum/index.php?showtopic=19329Look at the first post in the thread... he last updated this in Feb 2006, and last responded to a post in this thread in Dec 2005. The first post has been modified to point to his signature for a link to newer code. That thread hasn't seen any activity since mid-2006, but it's worth a try. And no, apart from that, I personally can't help you with this

@jvetter: You're welcome! Glad to help. @zaduma: You're not. I came inches within solving your programming problem. I gave you sliced bread, meat and cheese, and you complain I didn't give you a sandwich. If you need help with laziness, seek the help of a licensed therapist - or perhaps find someone to do it for you. You have all the grace and problem-solving skills of a cinderblock tumbling down a mountain, and will receive no further assistance, or replies, from me.

Without solving your problem for you (tempting as it is...), remember that every control is also a window. Once that is understood, a tremendous chunk of the Win32 API begins to make sense. Here is code in regular AutoIt to get a control from a point: ; WindowFromPoint (thanks Larry!) Func WindowFromPoint() Local $point, $cHwnd, $hwnd, $pos, $size Local $dll = dllopen("user32.dll") $point = MouseGetPos() $hwnd = DLLCall($dll, "hwnd", "WindowFromPoint", "int", $point[0], "int", $point[1]) If $hwnd[0] <> 0 Then $pos = WinGetPos($hwnd[0]) If @error Then Return 0 $size = WinGetClientSize($hwnd[0]) If @error Then Return 0 $pos[0] += (($pos[2] - $size[0]) / 2) $pos[1] += (($pos[3] - $size[1]) - (($pos[2] - $size[0]) / 2)) $cHwnd = DLLCall($dll,"hwnd","RealChildWindowFromPoint","hwnd",$hwnd[0], _ "int",$point[0] - $pos[0],"int",$point[1] - $pos[1]) If $cHwnd[0] <> 0 Then $hwnd[0] = $cHwnd[0] EndIf DLLClose($dll) Return $hwnd[0] EndFuncIn AutoItX, the MouseGetPos, WinGetPos, and WinGetClientSize functions are split up into X and Y, but you probably already noticed that. Naturally, you can accept X and Y as parameters instead of using the mouse position. The DLLCall is the tricky part, but it can be replaced with a function made with the DLLImport attribute. PInvoke.net gives the C# signatures (easy enough to translate) for RealChildWindowFromPoint and WindowFromPoint as: [DllImport("user32.dll")] static extern IntPtr RealChildWindowFromPoint(IntPtr hwndParent, POINT ptParentClientCoords); [DllImport("user32.dll")] static extern IntPtr WindowFromPoint(POINT Point);You will also need this (which is already in VB.Net): <System.Runtime.InteropServices.StructLayout(Runtime.InteropServices.LayoutKind.Sequential)> _ Public Structure POINT Public X As Integer Public Y As Integer Public Sub New(ByVal X As Integer, ByVal Y As Integer) Me.X = X Me.Y = Y End Sub End StructureSee MSDN for additional info on those. Suppose that you are uncomfortable with handles for whatever reason, and wanted to get the control ID; you can feed the handle from the above function into this GetDlgCtrlID, and it will give you the exact same thing the AU3InfoTool will. [DllImport("user32.dll")] static extern int GetDlgCtrlID(IntPtr hwndCtl); The rest should be fairly straightforward, and I think the resulting code should work on any 32-bit system after Win95. Good luck!

Thank you, that certainly covers the #Compiler_ directives, but I'm still in the dark about #forceref - anyone know about that?

I'm having trouble finding the documentation for the preprocessor directives and/or other things that start with #. I've checked the AutoIt and SciTe help files without success. Specifically I want to know more about #forceref, but I'd also like to know more about the #compiler directives. Could anyone point me towards where those are documented?

Yes, yes, a thousand times YES! The feature found in other languages that I miss most in Autoit is encapsulation. The UDF set I'd like to encapsulate most as a COM object would be the Auto3Lib, and after that the extant GUI UDFs. Even if it isn't much of a performance benefit, if it leads to cleaner (and therefore more maintainable) code, it would be totally worth it - as long as there isn't some substantial performance hit, like you get when running a udf "engine" in a seperate process.

Those interested in doing this kind of experimentation might benefit from Uten's work in creating a wsc.properties file for SciTE, located here.

I see what you mean! If I ever need that feature, I think I'll just write a command-line tool in .Net; Image format conversions are pretty much built-in to the Bitmap object, so it only takes a couple of lines. If that is something you'd be interested in seeing, I might do it sooner rather than later.

Awesome. Absolutely awesome. Every time I think you've outdone yourself, there you go again... I do have a feature request for a future release: it would be nice to be able to save screen captures in formats other than BMP. Specifically, JPG format would be most welcome. Apart from that, the way you simplified that (surprisingly complex) functionality into a single command is fantastic. I've been running the example scripts again for you. I found only two bugs! Just so you know: C:\...\Auto3Lib\Examples\Toolbar 2.au3(97,87) : ERROR: _Menu_GetMenuItemText(): undefined function. _Lib_ConsoleWrite($sItem & "string ........: " & _Menu_GetMenuItemText($hMenu, $iI) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^ The other bug (assuming it is a bug) is that the Tooltip2 example script only returned the first 80 characters of any tooltip, followed by different [control characters]: Contains files shared with your contacts and files your contacts have shared wit [+ACK] Provides options for you to customize the appearance and functionality of your c [+VT] 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789

Ouch. Ok, I deserved that. Serves me right for posting while tired. #2-3 didn't take the form I expected, so I didn't recognize it as what you had described.

That makes sense. Thank you.

I don't think we're communicating. All you showed in this example is a practical use of the StdOut stream and the command line parameters, which have been available all along. I thought you were talking about being able to call individual Autoit functions from other languages, not simply run entire scripts. When you get a chance, would you please clarify what your past couple of examples have to do with what you are trying to accomplish? The limitation of what you posted above is that it will run a new process every time you call that function. I don't dispute it has the desired effect, but it is hardly the same thing? If you were to put a call like that in a loop, you could seriously slow down your system! By contrast, if you were able to preload the autoit file somehow and make calls to it, you wouldn't have all the startup and shutdown time. (At least, that's what happened in my experiment...) Aw heck, you've been working at it a long time... I'll just sit back and watch to see what you come up with. The COM creation is still a huge deal, even if putting a COM-friendly interface on a UDF turns out to be impractical.

I see how you are accessing COM from AU3, but it sounded like you were also able to access AU3 from COM?

That's good to know. What specific OS were you using? I developed that on Win XP Home SP2, and, yes, the user account is in the Administrator group. BTW, I learned later that WSC files don't need to be re-registered after they've been changed because the actual component that gets registered is the script host, to which the wsc file is just a parameter or something. So as long as the file name doesn't change, the time-intensive regsvr32 line is optional.

I agree with you in principle, but I think we've strayed from the topic. The ability to create COM objects from AutoIT is a powerful revelation. However, I fail to see what purpose it would serve to create such components in raw AutoItX. You would have more flexabiliy with an AU3 or A3X file. I think the direction I'd like to see this go is being able to create an object in one script and share that object using COM with another script. Another cool direction would be This would let you do things like, say, compiling PaulIA's Auto3Lib project in an a3x file, running it as a service, and passing complex arguments to the functions - arguments like DLLStructs, Object references and multidimensional arrays. I imagine there are some people who'd like to do something similar with some of the graphics libraries I've seen floating around the forums. (COM supports arrays brilliantly, or at least the Scripting.Dictionary or Collections.SortedList objects do. DLLStruct and Object Reference support is speculative insofar as being AutoIt-compatible.) Anyways, I think we should focus more on the possibilities than the limitations for right now. This is too powerful a technique to let lie just because we can't say <script language="AutoIt">