pdaughe

I generally tend to stay away from threads that may become "inflamatory", but the subject matter of this thread is a fundamentally important one. I read Valik's response and although he sets diplomacy aside, if you think about the points he made, viewed from my 30+ years of dealing with programming languages and operating systems, he is spot-on, 100% spot on. My (prehistoric) background is primarily in mainframe programming and what you would have to experience (and suffer the consequences of) is a reluctancy to make changes just because it may require minor maintenance changes to existing programs. Progress waits upon change. What is important, critically important, is that changes are documented and here the developer's of AutoIt shine, not as a matter of opinion, but as a matter of fact. Not only are changes fully documented in the release notes, but script-breaking changes are clearly identified. I won't give examples of other providers where changes are not documented because if you've worked in this field for any appreciable amount of time, you've already encountered that. While I can relate to your frustration, you do have to take personal responsibility to review the release notes and change logs. It's just part of our job as developers.

I tried it for you also -- running lastest beta and it immediately crashes on restore. Regarding the positioning of the progress bar after restore: I have an application which also uses an embedded progress bar in the status bar. I tried minimizing the window while the progress bar is showing and although it does NOT crash the application, the progress bar no longer displays. I am using option 3 (center vertically and horizontally), but that did not change the behavior of your test script. My application show/hides the progress bar; it seems problems only occur if the window is minimized while the progress bar is showing.

Well, well...not the first time I've been impressed with you, and I'm sure it won't be the last! Thank you again for your help and all the time you put in on AutoIt. I'll be anxious to implement it when the fix becomes available. This functionality is a nice addition to AutoIt. Sincerely, Paul

Would someone else please compile and test the script below (beta required) and see if it fails? Please post -- thanks. Valik, After posting the previous reply, I thought to try one more thing: compile the test program. Oh my gosh -- after two full days, I FINALLY duplicated the problem. The reason it was so difficult to duplicate is that I was running all my tests under SciTE -- the problem only occurs if it is compiled (Update: the problem can and does occur under SciTe -- it's just harder to get it to occur. It seems to happen within the first two or three seconds, or not at all. It's more easily experienced when compiled). Here's the script that fails every time (update: strike "every time" -- strangely, "sometimes" the exe starts running and runs successfully -- other times if fails very quickly) for me: #include <GuiConstants.au3> #include <WindowsConstants.au3> #include <Constants.au3> AutoItSetOption ("GUIOnEventMode", 1);Enable event-driven processing Local $Main_Window = GUICreate ("Application Window") GUISetOnEvent ($GUI_EVENT_MOUSEMOVE, "Mouse_Move", $Main_Window) GUISetOnEvent ($GUI_EVENT_Close, "Termination", $Main_Window) Local $Main_Menu = GUICreate ("Main Menu", 200, 200, -1, -1, $WS_POPUP, -1, $Main_Window) GUISetBkColor ($Color_Red) GUISetState (@SW_SHOW, $Main_Window) GUISetState (@SW_SHOWNA, $Main_Menu) AdlibRegister ("Test01", 10) AdlibRegister ("Test02", 10) Global $Test01_Active = True While True Sleep (60000) WEnd Func Termination () Exit EndFunc ;=================================================================================+ ; Test01 | ;=================================================================================+ Func Test01 () ConsoleWrite (@HOUR & ":" & @MIN & ":" & @SEC & "." & @MSEC & ": Test01 Function begins..." & @CRLF) ;;ConsoleWrite (@HOUR & ":" & @MIN & ":" & @SEC & "." & @MSEC & ": Test01 Function ends" & @CRLF) ;;Return Local $Window_Position = WinGetPos ($Main_Menu) For $I = 1 To 50 WinMove ($Main_Menu, "", Default, $Window_Position[1] + 6) Sleep (02) $Window_Position = WinGetPos ($Main_Menu) If $Window_Position[1] >= @DesktopHeight Then $Window_Position[1] = 0 WinSetTrans ($Main_Menu, "", 255) Else WinSetTrans ($Main_Menu, "", 255 - $I) EndIf Next ConsoleWrite (@HOUR & ":" & @MIN & ":" & @SEC & "." & @MSEC & ": Test01 Function ends" & @CRLF) EndFunc ;=================================================================================+ ; Test02 | ;=================================================================================+ Func Test02 () ConsoleWrite (@HOUR & ":" & @MIN & ":" & @SEC & "." & @MSEC & ": Test02 Function begins..." & @CRLF) ConsoleWrite (@HOUR & ":" & @MIN & ":" & @SEC & "." & @MSEC & ": Test02 Function ends" & @CRLF) EndFunc ;=================================================================================+ ; Mouse Move | ;=================================================================================+ Func Mouse_Move () ConsoleWrite (@HOUR & ":" & @MIN & ":" & @SEC & "." & @MSEC & ": Mouse Move" & @CRLF) If $Test01_Active Then AdlibUnRegister ("Test01") $Test01_Active = False Else AdlibRegister ("Test01", 10) $Test01_Active = True EndIf EndFunc

