3.1.0++

[DaleHohm]

Hello Dale,

Thanks for testing the COM-part of AutoIt. 

I don't know how to fix the ObjGet() problem.  I tested it on several other programs.

Could you try to build an Error Event Object around the ObjGet() call, just to receive more information about the error it returns?

An Example:

$oErrObj = ObjEvent("AutoIt.Error","MyErrFunc"); Create an Error Event Object
$YourObject=ObjGet("","YourObjectName")      ; Attempt to open the Object
exit

Func MyErrFunc()
 Msgbox(0,"","We intercepted a COM Error!" & @CRLF & @CRLF & _
 "err.description is: "    & $oErrobj.description    & @CRLF & _
 "err.windescription is: " & $oErrobj.windescription & @CRLF & _
 "err.lastdllerror is: "   & $oerrobj.lastdllerror   & @CRLF & _
 "err.scriptline is: "     & $oerrobj.scriptline     & @CRLF & _
 "err.number is: "         & $hex($oerrobj.number,8) & @CRLF & _
 "err.source is: "         & $oerrobj.source         & @CRLF & _
 "err.helpfile is: "       & $oerrobj.helpfile       & @CRLF & _
 "err.helpcontext is: "    & $oerrobj.helpcontext _
 )
EndFunc

Regards,

-Sven

<{POST_SNAPBACK}>

Thanks for looking into this. Here is the code and the output:

$oErrObj = ObjEvent("AutoIt.Error","MyErrFunc"); Create an Error Event Object
$YourObject=ObjGet("","MindManager.Application")      ; Attempt to open the Object
exit

Func MyErrFunc()
ConsoleWrite("We intercepted a COM Error!" & @CRLF & @CRLF & _
"err.description is: "  & $oErrobj.description  & @CRLF & _
"err.windescription is: " & $oErrobj.windescription & @CRLF & _
"err.lastdllerror is: "   & $oErrobj.lastdllerror   & @CRLF & _
"err.scriptline is: "    & $oErrobj.scriptline   & @CRLF & _
"err.number is: "        & hex($oErrobj.number,8) & @CRLF & _
"err.source is: "        & $oErrobj.source       & @CRLF & _
"err.helpfile is: "    & $oErrobj.helpfile     & @CRLF & _
"err.helpcontext is: "  & $oErrobj.helpcontext )
EndFunc

Output:

We intercepted a COM Error!

err.description is: 0
err.windescription is: Operation unavailable
err.lastdllerror is: 14007
err.scriptline is: 2
err.number is: 800401E3
err.source is: 0
err.helpfile is: 0
err.helpcontext is: 0

>Exit code: 0   Time: 0.595

[Lazycat]

Great! Only problem with Enum - it's seems not work. Example from help - "No variable given..." error. Looks like Autoit don't know this word.

Of course, tested with "M" release

[jpm]

Great! Only problem with Enum - it's seems not work. Example from help - "No variable given..." error. Looks like Autoit don't know this word.

Of course, tested with "M" release

<{POST_SNAPBACK}>

Perhaps I did a wrong merging. I will check

EDIT: Yes I did N being uploaded

Edited March 29, 2005 by jpm

[webmedic]

I/m not a developer but I do have a request. Could the listbox widget be fixed so that multiple select is possible. Like for other command it could be done so that for instance $listbox[0] is the number of selected items and then $listbox[1], etc. are the arrray of selected items. It would surely be apriciated.

Also with the current stdout and stdin. would it be possible to have it so that there would be a simple function for a pipe? Right now as I see it there is not exactly a way to take input from a running comand and send it back to a parent app that calls in the first place. Maybe something like stdpipe() so that it is just a simple pipe from one app to another. I think in the current form there is no easy way to achive this unless I misunderstand the help file.

Thank you

[SvenP]

Thanks for looking into this.  Here is the code and the output:

....

Output:

We intercepted a COM Error!

err.description is: 0
err.windescription is: Operation unavailable
err.lastdllerror is: 14007
err.scriptline is: 2
err.number is: 800401E3
err.source is: 0
err.helpfile is: 0
err.helpcontext is: 0

>Exit code: 0   Time: 0.595

Thanks for testing the function. However, it seems to produce the same information as with your first attempt ("operation unavailable"). I just can't explain why it does not work with your application.

The only way I could debug this, is by having the MindManager application. But I guess it isn't freeware? :-)

Regards,

-Sven

[DaleHohm]

Thanks for testing the function.  However, it seems to produce the same information as with your first attempt ("operation unavailable").  I just can't explain why it does not work with your application.

The only way I could debug this, is by having the MindManager application. But I guess it isn't freeware?  :-)

