Hide New Windows

[Bartokv]

Just curious if anybody knows how to open any of the control panel applets (@SystemDir\*.cpl) within a hidden window by default.

The Run() function appears to require these files to be launched via "control.exe" or "rundll32.exe", but I can't seem to hide the resulting window:

Run(@SystemDir & "\control.exe " & @SystemDir & "\sysdm.cpl", @TempDir, @SW_HIDE)

Run(@SystemDir & "\rundll32.exe " & @SystemDir & "\shell32.dll,Control_RunDLL " & @SystemDir & "\sysdm.cpl", @TempDir, @SW_HIDE)

Calling WinShow() afterwards to hide the window works, but the applet window still appears for a brief moment.

Any ideas on what I'm doing wrong?

[Valik]

You are doing nothing wrong. It's just the way things work with that program. The window that is being created isn't getting the SW_HIDE notification becaues that window is being spawned by another program which isn't passing that information along. The only solution is to do what you are doing and manually hide it.

[Jon]

Having a tiny waitwait delay may help:

AutoItSetOption("WinWaitDelay", 0)

But set it back to a larger value after the hide for reliability.

[Bartokv]

Hmm, I was afraid that it may be due to permissions on child/forked processes...

Thanks for the verification.

[Bartokv]

Having a tiny waitwait delay may help:

AutoItSetOption("WinWaitDelay", 0)

But set it back to a larger value after the hide for reliability.

WinWaitDelay did help a little... Now the applet appears for less than a tenth of a second (instead of a full one).

Thanks for the advise!

[Bartokv]

Thanks! I was using WinWait, but it actually seems like your recommendation is a little faster... (Wierd)

Odd, I thought WinWait was essentially the same while not exists type loop.

[Valik]

Thanks!  I was using WinWait, but it actually seems like your recommendation is a little faster...  (Wierd)

Odd, I thought WinWait was essentially the same while not exists type loop.

There is a small delay hard-coded into AutoIt to prevent it from using 100% CPU when performing waitable actions. By using your own loop without a delay, you circumvent the internal one. Normally that would be a bad idea, it will cause 100% PCU usage, however, since you are expecting the window you are waiting on and speed is critical to that part of the script, it is safe enough.

[Bartokv]

Actually, it seems like it's just a role of the dice with the wait states and clock cycles:

$SysTitle = "System Properties"

Sleep(250)
$test1 = TimerStart()
  AutoItSetOption("WinWaitDelay",0)
  Run("control sysdm.cpl")
  While Not Winexists($SysTitle)
  Wend
  $test1 = TimerStop($test1)

  WinShow($SysTitle,"",@SW_HIDE)

AutoItSetOption("WinWaitDelay", 250)
WinClose($SysTitle)

Sleep(250)
$test2 = TimerStart()
  AutoItSetOption("WinWaitDelay",0)
  Run("control sysdm.cpl")
  WinWait($SysTitle)
  $test2 = TimerStop($test2)

  WinShow($SysTitle,"",@SW_HIDE)

AutoItSetOption("WinWaitDelay", 250)
WinClose($SysTitle)

MsgBox(4096, "Results", "While loop: " & $test1 & @CR & "WinWait:    " & $test2)

EDIT: At least with my tests. Sometimes the while loop is faster, other times WinWait is faster.

Edited February 4, 2004 by Bartokv

[Bartokv]

Sorry Valik, I didn't see your post when I made my previous one.

I was not commenting on your post -- even though the post order makes it appear that I was correcting you.

[Bartokv]

while loop should be more consistent.

