Leaderboard

I've often thought it would be nice to have a @FuncName macro of some sort.

[New Version] - 27 Jan 22 New: The GUIScrollbar_Ex UDF now recognises Win-D and taskbar desktop clearance commands and runs the correct minimize/restore code automatically. The previous UDF _Minimize and _Restore commands have been superceded by a single _EventMonitor function which runs in the script idle loop. This is a script-breaking change, but I hope that the additional functionality is worth the small effort it will take to alter your scripts. New UDFs, examples in zip file below. Previous changes: Changelog.txt Are you bemused by scrollbars? > Do you find them too difficult to use? > Then you need the GUIScrollbars_Ex UDF! Just download the zip at the end of the post and run this short script with the UDF in the same folder. No tricky calculations, no complicated functions to master - just easy to use, accurate scrollbars with one command! [size=5]#include <guiconstantsex.au3> #include "GUIScrollbars_Ex.au3" ; Create GUI with red background $hGUI = GUICreate("Test", 500, 500) GUISetBkColor(0xFF0000, $hGUI) ; Create a 1000x1000 green label GUICtrlCreateLabel("", 0, 0, 1000, 1000) GUICtrlSetBkColor(-1, 0x00FF00) GUISetState() ; Generate scrollbars - Yes, this is all you need to do!!!!!!!!!!!!!!!!!!!! _GUIScrollbars_Generate($hGUI, 1000, 1000) While 1 Switch GUIGetMsg() Case $GUI_EVENT_CLOSE Exit EndSwitch WEnd[/size] Try it today and see how easy it is! I have been trying for some time to understand how scrollbars work and how to get them closely to match the area I want to display. After much research and headscratching I have come up with 2 UDFs which I hope will be of use to others. Apologies for the length of this post, but scrollbars are complex beasts and as I did this mainly for the less experienced user I want to make sure that they understand what is going on. The 2 UDFs are: GUIScrollbars_Ex.au3 - This gives you scrollbars sized to your GUI in one simple command - with no other includes or commands needed. The UDF is designed for those who would not normally use scrollbars because the whole process looks too complicated. It also includes a command to enable you to scroll page by page, thus making it easy to scroll to anywhere on the GUI with only simple calulations based on the values you used to create the GUIs. [New] Ability to have recalculated scrollbars on resizeable GUIs. GUIScrollbars_Size.au3 - This calculates the Page and Max numbers for the user to feed into the _GUIScrollbar_SetScrollInfoPage/Max commands. The UDF is aimed at the more experienced user and is particularly useful when you have a GUI with a dynamic scroll size (i.e. adding or subtracting controls to the scrollable area as the script runs). First, a short tutorial for those who are interested in how the scrollbars affect your GUI and what it is that the UDFs calculate: All the files mentioned here are in a downloadable zip file at the end of the post. GUIScrollbars_Size.au3 As mentioned previously, the GUIScrollbars_Size.au3 UDF is aimed at the more experienced user who wants to use the full range of _GUIScrollbar comands, but would like a quick way of getting the required Page and Max values. It uses no other include files so you will need to include GUIScrollbars.au3 yourself, as well as the necessary GUIRegisterMsg and procedures for WM_VSCROLL and WM_HSCROLL. The syntax is simple - the size of the scrollable GUI and either the handle of the GUI you have created to hold the scrollbars or the size of the one you are going to create. It returns a 6-element array including the Page and Max values for the scrollbars and factors to compensate for the "shrinkage" of the GUI if you had already drawn some controls and wished to add others. Of interest, the returned Max value is biased not to clip the edges of the GUI - reducing it by 1 makes a tighter fit but can lead to some clipping. (If that does not make sense, please see the tutorial above for more details) The Size_Example_1 script to show the UDF in action - the "Pass Size" button shows the effect of creating the scrollbars BEFORE the controls, the "Pass Handle" button shows what happens if the scrollbars are created AFTER the controls. If you do not understand why there is a difference - go and read the tutorial above ! You will need to have the GUIScrollbar_Size.au3 UDF in the same folder. Where this UDF really helps is if you have a scrollable GUI of variable size - if the number of controls varies with user selections for example. All you need to do is to rerun the UDF with the new size of the scrollable GUI and it produces a new Max value for you to use. The Size_Example_2 script shows how the function enables you to dynamically size your scrollbars depending on the number of controls required. As before it requires the GUIScrollbar_Size.au3 UDF in the same folder. -------- Now the "simple" GUIScrollbars_Ex.au3 (which is actually the more complex internally as you would expect). This UDF is intended to be the single point of call for creating scrollbars on a GUI - it will automatically add the GUIScrollbars UDF and the WM_VSCROLL and WM_HSCROLL GUIRegisterMsg commands and procedures to your script - so you need no commands other than those within the UDF itself. These commands are _GUIScrollbars_Generate and _GUIScrollbars_Scroll_Page. As you might expect, _GUIScrollbars_Generate generates scrollbars for your GUI. It is usually called AFTER you have added all the controls and all you need to use it is the GUI handle and the size of the underlying GUI you want to scroll. If you so wish, you can also decide to generate the scrollbars BEFORE the controls on the scrollable GUI, and you can choose if you want to risk not quite reaching the edge of the GUI when the scrollbars are at the maximum position. So a basic call could be as simple as: _GUIScrollbars_Generate ($hGUI, 1000, 1000) which would put scrollbars on the $hGUI window allowing a 1000x1000 underlying GUI to be displayed. _GUIScrollbars_Scroll_Page lets you scroll a page at a time. If your GUI was 200 pixels wide, you would have 1000/200 = 5 pages to scroll before reaching the edge - no need to know what the actual Page and Max values are, just use this simple division based on the number you use to draw the GUIs. So: _GUIScrollbars_Scroll_Page ($hGUI, 3) would scroll to the third page - it would display the area between 400 and 600 pixels of the full 1000 pixel width. If you ask for a page over the maximum available, you just scroll to the maximum position - asking for page 1 resets you to the origin. Ex_Example_1 shows the UDF working. You can decide whether to have both or just one scrollbar, whether to create the scrollbars before or after the controls, and whether you want the maximum scroll to be tight to the edge or leave a border. Just select the options you want - the script selects a random width and height for both the scrollbar GUI and the underlying GUI - and press the "Scroll" button to show a single page scroll down and/or right followed by a scroll to the bottom right corner of the GUI. There are labels to let you see the size of the GUI and the accuracy of the page scrolls (please read the tutorial above to understand why these are almost certainly inaccurate). The script requires the GUIScrollbars_Ex.au3 UDF in the same folder. Ex_Example_2 is a really simple example to show how easy generating scrollbars can now become! As you can see - no other includes, no GUIRegisterMsg commands, no WM_H/VSCROLL procedure functions. Just accurate scrolling and proportional thumb sizes. Ex_Example_3 shows the automatic calculation of control positions. Ex_Example_4 shows how to initiate the cursor keys to scroll the GUI as well. [New] Ex_Example_5 shows how to use the new _GUIScrollbarsEx_Resizer function. I hope these 2 UDFs are useful to AutoIt users - I certainly find them so. Here is a zip file with the UDFs and examples: Scrollbars.zip My grateful thanks to the authors of the GUIScrollbars and WinAPI UDFs for their code, some of which I have plundered. And as always I welcome constructive criticism and/or effusive congratulations. M23

