
ako673de
Active Members-
Posts
29 -
Joined
-
Last visited
Everything posted by ako673de
-
Hidden IE-Window becomes unhidden with certain URLs
ako673de replied to ako673de's topic in AutoIt General Help and Support
Argh!!! I just accidently deleted my last post, so don't wonder if the following text reads some kind of different: As announced I wrote my own code to keep IEs hidden - well, at least as good as possible: The essential idea is that windows at least appear to be hidden, if they are not visible. So I move hidden IEs to the lower right screen corner. This property can then later be used to identify IEs that should be hidden (but maybe no longer are). My function _IEMultipleLoadWait() does exactly this and it then automatically rehides the auto-unhiding IEs (which are already not visible but still reappear in the task bar). While typing I thought that I could also boost this function a little bit: Because what the original _IELoadWait() is lacking of, is the possibility to handle more than one IE at a time (which however could be very useful for saving time if more than one page has to be loaded). My function therefore can wait for many IEs! And it can be interrupted by external events, which is another thing the original function is lacking of. BTW: I'm still using _IEAction("invisible") because the latter is thousands of times faster than WinSetState and it works. ; Same as _IECreate() except that hidden IE is moved to lower right screen corner Func __IECreate($Url="about:blank",$attach=0,$visible=1,$wait=1,$focus=1) $oIE=_IECreate($Url,$attach,$visible,$wait,$focus) If $visible=0 Then _IEPropertySet($oIE,"left",@DesktopWidth-1) _IEPropertySet($oIE,"top",@DesktopHeight-1) EndIf Return $oIE EndFunc ; Wait for multiple IE windows to complete or timeout. If $Abort becomes TRUE (possible only due to an Event!!!) it returns -1, else the bit coded completion state of all IEs Func __IEMultipleLoadWait($oIEarr,ByRef $Abort) $cntIE=UBound($oIEarr) Dim $hidden[$cntIE] For $i=0 To $cntIE-1 $hidden[$i]=(_IEPropertyGet($oIEarr[$i],"left")==@DesktopWidth-1) Next $completeMax=2^$cntIE-1 $complete=0 $tstart=TimerInit() While TimerDiff($tstart)<$__IELoadWaitTimeout And $complete<>$completeMax ; Wait until timeout, all browsers complete or Exit requested If $Abort Then Return -1 For $i=0 To $cntIE-1 If $hidden[$i] Then _IEAction($oIEarr[$i],"invisible") If String($oIEarr[$i].readyState)="complete" Or $oIEarr[$i].readyState=4 Then $complete=BitOR($complete,2^$i) Next Sleep(100) WEnd Return $complete EndFunc However, if anybody comes across a registry hack to disable this IE8 behaviour I would strongly appreciate if you let me know. It is still a bit annoying to see the taskbar moving left and quickly back right when IEs unhide... -
Having the tray menu open always pauses the script
ako673de replied to ako673de's topic in AutoIt General Help and Support
I have an update to report! My script now worked for several months and I didn't notice any problems, well, except of some "spurious" once in a while. Wasn't easy to find, but I just figured it out: Everything works like a charm, if always the regular program is running when clicking the tray icon. Timer routines are normally not so time consuming and therefore this case is highly probable. In case of your "consolewrite("x")"-sample script the probability of clicking the tray icon while the "x" is being written to the console is <1ms/500ms (<0.2%!). But if you really are so unlucky to click the tray icon while the timer routine is still executing, then the timer routine will be stopped and later timer events will also not get processed - until you release the tray icon. This behaviour is a little bit in contrast to the opinion we all had (=that the callback timer is a separate thread itself), isn't it? Can anybody explain this behaviour? How could the timer callback interact with the main Autoit thread in such way? Shouldn't it just use the code from the AutoIt-script and nothing else? -
Hidden IE-Window becomes unhidden with certain URLs
ako673de replied to ako673de's topic in AutoIt General Help and Support
_IEAction(...,"invisible") does it's work, even if the page is still loading. What I wrote was that while the page is loading this command CANNOT work because it does not know when during loading IE decides to unhide its window, and that's no other for WinSetState. The only temporary workaround would be to completely rewrite the _IENavigate-UDF to continuously rehide while waiting (for load complete or timeout). However you would still be annoyed about IE spuriously popping up and back down (=flashing). I think the only chance to overcome this issue is to tweak some IE8 setting (which for sure is some security related thingy) to stop it from unhiding, but I don't know which one. Putting the problem sites to "trusted sites" did not work... -
Hidden IE-Window becomes unhidden with certain URLs
ako673de replied to ako673de's topic in AutoIt General Help and Support
I just gave it a try and here is what I experienced: 1) What you suggest does not work (any other or better), if _IEcreate is called with "hidden" option turned on (before WinSetState(...,@SW_HIDE)-ing it). 2) If I run _IEcreate in normal mode, then what you suggest works (at least sort of, because a flashing IE window is not very beautiful to see). But here it becomes strange: The IE still does not stay hidden forever! As far as I can see, it seems to depend somehow on user interaction with Windows itself, e.g. bringing certain windows to focus or foreground, or the like. At least it does not always happen after a fixed number of "_IENavigates" (to always the same site by the way!). Conclusion: IE8 window still cannot be kept hidden under all circumstances. Other ideas? ako673de -
I create an empty ("about:blank") IE window with _IEcreate and force it to be hidden. So far it works. Then I navigate to other URLs and especially with URLs of the form "192.168.xxx.xxx" suddenly the hidden IE window returns visible. I already read similar comments, which talk about new security policies in Vista, that cause new browser instances to pop up if security zone changes while browsing, but I don't have Vista, just XP, and I confirmed that now new browser instance is being created, just the exisitng one will unhide. I also tried to rehide it with _IEAction(...,"invisible") but that does not work until the URL loaded completely (because the unhiding process seems to take place somewhere in between the loading of a qualifying page), which is a too long time for my application. I'm using IE8. Any ideas how to avoid this behaviour? Pls forget about those 5 ones given in the Autoit help regarding the "new instance" issue, I tried them all and none have any effect on my issue. regards ako673de
-
How do you disable: "^" "!" "#" "F4" etc..
ako673de replied to schilbiz's topic in AutoIt General Help and Support
There are many more or less good explanations out there in this forum, but I know that all this mess with characters, keys and so is a bit puzzling. Ok, one more try, hopefully now clear for everyone reading it: The characters "+","!","^" and "#" (the modifier characters as described with the Send command) can't be HotKeySet-ted directly. The bracket notation workaround described with the Send command ("{+}","{!}","{^}","{#}") simply does not work with HotKeySet (although it should! Look at the help page of HotKeySet - first line in the "Parameters" box: The text in bold can't be misunderstood, I think)! For example try HotKeySet("{+}","function") func function() consolewrite("x") endfunc and you will see an x on the console each time you press "SHIFT" and "=" (which is the "+" on an english keyboard!). Here on my german keyboard however the "+" is located left of the return key and no modifier is needed for it. So without working bracket notation I'm stuck... This thread is not the only one about this topic. Most of the others have been locked by some admin with the final comment that the issue will be (was!) fixed with the next BETA of AutoIt which should have been 3.2.11.0. I tried yesterday but found out that obviously nothing happened... -
How do you disable: "^" "!" "#" "F4" etc..
ako673de replied to schilbiz's topic in AutoIt General Help and Support
Fact is that all modifier keys can't be addressed as characters in HotKeySet. The notation as described in the Send command ("{+}","{!}","{^}","{#}") simply does not work with HotKeySet! This bug (I repeat it is one!) becomes critical, if a not working character is the PRIMARY function of a key. If it is just a SECONDARY function then you can address it via a SHIFT/CTRL/ALT+(working!)key combination (e.g. on an english keyboard you can address the "plus" by using "+2" (=SHIFT+2, because here the "plus" sign is a SECONDARY function of "2", which is addressable). But most probably you know that by now. New is that the bug obviously has not been addressed in the latest BETA v3.2.11.1! Any comments on this?!? -
The windows default setting for the duration tooltips are being shown is 5000ms. For my application this is way too short. I would prefer at least 1 minute or - even better - endless, so that the reader has time enough to read, re-read and understand - without permanently needing to move the mouse to re-show a tooltip. - GUICtrlSetTip has no parameter at all to control the display duration. - The "_GUIToolTip_*" functions offer such parameter but so far all my efforts to show a tooltip with these funtions (on Input, Edit, Button (or the like) controls) failed. I can't find any help about this set of functions, just two examples about the usage with ToolBars and ListViews. I used these examples to check if the function "_GUIToolTip_SetDelayTime" at least fulfills what it promises to do, and I can say that for me this function does not work at all: "_GUIToolTip_GetDelayTime" always returns the default regardless what parameter is given to "_GUIToolTip_SetDelayTime" before. But maybe I'm just confusing all the handles these functions require... Can anybody help (with a short sample script that shows a tooltip on a button for more than 5s)?
-
Having the tray menu open always pauses the script
ako673de replied to ako673de's topic in AutoIt General Help and Support
Rework complete. Works like a charm, even better than expected! Memory usage of the ONE process is at 1.4MB while the solution with two script processes (by Saunders) took 7+9MB (someone knows where this difference might come from? I'm not aware of any larger changes in variable count...). Furthermore the process does not use any noticable cpu time. The two-process-solution once in a while had load peaks up to 4% (each second, which equals the sleep timer used). -
Having the tray menu open always pauses the script
ako673de replied to ako673de's topic in AutoIt General Help and Support
I must admit that I didn't run your code (because I can't from where I am currently). So my first guess was just that the event code is part of the script, and what I know about that is, that it does not work. But now I think I got your idea!!! You assume, that the timer function of USER32.DLL already IS a separate thread (which does not depend on the run state of my script but just uses some part of it's code), right? That is a so far better solution!!! Thank you. I will give it a try as soon as I can. -
Having the tray menu open always pauses the script
ako673de replied to ako673de's topic in AutoIt General Help and Support
I don't exactly understand what you're trying to show me. As far as I understand your code, the big difference is that the periodic task is "event-ized". But that does not solve anything, because the problem still persists, that, if you right click on the tray icon, a menu will pop up, and while it is showing the script is on halt - COMPLETELY! That also concerns event functions because these are also just part of the script. What I was asking for is an event solution for the "multi-process" example by Saunders. His solution works by sending messages over the script internal AutoIt window, but the controls in this window can't be made event-able (because they are not accessible by the GUICtrlSetOnEvent() function) - well, at least after all of MY investigations... -
I just read the following FAQ topic: Q17. Why doesn't my combobox (GUICtrlCreateCombo) show a dropdown list when clicked? A1. When using GUICtrlCreateCombo be sure to enter the desired height for your combobox list in the "height" parameter. Windows XP automatically selects an appropriate height for combo boxes, but other versions of Windows usually do not. CODE: AutoIt$combo = GUICtrlCreateCombo("",10,10,200,20) would be correctly changed to CODE: AutoIt$combo = GUICtrlCreateCombo("",10,10,200,200) One question: The height obviously depends on the number of list entries AND on the font used, but are there other things (frame border, margin from border to active text, ...) to take into account? Is there an easy way to do the same calculation (WinXP does automatically) inside my script?
-
Having the tray menu open always pauses the script
ako673de replied to ako673de's topic in AutoIt General Help and Support
WOW! That is great. So many commands I didn't even know that they exist (AutoItSetWinTitle, $cmdline, ...). Thank you very much for this. I just built a slightly modified version of it into my script and can confirm, that the concept works! Just one problem remains: Your example uses polling in the process where pausing is inacceptable to receive messages from the pausable process. Unfortunately, as I mentioned, in my application the main loop is VERY timing critical. It must use as less cpu power as possible ("sleep()" period > 5sec) WHILE not reacting too slow on tray-clicks (handled by the other process). Is there a way to let the processes communicate in a way that events (=interrupts) are being generated in the message receiving process? -
Having the tray menu open always pauses the script
ako673de replied to ako673de's topic in AutoIt General Help and Support
@FreeFry: What exactly do you mean with "create my own tray items"? My sample script (in my opinion) ONLY uses "own tray items". Are we talking about the same ? Or did you miss my Edit to the last post? @Saunders: A limitation of the program? Man, that is quite some limitation !!! My script needs the ability to have a tray icon. And it needs to run ALL THE TIME. Any idea how to still enable me to use AutoIt? You say the same problem is for GUIs. Oh my god! Solution for this? Not use GUIs any more? Recently I wrote an "Active" MsgBox() routine. The only intention for me to write it was to have a MsgBox() that does not pause the running program (can be polled in a loop that performs periodic tasks). It is and was mandatory for me to have such. Now you tell me, that the user still can unintentionally pause these periodic tasks by clicking on certain boxes in my MsgBox GUI? Now that I know about this "limitation" it took only a few clicks to crash my script and I have no idea how to avoid it. 4 months of work are in vain, because that makes AutoIt completely useless for my project . What exactly is the reason for these limitations? None of the programs I know of have such limitations. Isn't the window and tray system completely event based? Does AutoIt use other methods to implement this? Why??? -
Having the tray menu open always pauses the script
ako673de replied to ako673de's topic in AutoIt General Help and Support
Happens in all modes. If the box containing the tray items (like "exit" and "pause" in default mode) is beeing displayed the script is on halt, regardless of any AutoIt option (I am aware of). Please explain why you think that such behaviour is not a bug. Imagine the following: - The script is designed to wait for e.g. a notification window to appear - Now the user presses the right mouse button over the tray icon to just look what is behind - in the meantime the notification window appears and then disappears - the user has seen what he wanted to see and clicks somewhere on the desktop to remove the tray menu - the program continues running but the event is missed and so it is lost in an endless waiting loop Do you really think this is acceptable?!? Disabling the tray menu completely is currently the only solution to avoid such misbehaviour. Here is a sample script (it uses "ConsoleWrite" to show you when the script is running and when not): #include <GUIConstants.au3> #NoTrayIcon Opt("TrayOnEventMode" ,1) Opt("TrayMenuMode" ,1) Opt("TrayAutoPause" ,0) TraySetOnEvent($TRAY_EVENT_PRIMARYDOUBLE,"TR_Event_Configure") TrayCreateItem("Configure",-1) TrayItemSetOnEvent(-1,"TR_Event_Configure") TrayCreateItem("Stop record",-1) TrayItemSetOnEvent(-1,"TR_Event_Stop") TrayCreateItem("",-1) TrayCreateItem("Exit",-1) TrayItemSetOnEvent(-1,"TR_Event_Exit") TraySetState() while 1 ConsoleWrite("x") Sleep(500) WEnd Func TR_Event_Stop() MsgBox(0,"Info","Stop clicked") EndFunc Func TR_Event_Exit() MsgBox(0,"Info","Exit clicked") Exit EndFunc Func TR_Event_Configure() MsgBox(0,"Info","Configure clicked") EndFunc -
OK, no problem. In the code attached I have reduced my script to the essential parts. The most important line is marked with a capital letter comment. After starting the script do the following to see the effect most clearly: - enter an alphanumeric string in one of the input fields - leave this field with TAB - notice the update (stringformat() inside the event handler) to a two digit number - press the "create" button - again enter an alphanumeric string in one of the input fields - again leave it with TAB - notice that no update will take place (the "change" event obviously does not occur!) - continue entering anything in any field and notice that from now on the update always works properly... ... but only until next "create", because then another "SetBKColor" is being executed. The strange thing is, that the very first time everything is fine. The bad behaviour only occurs, if after a "SetBkColor" (and only on a button!) another GUI (or as in my sample script: the same GUI) is been drawn. #include <GUIConstants.au3> #Include <Array.au3> Opt("TrayAutoPause" ,0) Opt("GUIOnEventMode" ,1) Global $GUI,$Chan,$DStart,$TStart,$Create,$BtnPath $num=2 $oldnum=1 while 1 If Not ($num=$oldnum) Then showGUI($num) $oldnum=$num EndIf Sleep(500) WEnd Func showGUI($num) $GUI = GUICreate("DVB Recording Scheduler",731,226,-1,-1,$WS_SYSMENU) GUISetOnEvent($GUI_EVENT_CLOSE,"GUI_Event_Cancel") Dim $Chan[$num],$DStart[$num],$TStart[$num] For $i=0 To $num-1 GUICtrlCreateGroup("",10,20+30*$i,705,35) $DStart[$i] = GUICtrlCreateInput("",310,30+30*$i,60,21,$ES_CENTER) GUICtrlSetOnEvent(-1,"GUI_Event_Dstart") $TStart[$i] = GUICtrlCreateInput("",370,30+30*$i,35,21,$ES_CENTER) GUICtrlSetOnEvent(-1,"GUI_Event_Tstart") GUICtrlCreateGroup("",-99,-99,1,1) Next GUICtrlCreateGroup("", 10,20+30*$num,705,35) $Create = GUICtrlCreateButton("Create", 655,30+30*$num,50,21) GUICtrlSetOnEvent(-1,"GUI_Event_Create") GUICtrlSetState(-1,$GUI_FOCUS+$GUI_DEFBUTTON) GUICtrlCreateGroup("",-99,-99,1,1) GUICtrlSetBkColor($Create,0xff0000) ; LEAVE THIS LINE OUT => WORKS!!! GUISetState(@SW_SHOW) EndFunc Func GUI_Event_Dstart() $entry=_ArraySearch($DStart,@GUI_CtrlId,0,0,0,0) GUICtrlSetData($DStart[$entry],StringFormat("%02d",GUICtrlRead($DStart[$entry]))) EndFunc Func GUI_Event_Tstart() $entry=_ArraySearch($TStart,@GUI_CtrlId,0,0,0,0) GUICtrlSetData($TStart[$entry],StringFormat("%02d",GUICtrlRead($TStart[$entry]))) EndFunc Func GUI_Event_Create() $num+=1 EndFunc Func GUI_Event_Cancel() Exit EndFunc
-
Activating a script's tray menu seems to be enough to pause execution of it This happens not only in the default mode (Opt("TrayAutoPause",1), but also, where none of the regular tray items (pause/exit) is present. Not to be misunderstood, I know that with "Opt("TrayAutoPause",0)" klicking right on the autoit tray menu normally shows a box that contains 2 tray items (pause/exit), and that pause - when clicked - will pause the script. What I want to say is, that the script even pauses if just this box is being displayed! The whole program is waiting! I don't know why it should do so, isn't that what only the "pause" item should do - after being clicked??? I think it's easy to imagine applications where it is mandatory that a program keeps running all the time (e.g. because it has to processes timing critical operations) but at least, if really needed to have a "pause" functionality, it shouldn't be so easy (just one click) to unintentionally activate it. So in my opinion this is a show stopping bug for the use of AutoIt. However for some reason I'm not allowed to post in the bug forum so I hope for a solution (or workaround) from this forum. AKo
-
Make a GUI with at least two input controls and one button. Set OnEventMode to 1 and create event-handler functions for the input controls. Then set the background colour of the button (doesn't matter which), and then try to press the "TAB" key to switch between the inputs. You will notice, that the first time you press TAB does not generate a "change" event on any input field, but all later TABs continue to work normally. Notice that only TAB is missed once after setting a button's background colour, hitting return or klicking in another control always works as expected (does not miss any "change" event). In my opinion this is a bug. However by some reason I'm not allowed to post in the bug forum... AKo
-
How do you disable: "^" "!" "#" "F4" etc..
ako673de replied to schilbiz's topic in AutoIt General Help and Support
I have noticed, that 6 regular keys are not redirectable via HotKeySet. These are "{", "}", "+", "#", "!", "^" and that obviously has to do with their usage as "SpecialKeys" to indicate "Shift", "Ctrl", "Alt" and "Win". The AutoIt help however states that they should be accessible via "bracketing" (e.g. "{!}" for "!") just like it works for the "Send()" function. I'm not completely sure, but to me it seems that we found a bug in AutoIt, especially because some of these keys still can be accessed by using special keys ("!" can be accessed by "+1", "{" can be accessed by "!^+(", "{" can be accessed by "!^+="). Of course this has an untolerable side-effect: It makes the function depending on the keyboard-layout. But I think the more important information is, that most probably it is not a system restriction we are talking about. Can anybody comment on this? If I'm right, is it possible, that the native HotKeySet-function of WinAPI works better? If so, how can I use that (I'm not so familiar with the calling scheme of this WinAPI function - especially with it's parameters like "virtual key codes" or so). -
The problem, again, is not that the autoit-script may not be able to determine which drive it can use. The problem is, that AFTER the script finished and has subst-ed to a certain drive some NT internal drive creating procedure may come along and redefine that drive letter! The result is that under certain circumstances you won't be able to access any ressources under that drive letter and in certain cases this can only be resolved with a reboot (without subst). Again to make sure: This problem has nothing to do with a script, it has to do with SUBST itself, because SUBST is not a well integrated function on NT based systems. It is some relict from DOS, and you know how "good" DOS programs run on NT, XP or the kind...
-
Actually the problem affects all NT based OSses. I personally have XP SP2. People not having this type of problem have Win 98SE or older or maybe Linux...
-
You don't understand my comment. It is not that I don't know how to permanently bind a virtual drive in an NT system. The problem is, that such virtual drives collide internally with network drives, memory card drives and most probably more system mounted drives. Try to e.g. mount a virtual drive as D: and then connect a USB drive. In many cases this drive will be mounted (by NT) as drive D:, too. This is simply because NT does not know about the presence of a subst-ed drive. The workaround (remapping the USB-drive letter again and again) can be QUITE annoying! And in case of a memory card device it is even more annoying. On my laptop the drive letter of the memory card is fixed to D: and if the collision with a subst-ed drive occurs even unmounting the subst-ed drive letter does not show the memory card drive (until reboot). OK, you may say, put the subst-ed drive letter to something else than D:. Well, right, that helps - sometimes -, but don't you think that some kind of "bad smell" remains? best regards AKo
-
Hi, something off topic: subst soes not work quite ggod on NT based systems. Even ntsubst, which is reported to be a clone working better on NT systems, shows things like: - Network shares connected as drives overwrite drives created by xxsubst - removable media like memory card slots overwrite xxsubst drives Does anybody know a well supported way to create virtual drives on NT systems?
-
I want to disable the menu bar and all controls of the window of an external application. Afterwards I want to re-enable a few really needed ones. Is there a simple way to get a list of all controls of a window (similar to FileFindFirst()/FileFindNext()) so I can simply loop through all controls and disable them? Is there any way to control the menu bar of an external application, like hiding/disabling it completely or disabling only selected menu entries? Currently my only idea is to disable the whole window and build a GUI for the needed controls that exactly overlays the external window, and let it forward user inputs to the controls of the disabled window. But to me this approach seems to be a little bit too inconvenient. Any ideas, preferrably of low programming effort and as general as possible?