IS there any way to embed an OLE object in the Wordpad application using some kind of scripting, say vb script.
Using native application we can do it through Insert->Object and then select any object that needs to be embedded. I need to do it through vbscript like we can do it in Excel/Word/Powerpoint.
Please let me know.
Thanks.
Wordpad does expose an interface that can be instantiated using the ProgID "Wordpad.Document.1" as seen below. However, it doesn't appear to have a type library associated with it (there's nothing to see in an object browser) and there is no documentation of any publicly accessible methods or properties. It would seem to me that this was never intended to be used as a scriptable interface despite the fact that the following code will execute without error.
Set objWordpadDocument = CreateObject("Wordpad.Document.1")
Related
I was looking at a code sample by Raymond Chen, available here. From what I understand, he obtains a shell item using the IShellWindows interface. Then, using that item's IDispatch interface and a call to QueryInterface, he hops over to the item's IWebBrowserApp interface. And then a few lines later, it appears that he hops over to the item's IServiceProvider interface. My question is, before using QueryInterface, how would you even know that an IShellWindows item might support the IWebBrowserApp and IServiceProvider interfaces? For example, I don't see any documentation listing all the interfaces that an IShellWindows item supports.
MSDN does not usually tell you which interfaces a object implements but if you look around you will often find some documentation and related interfaces you can QI. And just to make it clear, a interface is just a contract and multiple objects can implement a certain interface so you can't really blame Microsoft for not having a definitive list.
Let's try to pick apart your specific example.
The object that implements IShellWindows (CLSID_ShellWindows) does not really have any other interesting interfaces, you just care about its list of windows.
IShellWindows -> (IDispatch ->) IWebBrowserApp:
IShellWindows has a collection of open Internet Explorer and Explorer windows. For whatever reason it just gives you a IDispatch for each window instead of letting you ask for a specific interface. Possibly just because IShellWindows is also scriptable by Windows Scripting Host/Visual Basic and IDispatch plays a big role there.
The Shell windows collection includes file explorer windows and web browser windows Internet Explorer and 3rd-party web browsers). Normally each Shell window implements IDispatch; IShellWindows::Item and IShellWindows::FindWindowSW provide ways to access a Shell window's IDispatch interface.
..and the connection between IShellWindows and IWebBrowserApp/IWebBrowser2:
exdisp.h contains the following programming interfaces
IShellWindows
IWebBrowser2
IWebBrowserApp -> IShellBrowser:
Objects that have access to the site chain of the browser can get a reference to the browser on IShellBrowser using IServiceProvider::QueryService, with Service IDs such as SID_STopLevelBrowser and SID_SCommDlgBrowser. See the Knowledge Base article Retrieve the Top-Level IWebBrowser2 Interface from an ActiveX Control for more information on using service IDs.
The fact that the web browser and shell are connected like this should be no surprise for people that were interested in Windows around the Windows 98/IE 4 time frame. Internet Explorer and File Explorer were basically the same thing; Explorer could display web pages and IE could display the "file list" (IShellView).
IShellBrowser -> IShellView:
just a simple call to QueryActiveShellView.
There is a key point here; IShellFolder/IShellView can be implemented by a 3rd-party shell extension. Explorer implements IShellBrowser and it is IShellBrowser that hosts IShellView, and 3rd-party ISVs can also create file browsers that implement IShellBrowser. In theory you could have a file explorer app created by one company hosting a shell view created by a different company with no Microsoft code involved. IShellBrowser and IShellView is how they see each other.
IShellView -> IFolderView:
There is no direct connection here but if you look around you can connect the dots.
IShellFolderView is supported by the IShellView object that is returned from SHCreateShellFolderViewEx
[IShellFolderView is no longer available for use as of Windows 7. Instead, use IFolderView2 and IFolderView.]
In other cases where you can't find specific documentation you just have to try to query for interfaces you are interested in. The shell also has a ton of undocumented interfaces and a debugger is your only choice if you want to experiment with those.
Thank you for reading at first.
I designed a WPF application which rehosted the Designer, Toolbox and Properties of Windows Workflow. My Idea is really simple that I just want have visualization at runtime about my workflow and design them in the runtime as well.
ISSUE:
Now I try to Invoke a Method of a class under the same namespace of whole application. The class is called MyTwsClass. Please have a look below:
It is extremely Simple. The TwsClass is from a Reference ActiveX of Interactive Brokers Trading Software. This ActiveX simply provide the method and event for you to communicate with your account. Alright, I implement the MyConnect() method as you can see and this method simply set up some string and int variables to be parameters of connect method from TwsClass. I noticed that I could not set MyTwsClass or MyConnect method as static.
Now, at runtime designer, I try to invoke the MyConnect method. First of all, picture below:
Since MyTwsClass could not be a static class with static method (I guess it is because it inherits from the ActiveX class TwsClass, I am not sure as a newbie.) So I wanna invoke the instance method. It has no complaints before running the workflow. After running this, I expect that I should be able to connect to the API of the trading software.
Now I run the workflow:
Right after clicking the running button, it runs and I got pop up window to tell me that APP has crashed with exception code C0000005. If I click the close option, my WPF application will be closed. BUT before I close it, I could see that ACTUALLY the crashed WPF actually connected to the API as you can see in picture above to tell me that 1 is connected......
I tried my best to check this problem on Internet. I am kind of have sense that it is all because of some issue within Interop or COM process between my WPF and the reference ActiveX as the crash window indicated that the TwsSocket.dll is the reason.
But I really could not figure out further.....
I am writing an Explorer extension for Vista and Windows 7. I read that if you are making a namespace extension you can provide your own commands using IExplorerCommandProvider. This is done in response to IShellFolder::CreateViewObject.
I am not writing a namespace extension, but a toolbar that lets you perform operations in Explorer. So I need to get IExplorerCommandProvider from an existing IShellFolder.
I get IShellView from the IShellBrowser, then I convert it to IFolderView, then I get IShellFolder. So far so good. I get a valid folder pointer.
This however doesn't work:
pShellFolder->CreateViewObject(NULL,IID_IExplorerCommandProvider,&p); // returns E_NOINTERFACE
I tried passing different values for the hwnd parameter of CreateViewObject, starting with the file pane and going all the way up to the top level Explorer window, and none of them worked.
So my questions are:
1) Do regular file system folders even support IExplorerCommandProvider?
2) If they do, how do I get my hands on that interface?
Thanks
Ivo
I'm working on a little macro record/replay tool which can automate a few very old Visual Basic 6 GUIs we have. To do so, I'm identifying the controls by their name (the value of the name property of a control, that is).
One part of this tool needs to determine the name of a control given its HWND. For newer Visual Basic applications which were done using VB.NET, I can use the WM_GETCONTROLNAME window message. This works nicely.
However, this message is not understood by older windows. Is there any way to do this for controls of Visual Basic 6 applications? A solution which does not require being in the process of the GUI would be preferrable, but if I had a solution which only works inside the GUI process then that would be acceptable as well (since I can do the injection myself).
UPDATE: One thing I just tried, this moderate success: I used the AccessibleObjectFromWindow to check for implementations of the IAccessible interface of the object which shows the given HWND. In case I get an implementation (it seems that many [all?] Visual Basic controls implement this interface), I use the accName property to read out the "accessible name". Sometimes this does yield a useful string, but usually it doesn't.
I believe the only way would be getting inside the process and obtaining a pointer to the Form object, yet I have no idea how to do it from outside.
Is it possible you add support for the WM_GETCONTROLNAME to those older applications?
Or maybe, you could identify the controls by some other, natively-available properties?
Other that that, as Raymond is saying, there isn't much you can do.
Can you modify the vb6 apps? if so in each form load event you could iterate me.controls and use the SetProp(ctrl.hwnd, "MYNAME:" & ctrl.name, 0) api to add the name to the window's own property list, then in your other app you can EnumProps(ctrl_HWND) looking for the one that begins with MYNAME: and parse out the value.
When using Visual Studio it is easy to extract an interface from a class that I have written myself. I right click on the class and select 'Refactor' then select 'Extract Interface'.
Let's assume for a second that I wanted to create a ConfigurationManager wrapper and write some tests around it. A quick way to do that would be to extract an interface from ConfigurationManager by right clicking it, then 'Go To Definition' and then from inside the class select 'Refactor' then select 'Extract Interface'. Then I would simply create my wrapper class, inherit from my newly created interface, and then implement it and I have a great starting point for my wrapper class.
However, extracting an interface from any .NET system classes is not possible, probably because it's just meta data about the classes and not the classes themselves (or I am doing it wrong).
Is there an easy way to do what I am trying to accomplish? I want to ensure I am not wasting time typing what I don't need to be typing.
Thanks
The problem is not so much to extract the interface - you could also do this 'by hand'
But you have no way to tell the CLR that the System-defined Configuration manager implements this interface since this (meta-)information is stored in the framework assembly which you cannot modify.
EDIT:
To ease the 'extraction by hand' you can click with the right button on the type and select "Go to Definition". Visual Studio creates a class definition (without implementation) from the metadata. You can then use copy and paste into a new file. Anyway you'll still have to do some modifications by hand
Replace the class keyword by interface
remove all non-public methods/properties
remove the public and override access modifiers (they are invalid in an interface definition)
This can be done easily using search&replace. You'll even get the documentation strings with this approach.