Is it possible to extend Windows Explorer in Windows 7 with a custom view like "C:\windows\assembly". Behind this is a normal Folder Hierarchy (Visible via Cmd).
Are there any tools to spy into this microsoft implementation in order to find some possibilites?
EDIT:
Is there a documentation for HKLM\Software\Microsoft\Windows\CurrentVersion\Explorer
there is no magic and no need to spy anything, it all works with COM natively in Windows, no reason to spy or sniff from the registry, just plenty of theory to learn...
most of the examples are provided in C / C++, read this article for an introduction, in there you find many interface names and other keywords you can use to refine your search:
Edit: thanks to Luke's comment...
Understanding Shell Namespace Extensions
Related
I need to find the product version of an installed application using the product code GUID. Is there a way to do this using a simple API call of some sort? I have found ways to do it using P/Invoke and the WindowsInstaller namespace, but I am trying to avoid using P/Invoke.
The Windows Installer exposes Win32 API functions (P/Invoke) as you have discovered. It also has COM automation interfaces that wrap these APIs but I'm sure you can guess is this is even less elegant. Windows Installer XML (WiX) Deployment Tools Foundation (DTF) has an MSI interop library that wraps it as managed code but I'm sure you can guess what it's doing under the covers: P/Invoke.
There are ways of getting it from the registry but this is not the official API and is less elegant IMO.
So to answer your question, you are already doing it in a very good and professional way.
If you want to get sneaky you can look through the registry to figure it out. When an MSI is installed windows creates a set of registry keys under:
HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall\<munged-ProductCode>
or
HKLM\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\<munged-ProductCode>
(depending on your machine/MSI bitness)
Under that registry location there should be a registry value named "ProductVersion". The trick is to know how to 'munge' a windows GUID (see http://www.vmwareinfo.com/2011/09/surgically-eliminating-windows.html).
First, sorry for my poor English...
I want to add a virtual folder to Windows Explorer using a Namespace Extension (NSE), and I want users to be able to open this virtual folder to explore some path (e.g., c:\test).
How can I do this using Delphi? Thanks.
The place to start is the MSDN documentation: Introduction to the Shell Namespace. Naturally this is written from a C++ perspective but it's not too hard to map that across to Delphi.
Another excellent resource for such tasks is Code Project. For example: The Complete Idiot's Guide to Writing Namespace Extensions - Part I by Mike Dunn. In fact this is just part of an excellent series of articles on shell extensions.
At present Delphi is a poor choice because it does not produce 64 bit executables. This means that your shell extension will not run on 64 bit Windows which is now a serious limitation.
With the recent release of Delphi XE2 this limitation has been removed. XE2 is capable of producing 64 bit executables and can therefore be used to produce 64 bit shell extensions.
Basically a shell extension is a COM object that implements a set of interfaces. Which interfaces needs to be implemented depends on the type of the extension (there are some used by any extension, of course).
You can start reading here (you need some C -> Delphi translation, but when you start to work on such matters is better you get prepared to it), and then the reference is of course MSDN
http://www.shellplus.com/examples/namespace-extension-example.html
http://delphipower.tripod.com/winshell.htm
I asked a question earlier asking how to use the Windows 7 taskbar progress bar without the .dll files, but I realized that in VS2010 you can embed a .dll into your application. I set this option to embed to true, but when trying to use the code for said .dll, I get this error:
Interop type "Windows7ProgressBar" cannot be embedded. Use the application interface instead.
Not quite understanding what I have to do, I finally found a single .dll which is only 20KB (instead of the three required for the Windows API) and I can't quite use it yet.
Any help is appreciated!
The VS2010 option named "Embed Interop Type" only works for COM interop libraries. Not sure what "Windows7ProgressBar" might mean but it certainly doesn't sound much like an interop type. The native COM interface name is ITaskbarList4. Perhaps you are trying to embed a class wrapper for this interface, that won't work.
Consider using the ILMerge tool to combine assemblies.
My goal is to control an application from VB.NET. There is no API, and I do not have the source, only the compiled EXE file. Is there a way to find the opened application, find a button within the application, click a button and know it was clicked? Is there a way to read the contents of a textbox within the application?
Yes, with Windows Vista (or Windows 7, or Windows Server 2003 and later) there are "UI Automation" APIs.
There are managed options; System.Windows.Automation is one, shipped with .NET 3.0, as part of WPF... Though System.Windows.Automation was shipped as part of WPF, it does not require that the target application uses WPF.
You can read more:
the UI Automation blog.
the MSDN Magazine article - talks about using PowerShell with System.Management.Automation.dll (an alternative to System.Windows.Automation).
Blog post by Samuel Jack - describes using System.Windows.Automation to automate the Paint.NET program (C#).
CodeProject article #1 shows using UI Automation to test an installer
CodeProject article #2 provides a basic introduction to using System.Windows.Automation
Yes, you can, but first it might be easier to use 'AutoIt' as a prototyping script first to find the application. Look for the handle of the window of that application, enumerate through that window's child controls, look for that text box specifically and the button...once AutoIt prototype works, then dive into the real coding and it would be possible to use P/Invoke's to enumerate and find the windows, get the handles of it and perform the automation on it...
Have a look at the sample in C# from Stack Overflow posting Calling SendMessage (P/Invoke) keeps crashing. The OP was trying to access a third party window application, to extract texts and to use that texts within their program...notice how in that given link, 'FindWindow' was used to iterate through the child windows of the main process's window.
Yes, but you will have to resort to using native API calls such as EnumWindows and EnumChildWindows for example. Take a look at How To Enumerate Windows Using the Win32 API. It is for Visual Basic 6.0, but the concept is the same.
Window's COM allow us to wrap our application function for out-of-process invocation. If the COM interfaces are well defined and design, it is certainly great to consume the services via scripts and any programming platform that support COM/Automation/Active-X.
I am just wondering if there exist any alternate methods to design of what COM does? Or something close or similar methodology?
I am using Delphi in Win32 platform.
I'm not entirely sure, but it seems that you're talking about an alternate to COM for creating plug-ins for your software?
If so, there are myriad options:
TMS Software's Plugin Framework
RemObject's Hydra
Project JEDI's JVCL includes a plugin system
You can also roll your own. I wrote an article many years ago that provides the fundamentals (though the linked source is long since gone to the great bit bucket in the sky).
Corba
or
IBM's SOM
I'm sure there are others as well but those are the 2 others i can think of off the top of my head ...
If you want a TCP/IP (over the internet or over a LAN) interface for your objects, consider SOAP, and REST.
If you want to write plugins for your delphi app and not use COM/OLE-Automation, consider RemObjects SDK.