Sure will. Are the IDs constant, when you relaunch your app? If so, that's the way to go. I think all the junk after BUTTON.app.* is unique per session as well, but could be recalling incorrectly. That, or you can loop through all buttons, until you get the one that matches your name, and IsVisible (controlcommand function) last attempt: ConsoleWrite(ControlGetHandle("yourtitle","","[NAME:button1; INSTANCE:1]") & @CRLF) ConsoleWrite(ControlGetHandle("yourtitle","","[NAME:button1; INSTANCE:2]") & @CRLF) at least this way, if it works, errors from new buttons MAY only occur when a new button with the same name is added

What's wrong with the _Singleton() UDF? Jos

This is my replacement for WinDirStat which I coded ages ago and never bothered to share before. I have used this tool many times while working on neglected servers and old workstations that have no or very little free space on a hard drive, and it has helped locate the source of the problems. Ahhhh, good old SQL error logs and Norton backup files!! My only real gripe with WinDirStat is the speed. I couldn't help but think it should be faster than that, so I wrote this to find out how fast it could be. I found that there were 2 recursive file find routines that were best for different purposes, one for local volumes and one for network drives. My script will determine which you are searching and use the routine most optimized for that task. Another thing about WinDirStat that I dislike is that you have to install it on the machine, this being a standalone is very nice. Yet another thing I dislike about WinDirStat is that it tries to multitask the enumeration, and I think that is the #1 reason that my tool is faster - mechanical hard drives don't multitask! SSD drives do, but my tool is faster on my SSD than WinDirStat anyway, so not all of the speed gains are from that difference. The only thing WinDirStat really has on MyDirStat is that mine re-searches each folder as you move up and down the drive, I played around with a global array but honestly decided I would rather have it update each time rather than a static array built on the initial run, so maybe that isn't a plus for WinDirStat. Even when traversing folders very heavily with this tool to find the biggest folders and delete the space hogs it isn't bad, subsequent scans go much faster than the initial scan. Notable discrepancy: At least under Windows 7 x64, MyDirStat will report a folder "C:UsersAll Users" which is actually C:ProgramData, so the numbers below reflect that glitch. Being that this is rather old code and I'm just posting it for fun I am not going to hunt down a fix (at this time...). All times were 2 consecutive runs with the programs, time taken was the second run. NAS (Promise NS4300N with 3 WDC WD15EARS-00Z5B1 in RAID-5, GB LAN connection) WinDirStat MyDirStat Time 14:49 1:30 Files 83,536 (2.1TB) 83,536 (2.10TB) RAM Usage 30.9MB 10.3MB C: (120GB OCZ RevoDrive 3 PCI-e RVD3-FHPX4-120G) WinDirStat MyDirStat Time 19 seconds 7 seconds Files 138,814 (62.6GB) 140,172 (66.24GB) RAM Usage 55.3MB 16.4MB As if the speed difference of the SSD wasn't bad enough, look at the difference on the NAS!!! Since I have some extra functions built in there are a couple required files to go along with the main script, all of which are used to delete or empty folders (empty leaves the actual folder behind). You must have the files in the included ZIP in the script directory. RoboCopy and the included batch files have been discussed in another thread on the forum previously: '?do=embed' frameborder='0' data-embedContent>> Enjoy Ian Edit 09/04/2014 - updated code, previous version downloaded 130 times extras.zip MyDirStat.au3