Regards,

-Sven

<{POST_SNAPBACK}>

No, it isn't freeware, but they do have a 21-day trial -- but you work fast, so 21 days should be plenty

You'll find it here: MindJet (click on the orange 'Free Trial' button on the left).

Dale

[Valik]

JP, what does this change actually entail?

Fixed :      Edit/Input change notification (Thanks Valik)

From what I can tell, there is absolutely no difference in these unofficial builds you are releasing and the latest official/beta from Jon except I'm getting a single message from an input control when I don't expect it. I can't determine what is actually causing this message to fire (Or why it doesn't fire on the other input controls in the GUI). The code is far too massive and complex to post as an example. However, something is different than the last builds from Jon so I'm curious as to what the details of this change was supposed to accomplish. I can't see it doing anything different than before except the odd event mis-fire.

Edit: After more observation, is an input event fired when changing the text via GUICtrlSetData()? Is this a recent change if so? It seems this behavior is the culprit. I also notice that if that is the case, then I'm missing out on several other input notifications.

Edited March 30, 2005 by Valik

[jpm]

JP, what does this change actually entail?

From what I can tell, there is absolutely no difference in these unofficial builds you are releasing and the latest official/beta from Jon except I'm getting a single message from an input control when I don't expect it.  I can't determine what is actually causing this message to fire (Or why it doesn't fire on the other input controls in the GUI).  The code is far too massive and complex to post as an example.  However, something is different than the last builds from Jon so I'm curious as to what the details of this change was supposed to accomplish.  I can't see it doing anything different than before except the odd event mis-fire.

Edit: After more observation, is an input event fired when changing the text via GUICtrlSetData()?  Is this a recent change if so?  It seems this behavior is the culprit.  I also notice that if that is the case, then I'm missing out on several other input notifications.

<{POST_SNAPBACK}>

If I remember well you receive only one notification in the right order.

I did'nt implement a notification at each character.

I will have a look on several inout being change. I certainly check with only one.

[Valik]

If I remember well you receive only one notification in the right order.

I did'nt implement a notification at each character.

I will have a look on several inout being change. I certainly check with only one.

<{POST_SNAPBACK}>

You are correct, the event does come in the right order so that is good. I'm glad that was fixed as that eliminates a synchronization issue I was having.

Here is a small script which demonstrates my "bug" that I mentioned about an event being fired when I don't expect:

expandcollapse popup

#include <GuiConstants.au3>

Opt("MustDeclareVars", 1)
Opt("GUIOnEventMode", 1)

Main()

Func Main()
    Local $hWnd = GUICreate("Test")
    Local $input1 = GUICtrlCreateInput("", 5, 5, 100, 20)
    Local $input2 = GUICtrlCreateInput("", 5, 30, 100, 20)
    GUICtrlCreateButton("Button", 4, 55, 50, 50)

    GUISetOnEvent($GUI_EVENT_CLOSE, "OnClose")
    GUICtrlSetOnEvent($input1, "OnInput1")
    GUICtrlSetOnEvent($input2, "OnInput2")
    
    GUISetState(@SW_SHOWNORMAL)
    
    GUICtrlSetData($input1, "Data1")
    GUICtrlSetData($input2, "Data2")
    
    While 1
        Sleep(10)
    WEnd
EndFunc; Main()

Func OnClose()
    Exit
EndFunc; OnClose()

Func OnInput1()
    DisplayMessage("Input1")
EndFunc; OnInput1()

Func OnInput2()
    DisplayMessage("Input2")
EndFunc; OnInput2()

Func DisplayMessage($msg)
    ConsoleWrite($msg & @CR)
EndFunc; DisplayMessage()

Best viewed in SciTE or another editor to catch the ConsoleWrite() calls.

Run that script using AutoIt3.1.0.15N.zip. When I press the button, I get "Input2" in the output pane showing that the event for Input2 was fired. There was no event fired for Input1. Only the last input control fires an event, meaning, if there would of been more than 2 input controls, none of them except the last one used in GUICtrlSetData() would fire.

In this situation, my expectation is one of:

• No input events are fired. I think of GUICtrlSetData() as an internal source of data; external data would come from the user. I don't expect an event to fire when setting the data internally. If I do need an event to fire, I can call the code explicitly since I know at compile-time when the event needs to be fired. This is what I want to see.
• All input controls fire their events in the order in which they are queued. I do not want to see this method used. I only list it as one of the two possible scenarios.

In other words, I expect to see all the events or none of the events when using GUICtrlSetData() on an input/edit control. I favor seeing no events.

[jpm]

In this situation, my expectation is one of:

• No input events are fired.  I think of GUICtrlSetData() as an internal source of data; external data would come from the user.  I don't expect an event to fire when setting the data internally.  If I do need an event to fire, I can call the code explicitly since I know at compile-time when the event needs to be fired.  This is what I want to see.

• All input controls fire their events in the order in which they are queued.  I do not want to see this method used.  I only list it as one of the two possible scenarios.

In other words, I expect to see all the events or none of the events when using GUICtrlSetData() on an input/edit control.  I favor seeing no events.

<{POST_SNAPBACK}>

try "15O".

I hope I have a working solution. the only side effect will be GuiCtrlSetData will reset any previous setting. That's all I can do due to the fact that CtrlSetData is firing the same event as the typing in the control.

[jpm]

Slight update 15O

Fixed : Doc update Bad links in Opt(), With...EndWith or For...In...Next (Thanks JdeB)

Fixed : Edit/input notification missing/too much (Thanks Valik).

[webmedic]

I,m not a developer but I do have a request. Could the listbox widget be fixed so that multiple select is possible. Like for other command it could be done so that for instance $listbox[0] is the number of selected items and then $listbox[1], etc. are the arrray of selected items. It would surely be apriciated.

Also with the current stdout and stdin. would it be possible to have it so that there would be a simple function for a pipe? Right now as I see it there is not exactly a way to take input from a running comand and send it back to a parent app that calls in the first place. Maybe something like stdpipe()  so that it is just a simple pipe from one app to another. I think in the current form there is no easy way to achive this unless I misunderstand the help file.

Thank you

<{POST_SNAPBACK}>

Hm I'm sorry about this but if there is no solution would somebody say so. At least that would be better. I have asked these questions on other threads my questions go ignored. Thats fine I guess but could somebody just say that cant be done or something and I'll quit asking.

[DaveF]

Hm I'm sorry about this but if there is no solution would somebody say so. At least that would be better. I have asked these questions on other threads my questions go ignored. Thats fine I guess but could somebody just say that cant be done or something and I'll quit asking.

Also with the current stdout and stdin. would it be possible to have it so that there would be a simple function for a pipe? Right now as I see it there is not exactly a way to take input from a running comand and send it back to a parent app that calls in the first place. Maybe something like stdpipe()  so that it is just a simple pipe from one app to another. I think in the current form there is no easy way to achive this unless I misunderstand the help file.

I don't think I understand the question. I'm confused by your use of "a running command" which sounds like you want to get a (output) pipe to a process that's already running at the time that your AutoIt script starts, but then you say "send it back to a parent app that calls in the first place" which kind of sounds like that AutoIt would have started the process with a Run() function. And did you mean to say "take input from" because normally you want the output from a process? I'm just asking for clarification, and example of what you want to do would be really helpful.

[Valik]

try "15O".

I hope I have a working solution. the only side effect will be GuiCtrlSetData will reset any previous setting. That's all I can do due to the fact that CtrlSetData is firing the same event as the typing in the control.

<{POST_SNAPBACK}>

That seems a bit better, JP. I'm now getting the events when I expect. Thanks.

[webmedic]

I don't think I understand the question. I'm confused by your use of "a running command" which sounds like you want to get a (output) pipe to a process that's already running at the time that your AutoIt script starts, but then you say "send it back to a parent app that calls in the first place" which kind of sounds like that AutoIt would have started the process with a Run() function. And did you mean to say "take input from" because normally you want the output from a process? I'm just asking for clarification, and example of what you want to do would be really helpful.

<{POST_SNAPBACK}>

Yes I think i may not be wording it properly. I'm using barts pe and it has a window that is more or less a cmd window that shows the output of everything it is doing. Barts pe when it gets done runs mkisofs.exe which is a console app and then shows the output from mkisofs.exe in it's own window so you an watch what it is doing and also check for errors.

I have created a fake mkisofs.exe that just starts up some scripts. I use the scripts to clean everything up and update virus scanners and such before building the iso. So it gets called like this

barts pe -> mkisofs -> autobuild.cmd

I have it setup so that my mkisofs.exe stays open while the autobuild.cmd is running so that barts pe does not think everything is done. This all works great accept I would like my mkisofs.exe which is only acting as a wrapper for autobuild.cmd to be able to pass output from the autobuild.cmd back to barts pe which is still monitoring mkisofs for any output.

The problem with all this is of course. that the way the current stdout and stdin are written I would have to pass the data back to barts pe by executing it. This I dont want or need. I only need to pass the output from autobuild.cmd back to the app barts pe that is still running and waiting for input from the console app that it thinks is already running.

I hope this is easier to understand. And thanks for asking.

[Josbe]

Limitation or bug?

Using GRAPHICS over Tabs.