Valik, I didn't want to take up your time until I had made every attempt to duplicate the problem. I have not been able to duplicate it, so yes, I think it will be beneficial to pursure this -- I will follow your instructions... I have discovered the problem occurs in more than one situation in my application. What I have been able to determine is that I call a function which executes an AdlibRegister; the function completes (i.e the last trace message immediately before the EndFunc is written), then the crash occurs. This is not a "rare" occurence; it happens every time, and again, in more than one situation. It's surprising (and frustrating) to me that I cannot duplicate it. I have a couple of aside comments regarding AdlibRegister/UnRegister (these comments do not have anything directly to do with the problem). First here's a version of the script I've been testing with: #include <GuiConstants.au3> #include <WindowsConstants.au3> #include <Constants.au3> AutoItSetOption ("GUIOnEventMode", 1) ;Enable event-driven processing Local $Main_Window = GUICreate ("Application Window") GUISetOnEvent ($GUI_EVENT_MOUSEMOVE, "Mouse_Move", $Main_Window) GUISetOnEvent ($GUI_EVENT_Close, "Termination", $Main_Window) Local $Main_Menu = GUICreate ("Main Menu", 200, 200, -1, -1, $WS_POPUP, -1, $Main_Window) GUISetBkColor ($Color_Red) GUISetState (@SW_SHOW, $Main_Window) GUISetState (@SW_SHOWNA, $Main_Menu) AdlibRegister ("Test01", 10) AdlibRegister ("Test02", 10) While True Sleep (60000) WEnd Func Termination () Exit EndFunc ;=================================================================================+ ; Test01 | ;=================================================================================+ Func Test01 () ConsoleWrite (@HOUR & ":" & @MIN & ":" & @SEC & "." & @MSEC & ": Test01 Function begins..." & @CRLF) ;;ConsoleWrite (@HOUR & ":" & @MIN & ":" & @SEC & "." & @MSEC & ": Test01 Function ends" & @CRLF) ;;Return Local $Window_Position = WinGetPos ($Main_Menu) For $I = 1 To 50 WinMove ($Main_Menu, "", Default, $Window_Position[1] + 6) Sleep (02) $Window_Position = WinGetPos ($Main_Menu) If $Window_Position[1] >= @DesktopHeight Then $Window_Position[1] = 0 WinSetTrans ($Main_Menu, "", 255) Else WinSetTrans ($Main_Menu, "", 255 - $I) EndIf Next ConsoleWrite (@HOUR & ":" & @MIN & ":" & @SEC & "." & @MSEC & ": Test01 Function ends" & @CRLF) EndFunc ;=================================================================================+ ; Test02 | ;=================================================================================+ Func Test02 () ConsoleWrite (@HOUR & ":" & @MIN & ":" & @SEC & "." & @MSEC & ": Test02 Function begins..." & @CRLF) ConsoleWrite (@HOUR & ":" & @MIN & ":" & @SEC & "." & @MSEC & ": Test02 Function ends" & @CRLF) EndFunc ;=================================================================================+ ; Mouse Move | ;=================================================================================+ Func Mouse_Move () ConsoleWrite (@HOUR & ":" & @MIN & ":" & @SEC & "." & @MSEC & ": Mouse Move" & @CRLF) EndFunc 1. Notice that the Test02 function is never executed once the Test01 function starts. It appears that if an AdLibRegister function takes longer to execute than it's scheduled frequency, it will dominate. If you uncomment the first two commented lines in Test01, you see both Test01 and Test02 execute. I'm not suggesting this is a "problem", just noting it for your awareness. 2. It would be "nice" if AdlibUnRegister ("") would unregister all registered Adlib functions. The application can of course keep track of registered functions, but it would be convenient. Thank you for you willingness to help. My e-mail address is: Developer@twmi.rr.com. I live in the United States, Eastern Standard Time. Paul

PSaltyDS -- thanks very much for looking at this. Your simple script is similar to my test script -- except that I AdLibRegister and AdLibUnRegister like crazy! I appreciate your willingness to help. Valik -- FYI I have tested AdLibRegister/UnRegister exhaustively, interrupting driven functions with mouse and hotkey events. AutoIT has performed impeccably so you're right -- there must be something else going on; I'll find it, eventually By the way, the documentation for AdLibRegister could note that the frequency for an already register function can be changed simply by executing another AdLibRegister with the new frequency. That may have been true with the original AdLib function and I just never realized it...

