Zaxon

If you're refering to PCRE 7.4 as in http://freshmeat.net/projects/pcre/?branch...lease_id=262222 which is an external library, our problem isn't so much with the internal processing of the regex, but rather that AutoIt parses the statement and evaluates it before it can be plugged into the PCRE. And I've already given an example showing that it doesn't work as it is in AutoIt. Testing out an underlying library isn't go to solve the AutoIt side of things.

OK. The outcome of that thread seems to me to be: applying functions to back references totally fails. Use some other workaround instead, perhaps some combination of StringRegExp then manually replacing what you've found. So the upshot is that AutoIt's StringRegExpReplace is only usable for the simplest cases. Are there some plans to fix this to make it more usable?

StringRegExpReplace backreferences don't seem to allow functions to be applied to them. Let's check if back references are working: $string="hello" $string=StringRegExpReplace($string,"(.)","=$1") msgbox(0,"",$string) ; produces: =h=e=l=l=o So, the asc function is being applied FIRST and acts on the literal string "$1" rather than the back reference which will be substituted into it. Is there a way to use functions on back references - like you can in most other languages? If not, then StringRegExpReplace becomes practically useless except for the classic delete pattern: stringRegExpReplace($string,"something here","")

Good guess - it worked! Now, do we know the dll calls to resolve the remote port number?

External programs start a whole new process - an expensive operation in windows. Certainly in compiled or linked languages, you don't have this overhead with .dlls. I'm not sure how DllCall is treated in AutoIt, whether the autoit.exe program links to the dll directly from the process, or whether a new process entirely is launched. With the commands you've given, and thank you for what you've provided so far , netstat -a gives a list of every connection on your system. I could string parse that to find the details I need I presume, but that's a far cry from what I'm expecting to do. In PERL, I can interrogate the connection object of my current connection directly and it will happy tell me the IP and port of my current connection. No need for external commands or parsing down a couple of pages of netstat output to find the one thing I'm interested in. The SocketToIP($SHOCKET) used to work (I'm assuming). I've changed one of the types from int_ptr to int, as directed by the output I received, but I'm currently just get "0" return. Plus, a port was never returned, though I'm sure it's just another dll call away.

They're external commands. Given that your AutoIt script has the TCP connection, you'd think you'd be able to interrogate that connection directly from within AutoIt or at the least via a DLL call.

I'm trying to get the IP address, port #, and possibly even do a lookup to resolve the name of the remote peer that you're connected with via TCP/IP (using the inbuild AutoIt TCP connection commands). This needs to work on both the client and server sides. I can do this with PERL quite easily, but I'm trying do replicate that functionality with AutoIt. The SocketToIP() function given in the AutoIt help doesn't seem to work, even after I modify it because int_ptr is now a deprecated type. In addition, it never gave the port #. I've combed the forums for this info and read countless posts, but haven't seen mention of how to get this basic info about your connection.

Thanks. Works like a charm.

I've used code forever that changes the format of a date control, and although my script hasn't changed, a more recent version of AutoIt breaks the functionality. Currently using autoit-v3.2.9.11. I've written a test script by way of example: #include <GUIConstants.au3> GUICreate("") $date=GUICtrlCreateDate("",5,5,100,20,$dts_timeformat) $style = "hh:mm tt" ; or ;$style = "hh':'mm' 'tt" GuiCtrlSendMsg($date, $DTM_SETFORMAT, 0, $style) ; or ;GUICtrlSendMsg($date, 0x1005, 0, $style) GUISetState(@SW_SHOW) sleep(5000) This creates a time (date) control and attempts to change it's format to one which excludes the seconds. The two different format ($style = ) lines show testing attempts with the way it used to work in a previous version of AutoIt and the way given in examples in this forum. Same with the two SendMsg lines, one showing the way my script uses it, the other the way it's currently shown in forum examples. What I end up with is a date control showing a single number, eg: "5" for the actual time "5:24 PM", no minutes etc are shown. I've played around with the format of the $style string - pretty much everything I could think of - but I keep getting just a single digit shown instead of a properly formatted time. Now, I don't know what changed in AutoIt to break this functionality. How can I now correctly change the time format?

So as a group we can't figure out how to start VLC via ActiveX? If this is the case, then that's a pity, since we're about 90% of the way there already. I can already start it, but one of the types I'm passing to the call is incorrect.

It seems like we've taken a step backwards. VLC doesn't open at all with this code. addTarget is definately still listed as a valid method in all the reference material.

I've updated the VLC references in the previous post. If anyone can see, based on the information I've provided, how to correct the addTarget method call, that will solve our current step.