Using beta: 3.1.0.15M

Small example:

expandcollapse popup

Global Const $GUI_GR_COLOR = 8
Global Const $GUI_GR_RECT = 10
Global Const $GUI_GR_ELLIPSE= 12

GUICreate("Testing GRAPHICS with Tabs")

$tab= GUICtrlCreateTab(10, 10, 200, 200)

$b1= GUICtrlCreateButton("> Resize tab <", 260, 50, 80)

GUICtrlCreateTabItem("tab0")
GuiCtrlCreateGraphic(30, 60, 20, 20)
GUICtrlSetGraphic(-1, $GUI_GR_COLOR, 0x55, 0xffffff)
GUICtrlSetGraphic(-1, $GUI_GR_RECT, 0, 0, 10, 10)
GUICtrlSetGraphic(-1, $GUI_GR_COLOR, 0x55, 0x55ccff)
GUICtrlSetGraphic(-1, $GUI_GR_ELLIPSE, 10, 10, 10, 10)
$b2= GUICtrlCreateButton("Button", 30, 100)

GUICtrlCreateTabItem("tab1")

GUISetState()

$bool = 0
While 1
    $msg = GUIGetMsg()
    If $msg = -3 Then Exit

    If $msg = $b1 Then
        $bool = NOT $bool; toggle (resize the height)
        If $bool then
            $h = 25
        Else
            $h = 200
        EndIf
        GUICtrlSetPos($tab, 10, 10, 200, $h)
    EndIf
Wend

[SvenP]

No, it isn't freeware, but they do have a 21-day trial -- but you work fast, so 21 days should be plenty 

You'll find it here: MindJet (click on the orange 'Free Trial' button on the left).

Dale

<{POST_SNAPBACK}>

Dale,

I downloaded and installed the software (you could have given me the direct link: http://www1.mindjet.de/downloads/mmx5/MMX52-E-344_Pro.exe . That would have saved me the exhaustive registration procedure :-)

My conclusions: The fact that you can open MindManager with GetObject() in VBScript is a FEATURE of VBScript. After some 'deep research' I noticed that the line GetObject("","MindManager.Application") does also FAIL in VBscript, but immediately afterwards it invokes a CoCreateInstance() to the same object.

In 'human' language, this means: VBscript does in fact perform a CreateObject() after GetObject() fails.

My suspicions were confirmed when I closed the MindManager program and started the VBS script again.. how odd: It STARTED the MindManager program again!

That should not happen with GetObject() according to the documentation.

This leaves me with 2 options:

1. Keep the GetObj() in AutoIt as it is. So it will just fail with MindManager.

2. Modify GetObj(), in a way that it will call CreateObj() after failure.

Hmm.. I need some time to think about this.

-Sven

[DaveF]

The problem with all this is of course. that the way the current stdout and stdin are written I would have to pass the data back to barts pe by executing it. This I dont want or need. I only need to pass the output from autobuild.cmd back to the app barts pe that is still running and waiting for input from the console app that it thinks is already running.

You are correct, the STD I/O functionality doesn't give you a way to write to AutoIt's own STDOUT...

Have you tried the ConsoleWrite() function? It's used to write output that SciTE can capture, I don't know if it'll work for BartPE...

[jpm]

Limitation or bug?

Using GRAPHICS over Tabs.

Using beta: 3.1.0.15M

Small example:

I will say limitation because the drawing is working on the GUICreate window not on controls

[DaleHohm]

I downloaded and installed the software (you could have given me the direct link :-)

This leaves me with 2 options:

1. Keep the GetObj() in AutoIt as it is. So it will just fail with MindManager.

2. Modify GetObj(), in a way that it will call CreateObj() after failure.

Hmm.. I need some time to think about this.

-Sven

<{POST_SNAPBACK}>

Um, sorry about the registration process... I would have given you the direct link if I'd thought about it :-)

This IS really strange. I tested VBS GetObject on Excel.Application as well (when Excel was not running) and sure enough, it starts Excel just as you discovered it starts MindManager -- this is certainly not the way thtat MS has it documented.

I found a TechNet article talking about troubles with GetObject and Office applications (Q238610)... as an optimization, Office apps were not registering themselves in the Running Object Table (ROT) until after they lost focus and this caused GetObject to fail with the Operation Unavailable. Perhaps they changed the behaviour or GetObject to cover up this issue somehow?

I really don't understand things at this level, but perhaps MindManager is not registering itself in the ROT as it should be... Do you know of any way to peek at the ROT?

In any case, if this is isolated to my application, then I have a workaround and I'll all set. If it is a more general issue, I am happy to help debug in any way you would like.

Dale