Thanks Valik -- I have tried to replicate it, but I'll pursue this approach as you suggest. By the way, thanks for all the hard work you obviously put in; there were some very nice enhancements in the beta.

Thanks for the reply...the problem is, I can't easily run it in SciTE or in non-compiled form; otherwise I could get the script line where it's failing. I may have to make the necessary changes necessary to run it in non-compiled form, but that's more work than one may think! If I put a trace (log to file) after every line in the failing UDF, it doesn't crash because apparently the timing is different.

I upgraded to the AutoIT 3.3.1.0 beta a few days ago and upgraded to 3.3.1.1 yesterday. Since upgrading to 3.3.1.0 from the production version, I've been attempting to resolve an AutoIT crash that I began encountering after the initial upgrade to 3.3.1.0 (upgrading to 3.3.1.1 made no difference w.r.t. the crash). I'm in kind of a pickle on this one: the application is very large and uses inter-process communications -- I can only run (with any ease) the failing script as an exe, and the crash appears to be related to a timing issue. As I add more traces to the subject functions, the crash becomes difficult to cause. I've tried to duplicate the scenario in smaller, independent scripts, but have not been able to replicate the problem. I'm questioning whether the change introduced to the application from the upgrade may be related to the beta changes in the AdLib function (the application itself is unchanged and never crashed in the production version). What I know for sure is that the crash is happening because a UDF executed via AdLibRegister is interrupted by a UDF initiated due to a mouse move. I realize this behavior is the same as before: a UDF driven by a mouse event could always interrupt a UDF driven by AdLib, but here's a question: Can an AutoIT function itself be interrupted? In my case, the UDF driven by the ADLibRegister executes another ADLibRegister. This UDF is (and should be) interrupted by a UDF driven via a mouse move. Is the ADLibRegister function itself interruptible? The only information I have is from the Windows Event Log -- it shows the application fails at an offset of 4d65a. I don't know if this has any meaning, but I've crashed over 20 times and it is ALWAYS at offset 4d65a). Any tips on how I may debug this one would of course be very much appreciated.

Thanks Dale for testing this. I question, though, the certainty of your conclusion. I do not believe it is due to a change in Windows Mail design itself for three reasons: 1. I have several users running the application under Vista, INCLUDING MYSELF, where the attach always works, as I have stated, under IE7. Admittedly, when IE8 was installed on my Vista machine, I didn't review the other updates to see if updates were applied to Windows Mail as well. However... 2. I have confirmed that if you install IE8 on XP, the example script I supplied demonstrates that _IEAttach no longer works with OutLook Express. It does with IE7. My confirmation ensured the only change was the install of IE8. This should certainly be easy enough for you to verify. 3. Remember, my issue was NOT with Windows Mail or Outlook Express, but a corporate application using an embedded IE server. The corporate application did not change. I think all we can say with certainty is that IE8 functions, for perhaps reasons not presently fully understood, differently as an embedded control than IE7 did. Although most-likey related to security as you suggested, it is definitely not Vista's UIPI as I had suspicioned since the problem does indeed manifest itself on XP with IE8. That is in fact why I suggested Windows Help as an example. Here, for whatever reason, we are able to attach to an EMBEDDED IE, even with IE8. It may be helpful to others to note that existing IE.au3 based applications may fail when IE8 is installed. I was able to provide a (temporary) work-around to IE8 users of my application by using SendMessage to send specific command ids to the embedded IE Server control. However, I haven't found a reliable way to test whether the server is busy or not, without actually doing the attach (the temporary work-around just does a sleep after the SendMessage, and is apparently working fine, but may incurr problems when people log into the application from home). Do you have any suggestions on how to tell if the IE server is busy without doing an attach? There is an activeX control available (vbMHWB.DLL) to "externalize" the methods of the WebBrowser control, which I will be testing today. Do you have any experience with that? Thanks again for your help. Paul

