Jump to content

Recommended Posts

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?

Link to post
Share on other sites

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.

Link to post
Share on other sites

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!

Link to post
Share on other sites

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. :whistle:

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.
Link to post
Share on other sites

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 by Bartokv
Link to post
Share on other sites

while loop should be more consistent.

:whistle:

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.)
Link to post
Share on other sites

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.

Link to post
Share on other sites

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. :whistle:

Link to post
Share on other sites

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 by CyberSlug
Use Mozilla | Take a look at My Disorganized AutoIt stuff | Very very old: AutoBuilder 11 Jan 2005 prototype I need to update my sig!
Link to post
Share on other sites

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) :whistle:

Link to post
Share on other sites

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.

Link to post
Share on other sites

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. :whistle:

...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.

Link to post
Share on other sites

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
Use Mozilla | Take a look at My Disorganized AutoIt stuff | Very very old: AutoBuilder 11 Jan 2005 prototype I need to update my sig!
Link to post
Share on other sites

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.

Link to post
Share on other sites

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?
Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...