OK. This thread seems to have been taken off on a slight tangent. The purpose of this thread being how to programatically control VLC: pause, jump to location x, "what position am I currently playing in the file",unpause, stop etc. So I will bring it back to that. I've messaged the VLC support forums about this http://forum.videolan.org/viewtopic.php?p=106030#106030 and have been told that VLC can successfully be controlled via ActiveX without needing to use a web browser. I will add that virtually 100% of times VLC mentions ActiveX on their site it in the same sentence as web browser. Hence it wasn't my first avenue to try from a stand alone language. The support forum for ActiveX is even called "Web and scripting". But let's move on. ActiveX Taking the examples from the VLC website written in other languages, having read numerous posts on their support forum etc et al, I've written some code for starting VLC via ActiveX that almost works. #include <Constants.au3> $file="c:\temp\test.mpg" ; change this to a file that exists on your system $vlc=ObjCreate("VideoLAN.VLCPlugin.1") if @error then msgbox(0,"Error","Unable to create VLC object") exit endif ;msgbox(0,"",$vlc.versioninfo) ; uncomment this line if you'd like confirmation that we're successfully communicating with VLC dim $options[1] $options[0]=":vout-filter=deinterlace" enum $VLCPlayListInsert=00000001,$VLCPlayListReplace=00000002,$VLCPlayListAppend=00000004,$VLCPlayListGo=00000008,$VLCPlayListCheckInsert=00000010 $vlc.addTarget($file, $options,$VLCPlayListGo,0) What it does is: 1. Successfully create a VLC object 2. Successfully communicate with that object 3. Starts up VLC 4. But AutoIt errors out immediately after starting up VLC 5. VLC will successfully play the file until you close down the AutoIt error I believe that we're 90% of the way there; the objective being to start VLC via ActiveX with the view to allow full control over the VLC object. The error is caused by the $vlc.addTarget() line, so it's probably simply means we have the wrong variable type in the one of the fields. That's what we're here to figure out together. I have posted my code and asked for assistance in the VLC forum etc (see the above link) but I haven't received any reply. Hence, it's up to us AutoIt people to work out how to start up VLC via ActiveX on our own. Reference Material To figure out what might be wrong with the addTarget line, here are some VLC resources: http://wiki.videolan.org/ActiveX_Controls This page tells us the format for addTarger is: addTarget(uri as String, options, mode as VLCPlaylistMode, Position as Long) http://wiki.videolan.org/ActiveX/Delphi This gives us an example of using ActiveX via Delphi

This is spam right? VLC's website is videolan.org and has nothing to do with the website you posted.

I know. Solve this and we've created the 8th wonder of the world, right?

lol thanks. I'll let my parents know the education they gave me is paying dividends. Ah yes. I referred to "command line" a few times as my way of describing the line oriented, DOS like command window that comes up after you start VLC. But I can see the confusion. No requirement for it to be hidden. But not in focus (ie in the background) is a requirement, since VLC needs to be pumping video out to, say, the TV output while simultaneously allowing someone else to be chatting to you right here on the forum.

I need to establish interactive read/write relationship with the VideoLan player from AutoIT. However, I'm unable to achieve this. VLC doesn't offer a COM interface, so there goes our easiest way. VLC does offer some language specific bindings which are therefore of no use to AutoIt. VLC does offer a basic command line interface so I've tried to tap into this. command line interface On the surface it seems like any other command line interface, but I'm now having my doubts since it doesn't seem to be cooperating as such. Many of you will have VLC on your systems, so you can play along with the examples I give. To allow flexibility, I'm placing each example of each command type in a separate function and clearly labelling it. There are other steps I've taken that aren't shown. But I thought I'd show basic examples of what would need to be working before we can move onto those later steps. 1. Basic VLC startup #include <Constants.au3> $file="c:\temp\test.mpg" ; change this to a file that exists on your system start_nothing_streamed() func start_nothing_streamed() global $vlc=run('C:\Program Files\VideoLAN\VLC\vlc.exe --extraintf rc "'&$file&'"',"",@sw_show) endfunc oÝ÷ Ù¼(®K?mfails So redirecting just the outputs means that we it stops accepting keystrokes. And as we know from our previous example, the command line doesn't accept redirected input either. 5. Fudge input and output I have a requirement that VLC be communicated with while in the background. While we can use controlsend() to send commands, this does preclude any alt-space screen scrapes, since they require the app to have the current focus. To me, it looks like VLC command line is non standard and doesn't want to play nice. (If there's any errors in the way I've attempted to communicate with it just let me know so we can all go home.) Can anyone help in sending commands and receiving responses to VLC?

I have a script which uses a DLLCall to interact with another application. Specifically, it calls a DLL which interacts with Winamp. However, if winamp is unable to play the file it hangs. My main script, therefore, infinitely waits for the return of the DLLCall which will never come. The solution I need is for my DLL calls to have a timeout. And seeing that the DLLCall statement doesn't have one, we need to provide a workaround for it. This is the assistance I'm needing. The algorithm would go: 1) Call the DLL 2) Wait n seconds 3) If the DLL hasn't returned a result by then assume it has hung and take appropriate action How do I achieve this? Since the DLLCall function will freeze the script completely in which it's called, the only workarounds I can see is to: 1) Write a c program which uses the DLL. Look for the name of the c program in the process list. If it still exists after n seconds, assume it has hung and kill the process 2) Write a second AutoIt script which makes the DLL call. Have the second script create a flag to indicate it is still running. If this flag exists after n seconds, assume it has hang and kill the second script Does anyone have a more elegant solution for recovering from DLLs which hang?