While your About function is running the code is caught in the while / wend loop: While WinExists("About Xex Launcher", "")=1 Switch GUIGetMsg() Case $AbtBtn_close GUIDelete($AboutGUI) EndSwitch WEnd How should your main gui work? What you can try is to use GUISetOnEvent on main GUI but I'm not sure whether it will work when About function is called. Test it. Regarding the "bug" - I wouldn't say it is a bug rather it is the behavior how the GUI reacts when you initialize the child GUI that way. Br, UEZ

https://www.autoitscript.com/autoit3/docs/functions/WinExists.htm The documentation specifically gives an example of how to use this function with notepad. You can try WinExists("notepad.exe"). If you only have one instance of notepad open at a time you can also try processexists("notepad.exe"). Even if you have more than one instance of notepad that you want to control then use WinGetProcess.

Apparently, there was no one replying to this thread, but somehow after digging *a lot* deeper, I found some gems: Read and write binary file: '?do=embed' frameborder='0' data-embedContent>> Getting file extension: '?do=embed' frameborder='0' data-embedContent>> Opening a file (automatically) with its default corresponding application: '?do=embed' frameborder='0' data-embedContent>> Adapting some user's existing code to suit my customized needs: '?do=embed' frameborder='0' data-embedContent>> Final sample: #cs Function name: uploadFileToServer Description: Inserts binary file into BLOB column of file-storing table Parameter(s): $sFilePath - String pinpointing to location of file $iUserID - Integer containing the current user's ID $iFileID - Integer containing the FileID referenced from FileRecord table Return Value(s): On success, returns 1. On failure, returns 0. #ce Func uploadFileToServer($sFilePath, $iUserID, $iFileID) ; Get the file extension Local $sTempFileExt = getFileExtension($sFilePath) ; Open the file in Binary Mode Local $hTempFile = FileOpen($sFilePath, 16) Local $iFileSize = FileGetSize($sFilePath) Local $sBinaryChars = FileRead($hTempFile,$iFileSize) FileClose($hTempFile) ; Create SQL statement for insertion of file Local $sSQLstatement_insertFile = "INSERT INTO filestorage (FileID,UserID,BinaryData,FileExtension) VALUES (" & $iFileID & "," & $iUserID & "," & $sBinaryChars & ",'" & $sTempFileExt & "')" Local $setFileBinaryData = _Query($global_SQLInstance, $sSQLstatement_insertFile) If $setFileBinaryData <> 0 Then Return 1 Else Return 0 EndIf EndFunc ;==>uploadFileToServer Pre-requisites: - You must have the MySQL.au3 file from user cdkid (this can be found in the AutoIt Tutorials Wiki) - getFileExtension() is a user-defined function, not native to AutoIt. Feel free to write your own UDF to get a file extension - The table must have a LONGBLOB column EDIT: This does not check the actual file size *before* the upload process. If you wish to contribute on limiting user's file size before calling my written function, please feel free to reply. Thanks.

It's mentioned in the help file that it works that way, all you had to do is read it.

Yes it did. EDIT: well, that -1 was not in the correct place, but except for that it worked.

You misspelled your variable name for the ControlGetText function call. "$x3" instead of "x3" 232showtime.

Leviathan25, we have this wonderful thing called our forum rules, which prohibit (among other loser activities) scripts to get around CAPTCHA. http://www.autoitscript.com/forum/index.php?app=forums&module=extras&section=boardrules

trying is free why you need this?

When in doubt, the one with the example is best for others to see as solution.

The order of the commands is important: $Form1 = GUICreate("Form1", 200, 135, -1, -1, $WS_POPUP, $WS_EX_LAYERED) GUISetBkColor(0xABCDEF) $Button = GUICtrlCreateButton("Button", 10, 10, 75, 25, $WS_GROUP) GUICtrlCreatePic(@ScriptDir & '\testimg.jpg', 10, 40, 120, 60) _WinAPI_SetLayeredWindowAttributes($Form1, 0xABCDEF, 255) GUISetState(@SW_SHOW) Br, UEZ

Make this easier and provide the name of the program.

Try: include <GUIConstants.au3> #include <File.au3> #include <String.au3> #include <WindowsConstants.au3> Local $Form1 = GUICreate("AForm1", 625, 443, 193, 115, Default,BitOR($WS_EX_COMPOSITED, $WS_EX_LAYERED)) ... Br,UEZ