Hi, I installed IE8 and an existing application which uses IE.AU3 (attaching to an embedded IE) now fails. If you are running IE8, could you please run the following script? #include <WindowsConstants.au3> #include <GUIConstantsEx.au3> #include <Constants.au3> #include <IE.au3> AutoItSetOption ('MustDeclareVars', 1);Require explicit variable declaration AutoItSetOption ('WinTitleMatchMode', 2);Match any substring in title Local $Title = StringStripWS (InputBox ("IE Attach Test", "Enter title"), 3) Local $Handle = WinGetHandle ($Title) If Not $Handle Then MsgBox ($MB_ICONEXCLAMATION + $MB_TOPMOST, "IE Attach", $Title & " window not found.") Exit EndIf Local $oIE = _IEAttach ($Title, "Embedded") If @error Then MsgBox ($MB_ICONEXCLAMATION + $MB_TOPMOST, "IE Attach", "Unable to attach to " & $Title) Exit Else MsgBox ($MB_ICONEXCLAMATION + $MB_TOPMOST, "IE Attach", "Successful attach to " & $Title) EndIf $oIE = 0 1. Open the AutoIt Help file, run the script, and type in "AutoIt Help" (case sensitive). The IEAttach should be successful. 2. Open Windows Mail (Vista) or Outlook Express (XP). Show the Preview pane. Run this script, type in "Windows Mail" or "Outlook" and see if the IEAttach is successful. 3. Post your results. Thank you in advance!

Sorry, Dale -- the COM error description is: Access Denied", The requested action with this object has failed, Error code = 2208

Dale, it's exactly as I mentioned in post #20: the statement: $oIE.document.parentwindow is where the COM error occurs. Running under ScitTE, the error handler displays a message box, this is followed by the $_IEStatus_NoMatch return from _IEAttach. Yes, it is ALWAYS the same. I mentioned I haven't tested this yet under XP, and I haven't. But I just received an e-mail from one of the application's users that it is no longer working -- and guess what, that user just clicked on the IE icon this morning and was greeted by the IE8 setup. The user is running Windows XP Pro. That still doesn't confirm, beyond the shawdow of any doubt, that IE8 is indeed the culprit, but that gives me a fairly high-degree of confidence that it is. Based on that user report, if you run the sample I posted on XP with IE8, you should experience the COM error. And, did you observe that behavior with WinTitleMatchMode that I described? I just can't believe there is a problem in AutoIt like that because surely by now it would have been reported, which again, makes me question my setup. I appreciate your attention to this problem. I'm anxious, as any developer naturally is, to find out what's going on here. Paul P.S. By the way, I have to go out with my wife for the next three hours so I won't be on the forum until after that.

As have I. A period is also valid in a folder name. What this implies is that you cannot test to see if a string is a file or folder name simply by looking at it. You have to open it and look at its attributes. I've observed several scripts looking for an extension in a name and then "assuming" it's a file....

Whew -- it took a while to produce a reproducer of the IEAttach problem, but I believe I've done it. #include <WindowsConstants.au3> #include <GUIConstantsEx.au3> #include <Constants.au3> #include <IE.au3> AutoItSetOption ('MustDeclareVars', 1);Require explicit variable declaration AutoItSetOption ('WinTitleMatchMode', 2);Match any substring in title Local $Title = StringStripWS (InputBox ("IE Attach Test", "Enter title"), 3) Local $Handle = WinGetHandle ($Title) If Not $Handle Then MsgBox ($MB_ICONEXCLAMATION + $MB_TOPMOST, "IE Attach", $Title & " window not found.") Exit EndIf Local $oIE = _IEAttach ($Title, "Embedded") If @error Then MsgBox ($MB_ICONEXCLAMATION + $MB_TOPMOST, "IE Attach", "Unable to attach to " & $Title) Exit Else MsgBox ($MB_ICONEXCLAMATION + $MB_TOPMOST, "IE Attach", "Successful attach to " & $Title) EndIf $oIE = 0 1. Open the AutoIt Help file, run this script, and type in "AutoIt Help". The IEAttach should be successful. 2. Open Windows Mail. Show the Preview pane. Run this program, type in "Windows Mail" and the IEAttach may be successful, but for me, almost always gets a COM error, as I described in the earlier post. Again, I suspect IE8, but now that I think about it, other updates were installed along with IE8. I only know that this has worked impeccably for the last several months. The problem was difficult to reproduce because the actual AutoIt application is very large, and attaches to an embedded IE in a proprietary corporate application which no one else would have. I discovered the same problem with Windows Mail simply by trial and error. If I boot from my backup, which does NOT include IE8 and Tuesday's other updates, this script attaches to Windows Mail just fine. Moreover, if you run this script on XP, it attaches to Outlook Express just fine. I have had to struggle (rather significantly) with Vista's UIPI in other arenas, but I don't envision a solution here if it is in fact related to UIPI. I would appreciate it if someone else could test this on their machine. Again, your feedback would be greatly appreciated. Paul P.S. I forgot to add that it makes no difference if the script is compiled and "Run As Adiministrator". The COM error still occurs.