All true but not what I'm looking for. So let me write you up some sample code. #include <guiconstants.au3> $window=guicreate("my window") guictrlcreatebutton("my button",100,100) guisetstate(@sw_show) ; fart around for a bit sleep(10000) ; call a pre-written library routine that gets data from the current GUI window some_library_routine() #cs I'm a separately written library routine. * I want to perform a task on the "current GUI window". * I don't know its name nor its handle. And for the sake of this exercise, I refused to ask for it. I need to discover it on my own. * I have to assume that between the time the window was open and the time I was called, that some other program running on the computer may have focused itself to the front. So I can't expect the window to be the active one. #ce func some_library_routine() $current_gui_window = magically_discovering_function() $client_size = WinGetClientSize($current_gui_window) endfunc The whole purpose of this exercise is that all GUICtrlCreate* functions magically know what the current GUI window is. So I want some library routines to also magically know, without being explicitly told, and without assuming the created window is still the active one.

GUICtrlCreate* functions add controls to the window AutoIt has defined as current: either the last created window or one moved to via GUISwitch. Assuming that you want to access information about this current window from another function that hasn't created it (and for the point of this discussion doesn't want the window handle manually passed to it), is there a way of getting a window handle to the "current GUI window"? This would allow you to use functions like WinGetClientSize() to read information about the "current GUI window", which may not be the same as the currently active window in a Windows® sense.

I'm familiar with that sorting UDF. In fact, my present application code was based on that function, but a few beta's ago that function was slowed down and is now unuseable for me. It takes 8 seconds to sort a very modest listview. No user is prepared to wait 8 seconds just to display one list view. I created a minimalistic test script that did nothing but create a listview and sort it, and it came in at about 6.5 seconds. There's another script in the scripts and scraps section that claims to be 20x faster, that comes in at about 6.5 seconds. However, sorting via the registered function takes about .5 seconds. So you can see why I'm insisting on making use of that functionality. All I need to do is to programmatically trigger that sort. Presently I don't know how to do that: hence the purpose of this thread. But I'm sure it's simple, and there are a few people on this forum who I'm sure know how to do that. My alternate strategy is to presort the data in an array and then populate the listview from that. Much quicker than _GUICtrlListViewSort I'm sure. But seeing that I've already got the code in to cater for the registered sort, I thought I would hang out for the "programmatic click" functionality to show up.

OK. This is turning out to be a very long wait for a solution - it's about 12 days since I first asked the question. Should I assume that not many people are familiar with sending messages to GUI objects?

Easy. I have a tv site which I parse. On the TV guide page, it has links to individual page descriptions about episodes. Now, all description links contain a certain substring within a javascript URL. The link changes for every episode. However, there is always a substring that contains a unique string that I know about. So, I need to be able to say, click on the link that contains "blah blah" in its URL. And in case you're thinking that you can just calculating the URL, the site has referer blockers, so you HAVE to click to its pages from the main TV guide page. You can't go straight to its description pages.

I'm not sure if DaleHohm has considered this before or not: I was writing a utility which made use of the fabulous ie.au3 library. I needed to click a link based on URL. As it stands now, you need to manually iterate each link using _IELinkGetCollection, and then switch to _IELinkClickByIndex to make the click. It's an involved process, when comparised to _IELinkClickByText which does it all in one command. It would be good if link clicks could be generalized. So throw away _IELinkClickByText, and replace it with: _IELinkClickByType (or whatever you want to call it). It could have the form: _IELinkClickByType( ByRef $o_object, $s_linkString, $s_mode = "text" , [$f_wait = 1]] ) $s_linkString = the string to match $s_mode = "text", "URL", etc. I've bastardized the format of some already existing _IE commands, here. The concept being that you can cause a link click as easily base on URL (or any other relevant criteria) as you can now on text.

Ah! That explains why I wasn't getting anywhere. Ah! I've already got that part covered. But thanks anyway. The part I'm missing, and I'm sure you'll be able to help me out seeing that you've got a good knowledge of the area, is to programatically initially sort the columns. That's step 3 from the sequence below. So the sequence goes like this: 1. Create the ListView 2. Populate the listview 3. Cause an initial sort on a column of the code's choice by GUICtrlSendMsg (simulating someone clicking on a column) <= this part is needed 4. Hang around and process any sort requests that come through. So I'm wanting the code to initially sort the listview before handling over the listview to the user.