DonationCoder.com Software > Find And Run Robot

FARR v2 - Official Bug Tracking and Feature Request Thread

<< < (18/24) > >>

LibertyToad:
I've been trying to update FARR to the newest version but the when I download here from the official page I get  version 2.99.02.  

Also the update check still opens a dialog that has no close button.

Thanks!

:'(

NEVER MIND.  I was installing FARR into an existing FARR directory and it was installing the new version into a new FARR subfolder.  Oops.

DougalS:
but another problem: on x64 OS FARR cannot start any .lnk (from %MYSTARTMENU%|%COMMONSTARTMENU%)
for build-in/system Windows application from "%windir%\System32\" that doesnt have corresponding x32 analog in "%windir%\SysWOW64\"

on windows 7 x64 you cannot execute:
"Sound Recorder", "Snipping Tool" and other.

maybe FARR, when resolve *.lnk target to %windir%\system32\* can try to find it in %windir%\sysnative too ?


-lordmuzer (November 18, 2010, 03:27 PM)
--- End quote ---

I am new to FARR, although have used Launchy and Executor for some years (but am considering switching to FARR because it is so much better  :)). This is also a problem for me (and part of the reason I am looking at alternative launchers), as it is with both Launchy and Executor - although there is an unofficial Launchy x64 version.

I use regedit32 a lot, and often switch between the 32bit (sysWOW32 folder) and the 64bit (System32 folder) so I can see the HKLM\Software tree either in real mode or in the virtual redirected mode that the 32 bit version provides. There are other x64 apps I also use including nbtstat (doesn't exist in SysWOW32), and cmd.exe (need to run the x64 version to get access to nbtstat and also to manage network shares if the admin/normal networks aren't linked).

After lots of experimenting I think the following is the cause:

* x86 apps cannot see the System32 folder, or any of the files therein. Any reference to Sstem32, including in shortcuts is redirected to the SysWOW32 folder.
* x86 apps can call and use x64 apps that are not in the system32 folder, as it is the only one that is completely redirected.
To confirm this I use a x86 file explorer (Xplorer2) to look at the C:\Windows\System32 folder and it is exactly the same as the C:\Windows\SysWOW32 folder, and if I run C:\Windows\System32\regedit.exe I get the 32bit version (from SysWOW32 folder) and cannot see the real HKLM\Software\WOW3264node tree.

If I use a x64 version of Xplorer2 then I can see the real contents of C:\Windows\System32, and can start x64 apps from the System32 folder and x86 apps from SysWOW32 folder.
I think the only way to get access to apps (and consoles) in the C:\Windows\System32 is to do so from a x64 app. I have found that I can copy the apps out of the System32 folder and then they can be run fine.

One way I have got around this is to create a junction to the C:\Windows\System32 folder, and then I can access all the x64 app from the System32 folder by using the junction path. But this is a bit of a kludge and needs either Xplorer2 or link shell extension.

Sorry for long winded reply, but I think the only way to access the System32\apps I want is for a 64bit version of FARR.

DougalS:
Mouser has fixed the System32 redirection problem with v2.103.01 beta, hopefully it will be released shortly.
Edit: now out with 2.104.02.  :)

DougalS:
Character selection in Input and memo box.
Not sure if this is due to limitations of libraries you use or something in the coding, but there are some odd key combinations that don't work in these boxes.
In the Input box the normal word select keys shift+ctrl+left/right don't work but shift+home/end do.
In the memo box the shift+ctrl+left/right work, but shift+up/down, shift+home/end and shift+ctrl+home/end don't. To move the selection into the next/previous line of text you have to use shift+left/right at the end/start of the line.
This is a minor issue in such a great program, but I often want to select just the previous word to replace it, and currently I have to use multiple backspace or double click the mouse to do it.
Cheers

DougalS:
I am not sure this is a bug, or I am doing something wrong. I have a task that sometimes goes bad when the computer sleeps. I want to be able to kill it, then restart it again. Although I could do it with a script or batch called from an alias, I wanted to try and keep it all in an alias to keep everything in one place.

What I planned to do was use the pkill plugin to kill the task, wait a few seconds to make sure it is gone (if had to be forced), then start the task again.

I tried with alias result "restartsearch pkill taskname\n ;;; sleep 5000 ;;; restartsearch taskname\n" but it doesn't work, the first part "pkill taskname" just sits in the edit box for 5 seconds, then the second part "taskname" appears in the edit box, the results are provided and the task restart is executed.

If I use just the first part ("restartsearch pkill taskname\n") by itself as alias result, it works fine, but not when joined with the rest.

Thinking it may be something to do with calling an alias, I tried using direct file commands ("C:\Windows\System32\taskkill.exe /F /IM taskname \runasadmin"), and this works with the rest of the command (";;; sleep 5000 ;;; restartsearch taskname\n"). The TaskKill command isn't as neat as the pkill plugin though (you don't get to try request before force, it is one or the other).

I also tried creating an alias for the pkill part (which works by itself), but when used as the first part of the command it doesn't find and run that alias (so again the first part does nothing). Is there something about the result window not updating until all the command is complete?

Sorry if I have missed something in the help file or forum (been searching and working on this for few hours now).

Cheers

Is there something I am missing when using a plugin alias and an intermediate command, or is this a bug.

Navigation

[0] Message Index

[#] Next page

[*] Previous page