static readonly Guid IID_IDispatch=new Guid("{00020400-0000-0000-C000-000000000046}");
[Guid("00020962-0000-0000-C000-000000000046")]
[InterfaceType(ComInterfaceType.InterfaceIsIDispatch)]
public interface IWordWindow
{
}
[DllImport("oleacc.dll")]
public static extern int AccessibleObjectFromWindow(IntPtr hwnd, uint dwObjectID, byte[] riid, out IWordWindow ptr);
[DllImport("user32.dll")]
public static extern int BringWindowToTop(IntPtr hwnd);
[DllImport("user32.dll")]
public static extern bool ShowWindow(IntPtr hWnd, uint nCmdShow);
[DllImport("user32.dll")]
public static extern bool IsIconic(IntPtr hWnd);
[DllImport("user32.dll")]
public static extern int GetClassName(IntPtr hWnd, StringBuilder lpClassName, int nMaxCount);
public delegate bool EnumChildCallback(IntPtr hwnd, ref IntPtr lParam);
[DllImport("user32.dll")]
public static extern bool EnumChildWindows(IntPtr hWndParent, EnumChildCallback lpEnumFunc, ref IntPtr lParam);
The interface IWordWindow is the IDispatch COM interface for the Word COM object. If you want to use another Office Program, you'll have to adapt the Guid attribute (see MSDN).
First of all we need the process of Word
August 30, 2012
C# Office Communication without COM Reference
Lately I needed to communicate with Microsoft Word from C#. Well most programmers would use a reference to the COM library which is provided by Microsoft. For some reasons I don't want to use these libraries. One reason is the version problem. Let's say I'm linking the COM library which was implemented for MS Word 2007 and use it's interfaces etc. I won't be able to run this program on a machine having MS Word 2003 or MS Word 2010 installed.
To keep the whole story short, I'd like to show you a way how you can communicate with Microsoft Office without linking the COM libraries. The following sample shows how to search for a specific string in a Word document.
Because I don't want to break the explanation of how the code works, I'll just post all DllImports, interface and class declarations here.
August 1, 2012
C# File OpenAs Dialog (Win7)
Some time ago I ran into something weird. These lines of code worked perfectly the last years in order to show the open as dialog on Windows XP but stopped working on my x64 Windows 7 machine (it would have stopped working in Vista too, but I skipped this version).
ProcessStartInfo startInfo=new ProcessStartInfo()
{
WindowStyle=ProcessWindowStyle.Normal,
FileName=fileName,
Verb="openas",
UseShellExecute=true,
ErrorDialog=true,
};
p=Process.Start(startInfo);
Well to solve this issue I needed to check how the system used to show the open as dialog. As a result, I ended up with this line of code which brings up the open as dialog as usual.
p=Process.Start("rundll32.exe", string.Format("shell32,OpenAs_RunDLL \"{0}\"", fileName));
By the way, you'll need both versions if you want that your application works on Windows XP and later versions. This line indicates whether the application is running on Windows Vista or later.
Environment.OSVersion.Platform==PlatformID.Win32NT && Environment.OSVersion.Version>=new Version(6, 0, 6000);
March 16, 2012
Skype [beta] for WP7
I was wondering where I can download Skype beta for my Windows Phone 7 but I just couldn't find it in the Windows Phone Marketplace.
Well, if you are searching for it too, use this direkt link on your WP7 :-)
zune://navigate/?appid=c3f8e570-68b3-4d6a-bdbb-c0a3f4360a51
I found this link somewhere on the skype website - but very very hidden.
January 19, 2012
IntPtr Navigation
Have you ever wrote something like that?
Such code is often necesary when invoking the Win32 API. Well this code works well unless you're not running this code on a x64 machine.
When running on a x64 machine you might get a nasty surprise as soon as the pointer's address is above int.MaxValue. To fix this problem you might use the following code.
There also exists a static Subtract method which let's you decrease the pointer's address.
IntPtr ptr=...
Marshal.PtrToStringUni((IntPtr)(ptr.ToInt32()+wDeviceOffset));
Marshal.PtrToStringUni((IntPtr)(ptr.ToInt32()+wDeviceOffset));
Such code is often necesary when invoking the Win32 API. Well this code works well unless you're not running this code on a x64 machine.
When running on a x64 machine you might get a nasty surprise as soon as the pointer's address is above int.MaxValue. To fix this problem you might use the following code.
IntPtr ptr=...
Marshal.PtrToStringUni(IntPtr.Add(ptr, wDeviceOffset));
Marshal.PtrToStringUni(IntPtr.Add(ptr, wDeviceOffset));
There also exists a static Subtract method which let's you decrease the pointer's address.
Subscribe to:
Posts (Atom)