The while loop is more consistant, but sometimes the WinWait is faster. It appears that there may also be a short delay within the while functions. (I haven't searched the code to verify this, however.)

[Valik]

Whenever you open a window right after closing it, the second time is usually faster because Windows just accessed it and some of it could still be cached in memory. I would guess its for that reason alone that you get the results you do with your tests.

[Bartokv]

Whenever you open a window right after closing it, the second time is usually faster because Windows just accessed it and some of it could still be cached in memory.  I would guess its for that reason alone that you get the results you do with your tests.

Ah, forgot about system caching.. Good point.

I'm using Larry's while loop recommendation anyway... Was just curious how much faster it really was in comparison to WinWait.

[CyberSlug]

On slower computers (like 300 MHz), Larry's method might not work.

Also on 300 MHz systems, a WinWaitDelay under ~50ms might prevent the window from ever being hidden....

AutoItSetOption("WinWaitDelay",1) ;low!
Run("control sysdm.cpl")
WinWait("System Properties")
WinShow("System Properties","", @SW_HIDE)

sleep(2000)
MsgBox(4096,"","Window should have been hidden.")
WinShow("System Properties","",@SW_SHOW)

Edited February 4, 2004 by CyberSlug

[Bartokv]

On slower computers (like 300 MHz), Larry's method might not work.

Also on 300 MHz systems, a WinWaitDelay under ~50ms might prevent the window from ever being hidden....

Interesting...

Guess I've gotta figure out how to spawn forked processes -- one that launches the applet, and a pre-forked process that hides the window as soon as it appears. (within a reasonable amount of ticks)

[Valik]

Is it so terrible that the window flashes for a moment? It seems silly to me to worry about a second or less worth of visibilty given that the only solution I can think of involves writing your own program to load control panel applets. Even then, I couldn't guarantee you have any control over the initial state of the window for that applet.

A better course may be to determine why you even need to use the system control panel in the first place and find an alternative method for accessing the information you are looking for.

[Bartokv]

Is it so terrible that the window flashes for a moment?

...

A better course may be to determine why you even need to use the system control panel in the first place and find an alternative method for accessing the information you are looking for.

I'm trying to make a script to query computers connected to our network, and automatically patch and/or log any known issues found with each system.

There are different computer brands/types/models on the network, and some issues only apply to a specific system/build. One such issue concerns a user pool of roughly 9,000 IBM Thinkpad series laptops. Of these laptops, a good percentage shipped with a DIMM containing bad diode. This resulted in corrupt heap space, and a sytem report of ~161Mb Total RAM for the affected systems.

With that said, I'm trying to build a script that will check the total physical memory of any system, and report those found with the defective chips.

I've considered using the registry for this check, but I haven't had much luck in decoding the values that found therein. So I decided to cheat a little, and grab the total memory via sysdm.cpl -- only problem is that I can't launch the applet without the resulting window being visible.

The majority of our users have fundemental skills (at best) with the computer, and I don't wish to increase the number of tech support calls because of a window "mysteriously appearing" on their system.

...I know -- in a perfect world, there'd be a database associating each user with the specs of each system/build... But I live in a corporate world, and the people making the decisions aren't exactly the brightest bulbs in the box.

[CyberSlug]

Valik, do know of a way to force all explorer windows to refresh? I'd like to rewrite the following script without needing Folder Options to flash on the screen...

; Toggle Hidden Files in Explorer; tested on Windows XP
; Folder Options is necessary to "refresh" all the windows.....
AutoItSetOption("SendKeyDelay", 0)
AutoItSetOption("WinWaitDelay", 100)

BlockInput(1)

Run("rundll32 shell32.dll,Options_RunDLL") ; Launch Folder Options
WinWaitActive("Folder Options")
WinShow("Folder Options","",@SW_HIDE)

; Read registry key (2=hide,1=show) to determine status of hidden files.
$key = RegRead("HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced", "Hidden") 

; Click appropriate radio button based on the key status.
If Int($key) == 2 Then;click SHOW
    Send("^{TAB}{TAB}{DOWN 10}{SPACE}{TAB 2}{SPACE}")
Else;click HIDE
    Send("^{TAB}{TAB}{DOWN 9}{SPACE}{TAB 2}{SPACE}")
EndIf

[Valik]

As Larry said, hopefully AutoIt will have a memory function within the next couple days. It's written, sitting on a hard drive waiting on a processor and motherboard to go with it so I can get at it (Scheduled to arrive Thursday).

CyberSlug, in C++ I do, however, I don't know of a way to do it in Au3 other than what you already are.

[Valik]

Did you try EnvUpdate... I will test...

How does EnvUpdate work? Is there an equivalent API command it calls or something? I've never taken a look at it or used it. Does it use WM_SETTINGCHANGE or SHChangeNotify?

[Valik]

EnvUpdate() uses BroadcastMessage or som crap... wait... lemme go look at an AutXtra exerpt...

static  PULONG  aResult;
memset(&aResult,0,sizeof(aResult));

if(SendMessageTimeout(HWND_BROADCAST,WM_SETTINGCHANGE,0,(LPARAM)"Environment",SMTO_BLOCK,15000,aResult)==0)

there is a snipit of how it is done... EDIT: (in LCC ansi-C)

I thought maybe it used WM_SETTINCHANGE. I think calling SHChangeNotify with... ahh crap, I can't remember what flag. Some FILEASSOCCHANGE or something along those lines, anyway, I think that might cause explorer to refresh itself. Maybe AutoIt should also do that in EnvUpdate or have a seperate function to do it? Thoughts?