Hostage

Yep, that fixes it. Thanks. I take it you don't need me to open a bug report?

Is it known that _ScreenCapture_Capture doesn't seem to work in the latest beta (at least not in save to file mode)? The example script in the help file does not cause any files to be created. Do you want this on the bug tracker? #include <ScreenCapture.au3> ; Capture full screen _ScreenCapture_Capture(@MyDocumentsDir & "\GDIPlus_Image1.jpg") ; Capture region _ScreenCapture_Capture(@MyDocumentsDir & "\GDIPlus_Image2.jpg", 0, 0, 796, 596)

I guess it really comes down to some method of using IClassFactory2 when instantiating the COM object. My gut feeling is that AU3 can't do it. I should maybe have tried that before buying $1k worth of COM objects for this project... woops...

I phrased a bit of that wrong. The FAQ shows how to supply the run time key when you programmatically create the control- since there is no designer to do the heavy lifting for you.

Thanks for looking. This is one of the controls: http://www.exontrol.com/exgantt.jsp Here's their FAQ section on instantiating a run-time licensed control: http://www.exontrol.com/gfaq.jsp#runax This is the MSDN information on licensed controls: http://msdn.microsoft.com/en-us/library/aa751973(v=vs.85).aspx It looks like other language's design tools will retrieve the run-time key from the active X control using the design-time key, and embed it in the EXE. The FAQ shows how to supply it when you instantiate it yourself in languages that don't support the automatic inclusion. I have the run-time key values (the control's supplier gave them to me). Because I have purchased this I can re-distribute the DLL but I believe I cannot share the run-time key. EDIT: I mean share as in post it up here, obviously I have to be able to include it in my program or it would be useless.

I believe that the .LIC file/registry entry is for design-time licensing. From what I understand, run-time licensing appears to require that the license key (a code which I do have) be supplied when the COM object is instantiated, but AutoIT doesn't look to have any ability to supply that. I think it is possible to use an ActiveX object directly without registering it via DLLCall, and I'm wondering if that's the way forward? Just a bit over my head, unfortunately.

I need a little help- I have an ActiveX control that requires a run-time license. I do have the license. I've searched the forums extensively and only see a few fleeting references to this. I'm not sure where to go from here. From what I can see, other programming languages just have the functionality to supply the built in. I have a large-ish project I want to use these controls in, so switching languages is not really feasible. Thanks!

You're right, totally my error. Sorry about that. I moved the information over into the original ticket.

http://www.autoitscript.com/trac/autoit/ticket/1963#comment:2 I created this on the bug tracker regarding the bug mentioned in this post (it had been marked as fixed but I was still seeing the behavior). It was closed out as a duplicate, but I think it should still be open. I just added a comment to it, but I wasn't sure whether adding a comment to a closed bug would bring it to anybody's attention so I thought I'd post here. If I should create a new ticket just let me know. Thanks!

I was just wondering something similar with regards to an ADOR.recordset.

You know Valik, I had a line by line response to you but I've erased it in an attempt to thwart your needlessly aggressive and adversarial responses. I am no longer interested in your unhelpful speculative replies so I would appreciate it if you would refrain from providing them. The treeview delete all function still happily deletes both native and udf controls. It is only the listview delete all function which pops the message. Here is the code: Func _GUICtrlListView_DeleteAllItems($hWnd) If $Debug_LV Then _GUICtrlListView_ValidateClassName($hWnd) If _GUICtrlListView_GetItemCount($hWnd) == 0 Then Return True ;~ Local $iIndex, $control_ID If IsHWnd($hWnd) Then Return _SendMessage($hWnd, $LVM_DELETEALLITEMS) <> 0 Else _WinAPI_ShowError("Use GUICtrlDelete to delete items" & @CRLF & "Or if items were created with UDF functions MAKE sure to pass in handle to control NOT the controlid", False) ;~ For $iIndex = _GUICtrlListView_GetItemCount($hWnd) - 1 To 0 Step - 1 ;~ _GUICtrlListView_SetItemSelected($hWnd, $iIndex, True) ;~ $control_ID = GUICtrlRead($hWnd) ;~ If $control_ID Then GUICtrlDelete($control_ID) ;~ Next ;~ If _GUICtrlListView_GetItemCount($hWnd) == 0 Then ;~ Return True ;~ Else ;~ Return GUICtrlSendMsg($hWnd, $LVM_DELETEALLITEMS, 0, 0) <> 0 ;~ EndIf EndIf EndFunc If one removes the read-only flag from the include file, uncomments those lines and comments out the message it works fine. Very clearly the original functionality was, at a minimum, considered. As much as I hate to mess with the includes files, this solves my problem for now until I can rewrite to take advantage of the obviously better UDF. I am a little reluctant though to go down that road- we've already seen a complete deprecation of the previous UDF for this- does anybody know how stable the new one will be as far as introducing changes in functionality? Further, I have to be able to change the text color of the individual treeview items and I haven't found a way to do that with the UDF controls. I still assert it would be helpful to warn people before they download and install the new version of serious changes in UDFs which ship with the product. As Valik points out, the help file (once it is installed!) alerts you to that but that really isn't necessary- it becomes obvious when you first try to run an old script. Just to be clear, I do appreciate the enhanced functionality of the UDF. All I'm asking for is a little backwards compatibility.

I wasn't aware that any time someone added a message to the code, that meant that it was a permanent decision that was not open to any input or debate. If that isn't the case, then I take exception to your question. Was this actually a problem? I have been _guictrltreeviewdeleteall() - ing giant tree views for some time now and never got a crash that I attribute to that behavior. I do mean this honestly- is there some cause for worry over this or are we simply speculating? Lastly, are you speaking in an official capacity that the behavior is not going to change? I only ask so I know whether I should start re-engineering the way my code works. If it is a permanent change, I hope that the idea of popping a modal text box in what amounts to a programming error is open for re-evaluation. It would be nice if this update were clearly marked somewhere as breaking all the previous guictrlcombo, guictrllistview, guictrltreeview UDF functionality which has shipped with autoit for some time. It would be one thing if it were merely syntax changes, but we've got some actual behavior changes here.

I think it is pretty clear that I read it, since I quoted it verbatim... I'm trying to delete all of the treeview and listview items out of controls created in an autoit GUI. ControlGetHandle does not fix this that I can see.

Hoping this is the right place, but having a little problem: the new _guictrllistview_deleteallitems() pops a messagebox with an error if you use it on a listview containing controls created with autoit (the messagebox says "Use GUICtrlDelete to delete items or if items were created with UDF functions MAKE sure to pass in handle to control NOT the controlid"). The old _guictrllistviewdeleteallitems() worked on either. Any way this can be fixed to function the same work?

Global $ODBC_Access="Provider=Microsoft.Jet.OLEDB.4.0; Data Source=\\fwpsrv\fdrive\FWP Database\New Good.mdb" $newCon = ObjCreate ("ADODB.Connection") $newCon.Open ($ODBC_Access & ";") $rs = $newCon.Execute("SELECT * FROM [TABLE] WHERE [Customer Name Field Name] LIKE '%NAME%'") while not $rs.EOF $name = $rs.fieldS("Customer Name Field Name").value $address = $rs.fields("Customer Address Field Name").value $eye_color = $Rs.fields("Customer Eye Color Field Name").value ;do your stuff here $rs.MoveNext wend $rs.Close $rs = "" That will connect straight to the database using Microsoft Jet. You can look up adodb (that is the microsoft library we're using for database access) connection strings for DSN connections. #include-once just means the file will only be included once.