I am trying to integrate the Windows desktop file search feature into MSAccess to search files based on content .
For eg:
I want to search for all the files containing "Noble" in its content( preferably it also searches PDF content ) in a specific fodler(s) form MS Access.
Can anyone suggest good place to start?
I've been down this road. Windows Search or Google Search are quite problematic, particularly if you want to search data on a server, because you have to maintain indexes on each client workstation. There's a server version for Windows Search but the API is very complicated.
Office versions from 97 to 2003 provided a FileSearch object that was quite versatile, but that was removed in Office 2007.
Because of that, I coded up a FileSearch class module for use in Access to replace the core functionality provided by the old FileSearch object. You can find the code on my website. It still needs a lot of work, but I've had in production use since June 2009. It does have some issues on Vista/Win7 if you try to search folders that aren't available to non-admin users, and some other problems, too. I've wanted to get back to it and change the progress bar to use WithEvents, but as I've already got a working implementation for the two applications where I'm using it, it wasn't really worth my time.
Try it and see if you have any problems. For searching files for strings in those files, it works pretty well (much faster than the built-in WinXP search functionality!), but it's not going to be as fast as Vista/Win7's search, since it's not index-based.
At work I use Google Desktop because we're still on Windows XP and I don't know if that is the reason, but I'm not impressed with Windows Search.
I don't even think you can go into Access itself and do a search to look everywhere (data, objects, code, etc.).
Related
I am developing a small tool that can detecting which folders are being opened in windows explorer and bring it to front if a specific address has been opened.
I can use both C# and C++ and finally pick C# as it is easier than C++ to accomplish the same target. Then I googled the internet and knowing COM object SHDocVw.ShellWindows can help collect all windows being opened. Then I start looking for Microsoft document to see if any functions can help to achieve my other requirements. However, when I search shell related documents: https://learn.microsoft.com/en-us/previous-versions/windows/desktop/legacy/ff521731(v=vs.85) I am warned that "We're no longer updating this content regularly. Check the Microsoft Product Lifecycle for information about how this product, service, technology, or API is supported." Moreover, some documents even say these techs will be deprecated in Win11 (See the following screenshot)
I am wondering what the status of these Shell related technical. If these are being deprecated. What's the alternative solution? I don't want my tool stop working when start using new Windows. Meanwhile, I am confusing in the study routine of learning Windows desktop technical. Looks like so many technical to achieve the same targets. Is there anyone can give me some road maps?
Last thing, it's really frustrating to search COM object documents at Microsoft sites. Is this tech going down?
Microsoft has been trying to kill win32/desktop applications since Windows 8. That parts of the documentation is labeled as "legacy" is not something I would worry too much about. Some of the shell functions have been marked as deprecated for 20 years but still work fine today and too many applications rely on them for Microsoft to successfully remove them.
The Internet Explorer warning is different and IE might actually go away but that does not affect IShellWindows which is also used by Explorer.exe and 3rd-party applications. Its implementation lives in a shell DLL and not in IE.
I make intensive use of Office autocorrect feature for fast typing (which I use as a kind of autocompletion - shorthand / stenography). I have been able to modify the ACL file for Office 2011 applications (which works great in Word), but Office 365 comes with a separate 2015 version of Outlook and I cannot find the dedicated file for autocorrect entries. After a few tests, I found out that Outlook does take the Mac OS system dictionary entries into account (which are stored in an .sqlite file in /Library/Dictionaries/CoreDataUbiquitySupport/username/UserDictionary/local/store/UserDictionary.db - in case you're wondering where it was...). So I have been able to add my own dictionary entries in this sqlite file and Outlook does take them into account. Heck, Outlook gets real slow when this system dictionary is fed with more than 3000 entries (I bet you're wondering wtf is in this list, never mind). Luckily, I found out that Outlook's Autocorrect feature also uses its own set of entries (which can be manually updated through Outlook Preferences > Autocorrect) - these work better and faster. So now I just need to find this damn' little file where I can store my huge list of words through a bulk import...
A long search on the Web made me realize I am probably a very lonely user of Outlook's autocorrect feature (at least on Mac)... Any weird guy like me out there who would incidentally know the path to this golden little file?
Thanks in advance,
The real place to find this is in the Group Containers folder:
/Users/user_name/Library/Group Containers/UBF8T346G9.Office/Microsoft Office ACL [English].acl
Apparently you can find it here:
/Library/Dictionaries/CoreDataUbiquitySupport/{{username}}/UserDictionary/local/store/UserDictionary.db
According to this source: http://australianforexbrokersxx0.blogspot.com/2015/03/where-is-autocorrect-dictionary-file.html
How can I access Windows Search index data from Emacs? Knowing this would be useful for example when writing a minor mode that integrates Windows Search into anything mode or ido-mode.
By Windows Search, I mean the Windows 7 feature that lets you find documents by pressing Start and typing part of document file names (or part of document contents).
Here is a little Python script providing a command line utility for Windows Search. You need to install Python for Windows extensions to use it.
Accessing Windows Search from within emacs is going to be a bit difficult because the API Microsoft provides is strongly skewed towards the Microsoft programming environment. Judging by the MSDN docs, the easiest path would be putting together a SQL query that Windows Search will accept and sending that to a PowerShell/VB script that knows how to send that query to Windows Search. You'd then tell anything/ido/icicles to incrementally send input to such a script, parse the results, and display those.
The task that you are attempting is very difficult, and much of the difficulty comes from the fact that you are trying to get two programs from very different worlds of programming to talk to one another. Completely apart from the FSF/GNU folks actively disliking Microsoft, the design of the Windows API means that the least-effort way of dealing with Windows is to use the Microsoft toolchain. This in contrast to the Unix "API" of sending plain text through intermediary programs, pipes, and sockets.
I have several ppt and pdf files with similar contents and I want to search them together. Is there any application or simple technique available for that? Thanks a lot.
Windows Search might work but learning to use it effectively is a job in itself.
Try Agent Ransack, assuming a Windows computer. It's free and far easier to use than Win search. And is available for pretty much any version of Windows.
Use Windows Search and make sure you have the PDF IFilter installed.
Try Agent Ransack, assuming a Windows computer. It's free and far
easier to use than Win search. And is available for pretty much any
version of Windows.
Agent Ransack works really well for finding .ppt contents. I've used it to find which of several hundred .ppt files in a folder had comments (search for commenter's handle (usually their initials) + á, as in ABCá
Sample search box
Thanks to Steve Rindsberg for pointing me to this useful software. I'd tried Windows search and a couple of PowerPoint freeware programs, but Agent Ransack did the job and saved me manually searching multiple .ppt files.
FileLocater is free to use for personal use. You can search in ppt, pdf, zip files.
Goal
Let me start with my final vision of what I'd like to be able to do first: In Windows, I'd like to be able to use a global keyboard shortcut that I define (say, Ctrl+Alt+C) to copy the full path and filename of the open document in the foreground application to the clipboard.
This would be useful to, for example, be able to subsequently paste the path & filename into an "Open File" dialog in an email client to attach that document to an email, without having to manually browse to the target document in the filesystem.
Specific Question
Now, the specific part of how to do this that I'm interested in how to implement is: How can I get the path and filename of the current "open document" of any arbitrary currently-running Windows application. (If this can't be done with any Windows application, then the next best thing would be for this to work with as many applications as possible.)
Obviously, this wouldn't apply to some applications that don't necessarily have the concept of a "currently open document" that corresponds to a file on the local filesystem, such as an email client, an IM client, or (usually) a web browser.
Application-Specific Solutions
I'm aware that it's possible to write application-specific solutions to do this. For example, the following MS Word VBA subroutine will copy the filename and path of the open document in Word to the clipboard:
Dim myDataObject As DataObject
Set myDataObject = New DataObject
myDataObject.SetText ActiveDocument.FullName
myDataObject.PutInClipboard
However, what I really want is something that will work for any of the applications on my system (or, again, for as many of them as reasonably possible) without having to try and write an application-specific solution for each one.
Idea: Recent Documents Folder
One idea: Could the Recent Documents folder (and/or its underlying Windows APIs) somehow be leveraged to help with this? It seems to have information about the same concept of "open documents" that I'm interested in here, that apparently applies across various application types. (Looking at the contents of the Recent Documents folder on my machine, I see entries in there that were apparently made for documents that I opened with various applications including MS Word, MS Excel, Eclipse, Adobe Acrobat Reader, Paint.NET, TOAD, and Notepad2.)
Preferred Solution Language
I'd prefer solutions in C# or C++ code, but I'm open to any suggestions for how to go about doing this, regardless of implementation language!
Windows 7?
Update 11/2009: Now that Windows 7 is widely available, I figured it might be worth coming back to this question and asking: Does Windows 7 provide any new APIs, or any other mechanism, that would help with what I'm trying to accomplish here?
The best you could probably do is look at the recent documentation registry keys, and get the list of most recent documents. Some sample code for working with this data is in this CodeProject article. This is saved in:
HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\RecentDocs
However, this isn't going to show you whether a document is currently open or not. You could potentially check the title of all open applications, since many applications put document names in their window titles, but this is not a requirement, and many applications do not do that.
There is no mandatory mechanism for an application to specify its open document, so this is not generically possible.