Leaderboard

Impossible.

CaptureIt v1.06 This program designed to capture screenshots. ============ Main Features: ============ Full Screen Capture (display selection support). Window Capture. Selected area capture. Free selection capture. Save captured image in silent mode. Set watermark for captured image. Open captured image in graphic editor. Print captured image. Put captured image to clipboard. Upload captured image (to image hosting services). Share uploaded image on social networks. Capture History. Images format support: PNG GIF JPG - Quality can be set. BMP - Format can be set. Download Page or >Downloads Section [sources for AutoIt 3.3.10.2+ included in the archive] Enjoy! ============ History Version: ============

Well, I was looking on the internet for ways to suspend processes and spent a great deal of time trying to find API commands to do this. I found many thread suspend functions and other things, but not really any process suspend functions. I finally found a process suspend NTAPI function NtSuspendProcess(). To my great distaste I could find absolutely nothing documenting the NTAPI functions, nothing at all. Hours of Googling and i finally found a page that has the NTAPI functions listed. No thanks to Microsoft. :S You would think they would document functions that they took the time to write so that people could actually use them. To save others time, here is a page with the NTAPI functions listed: http://www.metasploit.com/users/opcode/syscalls.html Here is a UDF to call the system API to suspend or resume a process. No more systeminternals 104kb PsSuspend.exe. Func _ProcessSuspend($process) $processid = ProcessExists($process) If $processid Then $ai_Handle = DllCall("kernel32.dll", 'int', 'OpenProcess', 'int', 0x1f0fff, 'int', False, 'int', $processid) $i_sucess = DllCall("ntdll.dll","int","NtSuspendProcess","int",$ai_Handle[0]) DllCall('kernel32.dll', 'ptr', 'CloseHandle', 'ptr', $ai_Handle) If IsArray($i_sucess) Then Return 1 Else SetError(1) Return 0 Endif Else SetError(2) Return 0 Endif EndFunc Func _ProcessResume($process) $processid = ProcessExists($process) If $processid Then $ai_Handle = DllCall("kernel32.dll", 'int', 'OpenProcess', 'int', 0x1f0fff, 'int', False, 'int', $processid) $i_sucess = DllCall("ntdll.dll","int","NtResumeProcess","int",$ai_Handle[0]) DllCall('kernel32.dll', 'ptr', 'CloseHandle', 'ptr', $ai_Handle) If IsArray($i_sucess) Then Return 1 Else SetError(1) Return 0 Endif Else SetError(2) Return 0 Endif EndFunc @The Development Team I think it would be a good idea to add these to the process.au3 include file. You can call the function with the process name or PID _ProcessSuspend("notepad.exe") or _ProcessSuspend(467) The returns are as follows: 0 = Failure 1 = Sucess @error = 1 means that it failed because something errored when calling the dll @error = 2 means that it failed because the process was not found or is not running Sorry i didn't do a standard UDF writeup, didn't have time. If the development team is interested in adding this function i will happily write the standard UDF documentation for it. Important: This function will only run on Windows XP, Windows 2003 and Windows Vista.

aberration, I have added some explanatory remarks to the Help file page explaining the difference. mLipok, Nice to hear. M23

hehe, a funny example is GOOGLE, I was at some point scraping height data from google earth, and was reading around in Google Groups where I saw a Google employee saying to another user wanting the same.... "You should not scrape data !!!" ...which made me laugh out loud, as that was the exact way Google themselfes became Billionaires, by scraping other peoples data. Meaning it's OK when they do it themselfes and become billionaries, but when others want to scrape Google data, then all Hell is loose.

aberration, The only real difference is your use of HotKeys. I usually prefer Accelerators when dealing with GUIs as they are only active when the GUI is active and so do not interfere with other apps. M23

