Leaderboard

Musashi, Dream on! M23

In this case, what the OP needs (and everyone who is interpreting in that way) is an English grammar course, and obviously, trying what the function does: it opens a FileOpen Dialog

I fully agree with @pixelsearch , that FileOpenDialog is a misleading function name (for at least 95% of the users). However, @Melba23 's objection, that the naming was derived from Microsoft's specification, is comprehensible. Of course, it would go beyond the scope of any help to list everything that a function does not do. In "severe cases", a more exposed hint might be helpful, though. @c.haslam : You are definitely not alone with that one . While I assume you meant it as a pun , from a purely linguistic point of view you're not wrong. FileOpenDialog could be interpreted both as a File->OpenDialog and as a FileOpen->Dialog.

to be sure, it opens a dialog

I've got an idea! What if there was an AutoIt reference file or document that painstakingly listed and described the AutoIt language, its use, what each and every function does and its parameters, and what the expected function's result should be upon success and failure? What would be even better is if maybe they could throw in an example or two for most of the functions, because sometimes a good example can be worth a thousand words. Maybe it could have a relatively easy to read, standardized, format so if it was used often enough, one could quickly find the answers to these types of questions about AutoIt. Having such a document would surely clear up 95% or more of the ambiguities of naming conventions because it would clearly define its own language (AutoIt). One would merely need to read this document to find and understand exactly what any given AutoIt language element does and how it could be implemented. A document like that, if read and studied, might even make discussions like this one completely unnecessary. I know, it's a pipe dream. There's no way such a powerful document could or would ever be created and maintained. 🙁 Nevertheless, I really wished such a document existed.....oh wait.....it does! It's called the Help File. Sorry, I couldn't resist.

Hellooo Musashi & FrancescoDiMuro What about applying this "grammar split" to... FileSaveDialog

c.haslam, Alas, "FileOpenDialog" is the Microsoft name for that dialog, so that is what the AutoIt function is called. I sympathise with your plea, but best take it up with Bill Gates, not us! M23

