
Mbee
Active Members-
Posts
553 -
Joined
-
Last visited
Recent Profile Visitors
929 profile views
Mbee's Achievements
-
argumentum reacted to a post in a topic: SciTE4AutoIt3 Full won't show official function definitions
-
SciTE4AutoIt3 Full won't show official function definitions
Mbee replied to Mbee's topic in AutoIt General Help and Support
I'm going to go with that for now, but I have to go to bed. Thanks enormously guys! -
SciTE4AutoIt3 Full won't show official function definitions
Mbee replied to Mbee's topic in AutoIt General Help and Support
Your example with Send({f1}) works! BTW, all I did was type it in and "Go", I didn't select anything. Here's the full output... >"C:\Program Files (x86)\AutoIt3\SciTE\..\AutoIt3.exe" "C:\Program Files (x86)\AutoIt3\SciTE\AutoIt3Wrapper\AutoIt3Wrapper.au3" /run /prod /ErrorStdOut /in "C:\MyScripts\AutoIt Scripts\MyBasicFileCombiner\Another F1 test.au3" /UserParams +>22:49:11 Starting AutoIt3Wrapper (21.316.1639.1) from:SciTE.exe (4.4.6.0) Keyboard:00000409 OS:WIN_10/2009 CPU:X64 OS:X64 Environment(Language:0409) CodePage:0 utf8.auto.check:4 +> SciTEDir => C:\Program Files (x86)\AutoIt3\SciTE UserDir => C:\Users\mjb\AppData\Local\AutoIt v3\SciTE\AutoIt3Wrapper SCITE_USERHOME => C:\Users\mjb\AppData\Local\AutoIt v3\SciTE >Running AU3Check (3.3.14.5) from:C:\Program Files (x86)\AutoIt3 input:C:\MyScripts\AutoIt Scripts\MyBasicFileCombiner\Another F1 test.au3 +>22:49:11 AU3Check ended.rc:0 >Running:(3.3.14.5):C:\Program Files (x86)\AutoIt3\autoit3_x64.exe "C:\MyScripts\AutoIt Scripts\MyBasicFileCombiner\Another F1 test.au3" +>Setting Hotkeys...--> Press Ctrl+Alt+Break to Restart or Ctrl+BREAK to Stop. ->22:49:11 AutoIt3.exe ended.rc:1 +>22:49:11 AutoIt3Wrapper Finished. >Exit code: 1 Time: 0.9453 -
SciTE4AutoIt3 Full won't show official function definitions
Mbee replied to Mbee's topic in AutoIt General Help and Support
No, and that seems like an important clue. It also doesn't work with Notepad++ -
SciTE4AutoIt3 Full won't show official function definitions
Mbee replied to Mbee's topic in AutoIt General Help and Support
>>> The result I get is "+ looks good" Thanks so very much for sticking with me! -
SciTE4AutoIt3 Full won't show official function definitions
Mbee replied to Mbee's topic in AutoIt General Help and Support
Thanks for pitching in! Unfortunately, that's just where I got it from when I re-installed it from scratch. -
SciTE4AutoIt3 Full won't show official function definitions
Mbee replied to Mbee's topic in AutoIt General Help and Support
Thanks for helping me out... -
Mbee reacted to a post in a topic: SciTE4AutoIt3 Full won't show official function definitions
-
I have SciTE4AutoIt3 v21.203.1500.3 installed along with the latest versions of the rest of AutoIt. I haven't used it on this computer for a while, but SciTE used to work perfectly. Now, however, when I highlight an official function name and press F1, nothing happens, In fact, no matter what function key I press, I never get the function definition. I'm running the latest version of 64-bit Windows 10. I uninstalled and then re-installed SciTE4AutoIt3 from this official site. What can I do to troubleshoot this issue? I appreciate your help!
-
I've been trying bluetooth keyboard after bluetooth keyboard after bluetooth keyboard, but all of them produce unwanted effects (which don't occur with wired keyboards): Many, if not all, function keys do profoundly irritating things! For example, with a wired keyboard, if I highlight a keyword or known function name in the editor and press F1, the help file opens and displays all the relevant documentation for the highlighted item. Hooray! But with all six bluetooth keyboards I've tried in the last few weeks, "F1" opens a very large and infinitely annoying popup which shows me a set of apps (Edge, Notepad, etc) that it stupidly assumes I want to use! It's so weird I can't even create a screen capture of it because it seems to disable many, if not most, keys on the keyboard. This has got to be a Microsoft load of toxic, belligerent, mind-bogglingly hateful "features", since the exact same thing happens regardless of the bluetooth keyboard manufacturer or design. But maybe if I knew which scan codes F1 (or F2, since it seems to the same thing as F1) sends to SciTE for AutoIt, I could remap/reassign it/them to send the proper code instead of whatever hateful code it's sending that creates the Popup From Hell. On the other hand, that might not work either, so if anyone has any ideas to try, I would appreciate it. Thanks!
-
argumentum reacted to a post in a topic: Attempt to obtain CMD results fails
-
Thanks for your reply, @argumentum! But I just now solved the problem. I went into Control Panel -> Programs and Features -> Turn Windows features on or off -> Services for NFS. All the options were already checked down through all levels, so I unchecked them all, rebooted, and then re-enabled them all. Afterwards, "ShowMount.exe" and the other NFS client tools were all where they should have been all along: In @SystemDir. Don't know how that got messed up, but everything is working fine now. I'm going to add some code in my script to check for the presence of the necessary NFS Client tools in Windows\System32 first, and if they're not there, I'm going to advise the user to do the same thing. Actually, I'm going to ensure that they're either running Windows 10 Pro (don't know about 11, don't have it on any of my boxes) or otherwise have the Client for NFS (NfsClnt) installed. That last is because I've read of tricks that allow you to install the NFS Client on a non-Pro, Non-Enterprise edition of Windows 10. Many, many thanks to all of you for your time and knowledge!
-
Now, this is strange. There are three files in that weird directory... nfsadmin.exe rpcinfo.exe showmount.exe The earlier version of the app I'm developing did not invoke "showmount", but it did include an invocation of "nfsadmin", as follows... $L_PID = Run( @ComSpec & " /c nfsadmin client start", @SystemDir, @SW_HIDE, $STDOUT_CHILD ) Which has always worked correctly, even without reference to that directory path. I changed the line in the function in my OP to include a reference to @SystemDir, as follows... Local $Lf_CmdLine = '"showmount -e ' & CUBE & '"' $Lf_PID = Run( @ComSpec & " /c " & $Lf_CmdLine, @SystemDir, @SW_HIDE, $STDERR_MERGED ) But that does NOT work. Why does the former work without specifying the WinSxS directory, but the latter won't? Note again that if I include the WinSxS path in the "showmount" command line, it works correctly. But that's such an ugly "solution" that there's got to be a better way. That better way should look just like the "nfsadmin" call. Any suggestions as to how to get the "showmount" command to work without specifying path to the WinSxS directory?
-
Thanks for your reply. Earlier, I brought up the possibility that calling Run() with @ComSpec within a script might not carry over the necessary environment, including environment strings. But please consider (1): If I run the command via the CMD line, it works perfectly, and (2) that every other such call works perfectly. For example, you don't need to define an environment variable to perform a CMD such as... Run( @ComSpec & " /c " & 'Dir /b "' & @ProgramFilesDir & '"', "", @SW_HIDE, $STDOUT_CHILD ) My guess is that you're not running Windows 10 PRO. Only the Pro version comes with the NFS Client installed. Also, you have to ensure that the NFS Client service is running. Perhaps if your system isn't configured that way, you will get the results you see. Another possibility is that the directory in question is present on non-Pro systems so that the NFS Client could be installed?
-
I have another idea. What if I create a batch file that outputs to a temp file, then read that temp file to an array? I'll let you know... Hmmm.... I'm getting a weird response (attached file) Local $Lf_Stat, $Lf_TempPath, $Lf_BatHdl, $Lf_PID, $Lf_RawCmdOutAra[1], $Lf_NumShares = 0 Local $Lf_TempReplyPath = _TempFile() Local $Lf_TempBatPath = _TempFile( @TempDir, "_", ".bat" ) $Lf_BatHdl = FileOpen( $Lf_TempBatPath, $FO_OVERWRITE + $FO_ANSI ) FileWriteLine( $Lf_BatHdl, @ComSpec & " ShowMount -e " & $argIn_NFS_ServerNameStr & " > " & $Lf_TempReplyPath ) FileClose( $Lf_BatHdl ) $Lf_Stat = ShellExecuteWait( $Lf_TempBatPath ) If @error <> 0 Then Return SetError( @error, 0, -1 ) EndIf $Lf_Stat = _FileReadToArray( $Lf_TempReplyPath, $Lf_RawCmdOutAra ) If $Lf_Stat <> 1 Then Return SetError( 1, 0 , -2 ) EndIf ~dsckcek.tmp
-
Well, I figured that there was something about running a command via AutoIt that didn't match the environment of running it via the command line, so I tried the following (snippet): Local $Lf_Stat, $Lf_TempPath, $Lf_PID, $Lf_RawCmdOutAra[1], $Lf_NumShares = 0 $Lf_TempPath = _TempFile() $Lf_PID = Run( @ComSpec & " /c ShowMount -e " & $argIn_NFS_ServerNameStr & " > " & $Lf_TempPath, _ "", @SW_HIDE, $STDERR_MERGED ) If ($Lf_PID = 0) Or (@error <> 0) Then Return SetError( @error, 0, -1 ) EndIf ProcessWaitClose( $Lf_PID ) $Lf_Stat = _FileReadToArray( $Lf_TempPath, $Lf_RawCmdOutAra ) If $Lf_Stat <> 1 Then Return SetError( 1, 0 , -2 ) EndIf Unfortunately, it produced a zero-length file.
-
That's correct, @Jos. I've never needed to make separate calls in the past, since until now specifying "$STDOUT_CHILD + $STDERR_CHILD" and then calling StdoutRead() worked fine. I now see that the only time that will work is if there is no error output. I love learning of my mistakes!