ATTENTION: You are viewing a page formatted for mobile devices; to view the full web page, click HERE.

DonationCoder.com Software > Find And Run Robot

New Version

(1/2) > >>

piedone:
Hi!!
Just did some tests on the new version. It works now. Shortcuts, everything. What was the problem? Could you find that out? :)
So far so much!! Thanks anyway. let me know if you need to know anything else.  I am also...a programmer. If you need a hand :), let me know.
I will keep testing. But it looks already good.

piedone

ps - in my opinion, find&run kicks the google desktop search somewhere...:).

mouser:
here's what i can tell you about the fix to shortcuts,
there is a windows API command called ShellExecute (google will find you lots of pages).
it can be used to start programs from within other programs, and can be used to tell windows to open an arbitrary file,
in which case windows is supposed to go looking for the program that handles that type of file and open it.
so basically ShellExecute does it all.

by default, F&R was invoking ShellExecute on the files selected for launching, whether they were exe files, other documents, or shortcuts to exes or documents (ie .link files).

apparently there were 2 problems with this.

the first was this policy i didnt know about which says the ShellExecute essentially hangs while waiting for the parent application of a document to start up and be ready to take input.  this was causing F&R robot to just sit on screen waiting and helpless.

the second problem was the fact that it seems on some computers, when ShellExecute is called with a ".lnk" file (shortcut file), it refuses to launch it.  i'm still not sure why certain machines do that and others don't.  it sounds like it could be a security issue but i've never heard it discussed before.

the solution to these problems were, first, to manually decode the shortcut file inside the program to recover the file being pointed to, whether it be an exe or a document.  then the second was to write a tiny like 1 line helper windows utility that basically just takes the name of a document on the command line, and calls ShellExecute on it to have windows open the appropriate program.  By using a separate helper to call ShellExecute, and by invoking that helper with a *different* kind of spawning api call (CreateProcess) i was able to hand off the "waiting for ShellExecute" responsibilities to a separate process and thereby let F&R get back to its job of minimizing or exiting after a launch.

probably more info than you wanted to know, but there it is :)


hehehe, well as i was telling someone before,
find&run is not really a competition for the desktop search engines which can actually look INSIDE files, find and run just works on file names, and because it actually searches for files on demand, its probably not ideal for searching entire hard drives over and over; in such cases its better to have a large database-driven constantly updating indexing system like one of those desktop search things.

mouser:
just again wanted to say how much i appreciate the beta testing!!
as a programmer it's so nice to know people who are willing to try these intermediate releases and report back, it's so much harder to fix these problems without such help.

piedone:
:)
thanks for the answer. better long than too short. hehe
keep in touch


piedone

mouser:
did you notice i added the alpha-blen (transparency) control?

Navigation

[0] Message Index

[#] Next page

Go to full version