Hi there, while I created an example script to generate and execute a function during runtime, I stumbled across a neat way to share data between running autoit scripts. This is done using the amazing magic of AutoItObject_Internal . (You'll need at least Version 3.0.0 of AutoItObject_Internal) Using this UDF, you can create a shared data storage, basically an empty "AutoitObject_Internal-"Object which you can then use to write / read data Inline. no set/get methods, just #include "AutoItSharedData.au3" $oShare = _AutoIt_SharedData_CreateOrAttach("MyCustomID") $oShare.some_data = 'foo' and you're done. any other script accessing this data will have to do: #include "AutoItSharedData.au3" $oShare = _AutoIt_SharedData_CreateOrAttach("MyCustomID") ConsoleWrite($oShare.some_data & @LF) Basically it's Larsj's Implementing IRunningObjectTable Interface, but you dont have a Dictionary, but an IDIspatch Object instead. There are already a bunch of IPC options available - and this is another one. AutoItSharedData.au3 Example Script 1 Example Script 2 Output: To test: run Example Script 1, Then run example Script 2.. or the other way around. Example Script 3 Example_sharedata3.au3 Example_sharedata3_Controlsend.au3 Example_sharedata3_Tooltip.au3 To test: run Example_sharedata3.au3. Output: Example SharedData4: Output: /Edit: Please note that there's a limitation with the Running object table : The Script accessing a variable first, will be the "server" for this variable. This means, access to that variable from other scripts should only be possible, as long the "server" script is running! Use appropriate Object Error handlers in case you don't want the surviving "clients" to crash. Feedback and/or improvements appreciated changelog version 2.0 Removed need for AutoItObject, as AutoItObject_Internal now comes with ROT support Added UDF Header Fixed typo on "#include AutoItObjectInternal.au3" -> "#include AutoItObject_Internal.au3" Added ObjGet() after registering the object fails (in case 2 programs tried to register the same ID simultaneously) Updated Examples & zip archive. Cheers, AutoItSharedData.zip

@64bitfury IMO, a better option would be to use _WD_UpdateDriver to install msedgedriver.exe to a directory of your choice if it doesn't already exist.

Please don't take my dreams away . Finally, however, you , @FrancescoDiMuro , @TheXman [et al.] are of course right. If someone is interested to delve deeper into AutoIt, then she/he should also have the willingness and ability to deal with such inaccuracies in the addressed function names . Therefore, this aspect of the discussion can probably be declared as finished.

There is also a problem with handles: local $hWin = WinGetHandle("[active]") $oShare.hGUImain = $hWin ; it also stores it in Decimal... ConsoleWrite($hWin & "___" & Hex($oShare.hGUImain) & @CRLF) Local $aGUI_Main_Pos = WinGetPos($hWin) ConsoleWrite("Pos hWin:" & $aGUI_Main_Pos[0] & @CRLF) Local $aGUI_Main_Pos = WinGetPos($oShare.hGUImain) ConsoleWrite("Pos oShare:" & $aGUI_Main_Pos[0] & @CRLF) ; ERR Local $aGUI_Main_Pos = WinGetPos( HWND($oShare.hGUImain) ) ; THIS works ConsoleWrite("Pos oShare:" & $aGUI_Main_Pos[0] & @CRLF) ; OK EDIT You should detect if there is a handle and store it as 0xHexNumber into the share var.

This looks like something coming from your code and completely unrelated to _WD_ElementOptionSelect. 🤔 _WD_ElementSelectAction may eventually allow you to choose one of the Select element's options, but currently it offers the following options -- Value - retrieve the Select element's current selection Options - retrieves the value / label attributes for the Select element's options

You need // at start of the xpath

@USSSR This could be one of many ways: Local $hWinHandle = WinGetHandle("[REGEXPTITLE:(?i)^\(\d\/\d\) \- Information \-]") But, as @Nine stated, try to use the CLASS of the Window, which you can find using the AutoItWindowInfo Tool P.S.: OT, but congrats for the 1k reputation @Nine!

@FrancescoDiMuro sorry, but I have to disagree. Having two xls-Files in my folder, Ubound() returns three. And both files get opened @don00 the help file says: _Excel_BookOpen ( $oExcel, $sFilePath [, $bReadOnly = False [, $bVisible = True [, $sPassword = Default [, $sWritePassword = Default [, $bUpdateLinks = Default]]]]] ) So you'd need to use something like (just copied from the help file) ; Create application object Local $oExcel = _Excel_Open() If @error Then Exit MsgBox($MB_SYSTEMMODAL, "Excel UDF: _Excel_BookOpen Example", "Error creating the Excel application object." & @CRLF & "@error = " & @error & ", @extended = " & @extended) ; Open an existing workbook and return its object identifier. Local $sWorkbook = @ScriptDir & "\Extras\_Excel1.xls" Local $oWorkbook = _Excel_BookOpen($oExcel, $sWorkbook)

Usually I don't participate in this kind of thread to avoid a "too much" passionate debate, but today I'll do an exception. @c.haslam : your thoughts are exactly the ones I had 3 years ago when I discovered AutoIt, asking myself how a function named "FileOpenDialog" didn't open anything, especially when there's an "Open" button in the Dialog ! Isn't it supposed to be a "FileOpen" function (which opens a file) added to a GUI dialog ? It's true that the help file stipulates "Success: the full path of the file(s) chosen." and chosen is a key word in this sentence. If the function doesn't open anything but simply "chooses" or "selects", then why isn't it called "FileSelectFile", based on the "FileSelectFolder" function name ? Or even "FileChooseFile" ? Everything without the "Open" word in it would be fine ! And for users who still don't find an issue with the word "Open" in "FileOpenDialog", then don't you think the function could also have been badly named "FileDeleteDialog" or "FileMoveDialog" or ""FileRenameDialog" ? With a help file stipulating in all cases "Success: the full path of the file(s) chosen." ? I'm sorry but this GUI dialog function badly named "FileOpenDialog" is only a file chooser function not related at all with "Open". You can do what you want with the returned "full path of the file(s) chosen", you can delete the files, move them, open them etc... Anyway, Melba23 gave us the correct reason why the function is named like that and I'm glad he "sympathises with your plea". Because of his open mind, he's able to understand people's concerns and, as I already told him before, he's able to place himself in other people's shoes to understand them better. So c.haslam you're not alone on that one, I remember having had the same thought about the badly named "FileSaveDialog" function (which saves nothing at all) but when this "misfortune" happens to you once, then it shouldn't happen anymore after that... in theory.

Having been away from AutoIt for a year or so, I was confused. I would call it FileSelectFile. The first "File" identifies it (and sorts it in the Help) as a file-related function. It would then be a "mate" to FileSelectFolder. This change would break many scripts: you asked, so I suggested. It won't happen. I note that FileOpenDialog labels the button as Open. But in the script I am writing, a selected file is never opened, so having a parameter to choose the label as Open or Select would be an advantage. Mea culpa!

Using your logic, what would you call a function that represents a common dialog box (named OpenFileDialog) that allows a user to specify a filename for one or more files to open (making sure that it followed the established naming convention for AutoIt file-related functions)? Keep in mind that you want people to understand that it is a common Microsoft dialog box, not a custom dialog box. Maybe....FileOpenDialog() or FileOpenFileDialog() (which is a little redundant)? Just because you misunderstood the naming of the function and didn't understand the help file's description of what it actually does, doesn't mean that every else has that same misunderstanding. That's a bit self-centered isn't it? You make it sound like function names should be tailored to you and your understanding, as misguided as they may sometimes be. 😉

You can always read registry : HKEY_CURRENT_USER\Software\Google\Chrome\BLBeacon\version HKEY_CURRENT_USER\Software\Microsoft\Edge\BLBeacon\version

c.haslam, Where in the Help file page for FileOpenDialog does it even mention opening files? It specifically says: which is all that it does (other than change @WorkingDir if successful and which is also quite clearly mentioned). Do you expect us to say what it does NOT do as well? I mean it does not delete the files, nor change their attributes, nor move them up one level in the directory tree, etc, etc. What it does do is tell you the file(s) selected - which is, as shown above, specifically mentioned. M23

@MASKED, Ok, I can only come to the conclusion you are really not that smart when you consider it to be a bright idea reporting both @Melba23 and me for locking your threads. You are banned.

Current Alpha version has resolved that issue

well, keep us posted

Guinness, I used Return (@error <= 0) because if @error is 0 or -1, then the registry key exists.

I made my own function for this. Func _RegExistKey($sKeyname) RegEnumVal ($sKeyname, 1) Return (@error <= 0) EndFunc