
M4M
Active Members-
Posts
21 -
Joined
-
Last visited
Everything posted by M4M
-
when you do that, doesnt it create a file called "nul" with the text "press any key to continue" in it? a simple fix for then would be to just add: del nul
-
a month ago? it was made about 4 days ago! Oct 30 2006, 08:06 AM
-
How do you check a GUI for a change before closing it?
M4M replied to M4M's topic in AutoIt GUI Help and Support
due to the amount of controls, I figured that would be easier to script in one big IF statement then to have about 15 "$var = GUICtrlRead($control) AND to have them all checked in an IF statement. I.E: IF GUICtrlRead($Checkbox1) = iniread(this.ini,"do","re","me") AND GUICtrlRead($Checkbox2) = iniread(this.ini,"heh","lol","wtf") and ect,ect,ect or is there an easer way to lump all of the controls into one var. so I dont have to have a mile-long IF statement? OR would my origional idea be better (create a temp ini and compare the two)? heh, OR am I just making it way harder then it really is? Please keep in mind, I havent had much time to fully explore autoit, so I am still unfamiliar on how flexable the commands are. -
How do you check a GUI for a change before closing it?
M4M replied to M4M's topic in AutoIt GUI Help and Support
Paulie: is this what you had in mind? If so I am a moron for not seeing it earlier... #include <GUIConstants.au3> $Form1 = GUICreate("AForm1", 361, 207, 193, 112) $Checkbox1 = GUICtrlCreateCheckbox("ACheckbox1", 56, 40, 137, 49) GUICtrlSetState(-1,$GUI_CHECKED) $before = GUICtrlRead($Checkbox1) $Button1 = GUICtrlCreateButton("close", 56, 144, 89, 33, 0) GUISetState(@SW_SHOW) While 1 $Msg = GUIGetMsg() Select Case $Msg = $Button1 $after = GUICtrlRead($Checkbox1) If $before = $after Then msgbox(0,"no change","the checkbox did not change") Exit Else MsgBox(0,"changed","the checkbox changed") Exit EndIf EndSelect WEnd crzftx: heh, that is still a weeeeee bit over my head at this point. I have yet to play with global constraints yet. besides, would that work with a mixture of controls (checkboxes, radio, dropdown lists)? -
How do you check a GUI for a change before closing it?
M4M replied to M4M's topic in AutoIt GUI Help and Support
ummmmm, yea, I did read the help file and seen this also...and from what I understand, this command just checks the current state of the control in question. how can this be used to compare from what the state of a control is to the state of the control when the user tries to close the gui? I.E. when the gui first opens, a checkbox is checked. the user unchecked the checkbox and then closes the gui. how can I script it so the script sees the change made and warns the user of the change before closing the gui? I guess what I am saying is this..... If this is what you would use, how would you use it to detect the change, and not just report the current state of the control? -
I am not all to sure on how to word this but here it goes.... I have a gui that has a few options (about 5 checkboxes, a drop-down list, 2 search fields and 2 radio buttons). How can I script it so that if a change was made and if the user tried to close the gui, A warning would pop-up saying that changes where made...yada, yada, yada.....you get the idea. I know how to script everything else, its just the detection of the changes is what is giving me trouble. Just to let ya know, all the options are saved in an ini file. I had an idea of this: when the user clicks on the close button, have it save the gui to a temp ini file, and have the script look at the temp ini and compare it with the origional ini, and if a different setting was found, it would warn the user, and at the end of it all, have it delete the temp ini file. Would this work? Would there be an easier way?
-
This is what I would suggest....
-
not to sound rude myself, but a simple batch file can do the same thing.... I have several batch files on my desktop that I run on a regular basis: defrag only defrag-n-shutdown force reboot for example I will post em..... Forced reboot..... @ echo off title Force Reboot echo NOTICE! This is a FORCED reboot! echo If your PC is running fine and wish to do echo a normal reboot, then close this window echo and choose restart from the start menu. echo. echo If your PC is acting up and you can't get echo some apps to close in the normal fashion, then echo press any key to force the reboot..... pause > null del null shutdown -r -t 10 -f -c "PC is now being forced to reboot in 10 seconds. This is an intentional reboot." Defrag-n-Shutdown...... @ echo off title: M4M's HD Defrag-N-Shutdown Utility defrag c: -f defrag d: -f shutdown -s -t 05 -c "Hard drive defragmention is complete. PC is now shuting down... Defrag only.... @ echo off title: M4M's HD Defrag Utility defrag c: -f defrag d: -f NOTE: for the defrag ones you might want to change/add/delete the HD letters (c:, d:) to suite your needs. Also, these are used on WinXP Pro. They *might* work if you are using win2k, and WONT work on win9x. Just copy each one in a txt and change the "save as" to "All Files (*.*)" save it as whatever.bat
-
heh, I myself like the "tip of the day"....nice!
-
1: WTF?!?! Not to sound mean or anything...but that pic is WAAAAAYYY to big! it really screws with the forums... 2: If you have scite installed, just save an empty script, then go under tools --> guibuilder or tools-->Koda(formDesigner) and play with those. Using one of those tools makes creating a GUI very, very easy.
-
well, depending on the OS you could just make a seperate user account on the PC and password protect yours, thus eliminating any currrent/future hassles.....
-
heh...It was right in front of me.... Here is an example for those interested.... #include <GUIConstants.au3> #include <array.au3> GUI1() Func GUI1() $Form1 = GUICreate("AForm1", 633, 447, 193, 115) $Combo1 = GUICtrlCreateCombo("ACombo1", 56, 32, 385, 25) $Button1 = GUICtrlCreateButton("Close", 56, 64, 177, 49, 0) $Button2 = GUICtrlCreateButton("Edit", 248, 64, 193, 49, 0) $GameListData = IniReadSectionNames("Setting.ini") If @error Then MsgBox(16,"setting.ini file missing/empty!","Your setting.ini file is missing/empty! One will be created/filled for you for this test") IniWrite("setting.ini","List one","","") IniWrite("setting.ini","List two","","") IniWrite("setting.ini","List three","","") GUI1() EndIf For $i = 1 To $GameListData[0] _ArraySort($GameListData) GUICtrlSetData($Combo1, $GameListData[$i]) Next GUISetState(@SW_SHOW) While 1 $Msg = GUIGetMsg() Select Case $Msg = $GUI_EVENT_CLOSE MsgBox(0,"Deleting ini file","When you close this, the INI file created for this test will be deleted") FileDelete("setting.ini") Exit Case $Msg = $Button2 GUIDelete("AForm1") GUI2() Exit Case $Msg = $Button1 MsgBox(0,"Deleting ini file","When you close this, the INI file created for this test will be deleted") FileDelete("setting.ini") Exit EndSelect WEnd EndFunc ; <--End of GUI1 GUI2() Func GUI2() $Form1 = GUICreate("AForm2", 550, 300, 193, 115) $Combo1 = GUICtrlCreateCombo("ACombo1", 88, 48, 409, 25) $Button1 = GUICtrlCreateButton("Done", 88, 96, 185, 33, 0) $Button2 = GUICtrlCreateButton("Delete", 296, 96, 201, 33, 0) $GameListData = IniReadSectionNames("Setting.ini") For $i = 1 To $GameListData[0] _ArraySort($GameListData) GUICtrlSetData($Combo1, $GameListData[$i]) Next GUISetState(@SW_SHOW) While 1 $Msg = GUIGetMsg() Select Case $Msg = $GUI_EVENT_CLOSE Exit Case $Msg = $Button1 GUIDelete("AForm2") GUI1() Exit Case $Msg = $Button2 $test1 = GUICtrlRead($Combo1) IniDelete("setting.ini",$test1) GUIDelete("Aform2") GUI1() Exit EndSelect WEnd EndFunc ; <--End of GUI2 test.au3
-
lol, yea, I worded it very poorly, and I apologise for that. your idea is good, but deleting the ini file would kinda kill the point for the "app" that I am creating..... and it is more or less a front-end for daemon tools. The ini file would hold such info as: cd image location, daemon tools exe location, ect, ect. ....I kinda wanted to keep my idea under wraps until I was happy with the finished product, but I suppose in order for others to better help me, I need to give up some info, lol. So, now that you know what I am after, let my try to word it a little more properly... Still running from one script... GUI1: Main GUI. User sellect a game from the drop-down list to run, along with buttons such as: run, edit/delete/add game, options, and exit. GUI2: Settings GUI. This GUI gives you the options to add/edit/delete a game from the INI file, sellect where the ISO is located, auto-run screen name, exe file location, ect.. What it currently does: If a person clicks on the add/edit/delete button, the main gui drops to the task bar (will explain why later) and the edit gui opens up. Once the changes are made, and the user clicks on save, the settings are saved to an ini file, then the user needs to click on close (this is done to prevent lose of changes made), and then the options gui closes and the main gui comes back up. Why it works the way it does (main gui dropping to taskbar): I tried closing the main gui, loading the options gui, and when that is closed, the script would return to the top, thus re-launching the main gui. BUT, apon doing this, the script either 1: had an error that I could not find/fix or 2: would not re-load the settings in the settings.ini file.
-
I am working on a script and I am tring to figure out how to re-load a gui. To help explain my problem, here is an example (note, all gui stuff is in one script): begining of script: GUI1 this is the gui that gets loaded first. think of it as a font-end (sellect an option and run it, like notepad.exe, cmd.exe, nero.exe, ect). GUI2 this is a gui that allows you to make/save changes in the ini file that holds settings such as app name, exe location, ect. end of script: How can I script it so that if I make a change in GUI2 (and save it), the changes are immediatly shown in GUI1? I am sure it involves reloading the first gui, but I am not sure how to do it without completely closing out the script and restarting it.
-
lol, it IS your idea. it came to me after testing your drive lock. those were just some ideas I had to improve apon it, if you chose to. the only thing that could cause problems is if you were in the middle of working on something (say writing a report), locked the PC, and someone came along and wanted to use the PC, it would appear that the PC is just locked up (the screen is blank and mouse/keyboard doesnt respond), they would just hit the reset button, thus loosing everything that you were working on. instaid of shutting down the monitor, have some indication on the screen that says the PC is locked. anyway, your welcome to the input, keep up the good work!
-
This script is a very, very good idea, but I have noticed one major flaw. while the system is "locked down", someone could simply hit the reset button and the lock is bypassed. I have come up with a 95% secure method, but it would involve running 3 scripts (it could be done in two, but for ease of explaining I will break it down to 3). The three scripts would be: 1: startup 2: lock 3: config And now let me explain each...... Lock: You are happly computing along and you decide you need to leave your PC, so you run the lock script on your desktop. This will create a random made file on the "key" (it can be a text file, MD5 hash, whatever) and a copy of the information is saved in an ini file. Then when it is ready it will prompt you to remove the "key". When the key is removed, the PC will lock down, and will constantly watch that drive letter for the key to return. When the key is inserted, the script will compare the file with what is in the ini file, and if they match, the PC will unlock, the ini entry deleted and the script will end. If they do not match, nothing will happen. startup: This script will run on PC startup (the best option will be through the registery, NOT the startup folder). when the PC starts up, the script will run, and check the ini file. If there is an entry in there, that will tell the script that the PC was locked but somebody hit reset or shut down and restarted the PC. In this case, the keyboard and mouse will be locked, but the monitor will stay on, and a screen will show up saying "To use this PC, please insert the correct "key" to unlock." When the correct key is inserted, the keyboard and mouse will unlock and the script will end. If the incorrect key is inserted, nothing will happen. If the ini file is empty, that will tell the script that the PC was unlocked when shutdown or restarted and the script will simply end. config: this script will simply save the drive letter that the random file should be saved to (this will be saved into an ini file also). HINT This can be combined with the locking script to check if the drive letter has been set. If so, it will simply go to the locking section of the script. If not, it will have a pop-up asking which drive letter you want to use, save it and then continue with the locking section of the script. Pros: 1: The script will only run when needed, saving CPU time. 2: prevents someone from hitting reset to bypass the lock. 3: The ONLY way around it is to boot into safe mode and prevent the script from running on startup. 4: Being that the key file is randomly generated, there is very, very little chance of it being guessed. 5: If by some chance you loose your key, it can be bypassed by booting into safe mode and disabled (read # 3). Cons: 1: in the end, it would be much easier to just use a password (win2k, XP) and just manually locked it, but the problem here is that passwords can be guessed/found out, while this script always changes and cant be guessed on what it is. Ideas: The script can also keep track of the drive's info (such as brand, freespace, ID # ect, to prevent the key file from being copied. Although, this might be overkill, because if someone got ahold of the key and copied it, well, then you didnt keep good track of your key Please, I do not mean any disrespect, the origional idea is very good, I just thought that these ideas would further improve the strength of your lock. Keep up the good work!