mLipok, If you want this functionality in an AutoIt GUI then I would use accelerator keys like this: #include <GUIConstantsEx.au3> Global $aTab[3] $hGUI = GUICreate("Test", 500, 500) $cTab = GUICtrlCreateTab(10, 10, 480, 200) $aTab[0] = GUICtrlCreateTabItem("Tab 0") $aTab[1] = GUICtrlCreateTabItem("Tab 1") $aTab[2] = GUICtrlCreateTabItem("Tab 2") GUICtrlCreateTabItem("") $cTab_Right = GUICtrlCreateDummy() $cTab_Left = GUICtrlCreateDummy() GUISetState() Global $aAccelKeys[2][2] = [["^{TAB}", $cTab_Right],["^+{TAB}", $cTab_Left]] GUISetAccelerators($aAccelKeys) While 1 Switch GUIGetMsg() Case $GUI_EVENT_CLOSE Exit Case $cTab_Right $iTab = GUICtrlRead($cTab) + 1 If $iTab > (UBound($aTab) - 1) Then $iTab = 0 GUICtrlSetState($aTab[$iTab], $GUI_SHOW) Case $cTab_Left $iTab = GUICtrlRead($cTab) - 1 If $iTab < 0 Then $iTab = UBound($aTab) - 1 GUICtrlSetState($aTab[$iTab], $GUI_SHOW) EndSwitch WEnd M23

Not in a single line probably not, you'd have to enclose it in a multiline If statement. If $XYOptionWidth = 3 Then $SelectedWidth = 1600 $troll = 89 $autoitforum = "I Love you all" EndIf I wouldn't say no because someone may come along with some totally unwieldy code that allows you to do it. But the way I wrote it is much easier to troubleshoot and debug if something was to be wrong in it.

If you know the file is in the same folder as script $sFilePath = @ScriptDir & '\file.reg' Run($sFilePath)

Local $sFileSelectFolder = FileSelectFolder("Select file location", "") If Not @error Then $sFilePath = $sFileSelectFolder & '\file.reg' Exit MsgBox(0, 'File Path', $sFilePath) EndIf ;==> Exit MsgBox(0, 'File Path', 'Error')

Update...

The answer is: those details should be hidden, and the data should be accessed by a function (or several functions). As a general rule with complex data structures, or even simple data structures, the user (you) should not know how the data is stored in memory exactly. It helps to have some idea, but you don't need to know the exact implementation details. This is actually a very common problem, particularly in graphics (think of drawing a graph in a GUI, the y axis is based on the bottom left corner, but coordinates for GUIs are done on the top right). Here's a Matrix class I wrote for someone this morning who wanted to know about template classes and static_assert: template<int R, int C> class Matrix { static_assert( R > 0 && C > 0, "Matrix dimensions must be positive and non-zero." ); private: int* data; public: Matrix( ) { this->data = new int[R * C]; } ~Matrix() { delete this->data; } int& at( int r, int c ) { if ( r >= R || c >= C ) { // The given index is too big for the matrix! throw std::out_of_range( "Index out of matrix bounds" ); } return ( this->data[r * C + c] ); } }; The user does not need to know that I'm actually storing the matrix as a single array, all they know is that each element is an int in memory, and they can get a reference to it using the at() method. I could have stored it as a 2d jagged array, but this wouldn't have made sense from a programming perspective. The same goes for AutoIt, and languages where you don't get classes and structures to help you with this. Look at the "memory" functions I made >here, they are simple, and could easily be done without the wrapping functions, but with the code as it is I left my options open, and could now go back and write a garbage collector or something without changing much of the current code at all. Even something as simple as reading a memory address I made a wrapping function for.

Ignore what this guy said, <snip>, this has nothing to do with multithreading. What you could do is compile as CUI and add first two lines to your script: DllCall("kernel32", "bool", "FreeConsole") DllCall("kernel32", "bool", "AttachConsole", "dword", -1) ; ...The rest of your code... That way you have "waiting" effect if run from cmd, and no console if run by double-click. However, you'll have initial console flash in latter case, so if that doesn't satisfy you seek alternatives.

MariusN, I have come across a number of occasions when a Dummy control was useful: - 1. When using an Accelerator key without a corresponding control. You need a control to link to the Accelerator key, so if you do not have one (or do not want to use an existing one) you can use a Dummy. - 2. To fire a function from within a Windows message handler. You should return from a handler ASAP - by using GUICtrlSendToDummy you can exit quickly and get the Dummy control to fire with a specific value depending on the result. - 3. It is often useful to know the range of ControlIDs used by ListViewItems where you do not need to use variables to store each one. A Dummy control before and after the creation of the ListViewItems will do this for you. And there are doubtless many more.... M23