Long time listener, first time caller. Does anyone know of a good interop library for the Win32API?
I found pinvok.net which is OK.
(FWIW I got the addin to work with MSVS 2010 by following the instructions here:
http://www.red-gate.com/supportcenter/GeneralContent.aspx?c=knowledgebase\PInvoke\KB200711000198.htm
and using 10.0 instead of 9.0)
...and the Windows API Code Pack 1.1 from MSDN seems not to have the basic Win32 stuff from user32.dll or am I missing something?
More specifics...
I am trying to take an external window and make it a child of a control in my managed System.Windows.Form (embedded GUI in a panel or tab of my main form). Researching here and on google it seems like Win32/user32.dll is the way to go. My application is a framework that launches 3rd party GUIs (dlls and exes). The 3rd party code/forms are all unmanaged (mostly MSVC) code. These unmanaged forms are launched from within my process hierarchy. My preference would be to stay in .NET if is possible.
The best interop library available is the .NET Framework. User32.dll is wrapped very well by Windows Forms.
The Windows API code pack concentrates on wrapping API additions made in Vista and Win7. Those were not additions to user32, mostly shell stuff.
You'll probably get a better answer if you can be specific about exactly what user32 APIs you want to use.
After seeing edit: what you are trying to do is explicitly forbidden by the Win32 SDK documentation. The parent of a window must belong to the same process. There are however some appcompat hacks in Windows, designed to support Windows 3.x programs where this restriction did not exist. Because it didn't support threading.
You can try, but beware you'll void the warranty. P/Invoke SetParent(). Visit pinvoke.net for the declaration you'll need.
Much of the Windows 32 API is exposed in .NET in the framework itself - so it's rare that you need to P/Invoke into user32.dll. You're better off using the managed versions of the framework.
When you do need to setup a P/Invoke call, pinvoke.net is a great resource for the specific API required for a call into most of the Win32 API.
Related
I just got back from Microsoft Build 2018 where they announced .NET Core 3 support for WPF applications. This is great because I can finally start using some of those cool fluent design things that are available for UWP. The only problem is, it's not getting released until next year.
I started looking into converting my app to a UWP app (because I'm impatient) but I'm running into some challenges. Mainly hardware. Talking with a few guys at Build, they made it seem like it was possible to write UWP apps that connect to low-level Win32 drivers for communicating with hardware (HID printers, card readers, bar code scanners, etc). I'm not having any luck finding information about this. Just to be clear, this is not an app I want to release to the Windows Store. This is a kiosk app that runs on our own hardware.
How does one access Win32 APIs for hardware integration in UWP?
Your best bet is likely to use P/Invoke, which is technology designed to allow .NET code to call unmanaged code. Assuming that your hardware is accessed through Win32 APIs in a DLL, this may be your best option.
The pinvoke.net Web site provides specific examples of the .NET code needed to call a specific Win32 API. Perhaps those examples can help you get started.
UWP app written in C++/CX has access to the Win32 and COM APIs that are part of the Universal Windows Platform (UWP).
The APIs in Win32 and COM APIs for UWP apps is only for C++, you can not use the C# to access it directly. Please see Visual C++ Language Reference (C++/CX) to get more details about C++/CX.
But, you can create a Windows Runtime component in C++/CX, then call it from C#, you can see the Walkthrough here:
https://learn.microsoft.com/en-us/windows/uwp/winrt-components/walkthrough-creating-a-basic-windows-runtime-component-in-cpp-and-calling-it-from-javascript-or-csharp
I'm looking for a library that can be used in native .NET code, just like any .NET assembly. The purpose of the library must be to automate Windows (push a button, select a window, send keys, record & playback, that sort of thing).
So: the library is supposed to be used natively in .NET, but the automation itself must be able to target any native or .NET Windows application that can receive user input.
Suggestions so far:
benPearce suggested AutoIt. It has a DLL, which is native Win32 but not native .NET and cannot be used without use of .NET Interop.
Chris Dunaway suggested Global Mouse Keyboard Lib. This came closest, but is not an automation lib. It just helps setting up keyboard and mouse hooks.
pm100 suggested Microsoft's WPF UI Automation. This one is pretty good, albeit that it's not available if you develop in .NET 2.0 and it requires the WPF to be installed on the system. It can, however, automate everything from Win32 apps to HTML in a browser.
JasonTrue suggested WebAI from ArtOfTest. This is a testing framework mainly geared towards browsers and web applications. It is unfortunately not well suitable for use for Windows automation.
If nothing else appears available, I'll probably choose Microsoft's UI Automation and upgrade any projects that require it that are still in .NET 2.0 to .NET 3.5, if possible. But I hope for a more widely applicable automation framework (.NET prior to 2.0 does not need to be supported).
Have you looked at the White framework?
I have used AutoIt in the past with success.
microsoft's own built in one is fine
http://msdn.microsoft.com/en-us/library/ms747327.aspx
not restricted to wpf as some seem to think.
If you haven't seen it yet, and a commercial library is acceptable, you might check out Ranorex:
http://www.ranorex.com/
I used Ranorex 1.5 quite a bit to write small C# UI automation utilities. It was pretty effective! Development seemed faster compared to using the MS UI Automation API directly, since Ranorex has a lot of useful convenience methods already available.
I haven't used Ranorex 2 very much yet, though.
In Ranorex 1.5, there was also support for traditional Win32 development in C++, but I didn't use it. As far as I know, that's still available in Ranorex 2.
I can't speak to the quality of the record/playback support in Ranorex since I never used that feature.
One final plus: Their support team was really responsive and helpful anytime I emailed them.
This library is pretty interesting and is fairly simple. Perhaps it will help you.
Check out Tools for automated GUI testing on windows
I would still suggest FlaUI for autoamating .Net Desktop,Mobile apps. Its based on Microsoft UIA libraries and have support for external controls like the DevExpress Grid too
Moreover, it is built on top of TestStack.White so indeed a very good library and has a github page also
I have used WebAii from ArtOfTest with a fair degree of success in automating integration testing for a Silverlight app. It also supports WinForms and Web applications.
Microsoft UI Automation, the successor to Active Accessibility, can do almost all of the Windows UI automation you would need.
How about CSharpScript, here's an article about it on Codeproject, and here's the link to the main website. Furthermore, it is familiar C#, scripted which can be used to automate anything.
Hope this helps,
Best regards,
Tom.
This is what I need to do.
I must create an ActiveX (IE add-on) in C# to show image(s) on client (load image(s) from Twain Scanner).
I have made Windows Form and use System.Windows.Forms.PictureBox but it need .NET framework installed on client PC.
Any ideas are appreciated. Thanks so much.
Everything written in C# requires .NET framework to run. Either the full framework or Silverlight.
If you want to write an ActiveX that is independent of the .NET Framework you have to write it in another language, such as C++ or Visual Basic 6.
I'd recommend that you really, really, really try to get out of the ActiveX requirement and instead use AJAX or Silverlight.
If you use C# to create an ActiveX control, then yes: it will require the .NET framework at the client. You cannot change that.
If you want a non-.NET control, VB6 (though obsolete) may be simplest. AFAIK Silverlight does not offer access to scanners, so is not an option.
I also suggest, however, that ActiveX itself is already imposing a lot of demands (mainly: IE). I wonder if something like a ClickOnce client application is more appropriate. Or: just provide upload (input type="file") controls.
I'm trying to automate a hidden .NET application, with another .NET application (written in c#) using the easiest way possible. It's NOT for testing purposes, it's a way to fulfill the lack of scripting for this application.
I already tried white framework, but there is one major problems with it: the way it's working. It's slow and it's not working on hidden windows and controls (like the winAPI does). Whats more, when "clicking" white moves the mouse, brings it's targeted window to the front and so on.
I was also thinking about using a user32.dll wrapper, because the way it's handling it's target is what I need, but I've red it's not working with .NET applications. It also would be a problem working with it, because my targeted application got 5 button labeled "...", and would be really hard finding 2 of them I need. I also would like to use the controls .NET id (the name the developer gave to it's controls when designing the GUI).
BTW, my targeted application is MeGUI if that helps. We do a lot of video encoding and a tool like this would help us a lot. I need the MeGUI to be hidden, because I'm the only programmer, others using my tool shouldn't see what happens in the background, not to talk about the many windows popping all around.
You can add a reference to the exe from your project and then create an AppDomain to run its main method. From there, it should be possible to queue delegates to its main thread's loop. With a bit of reflection, you could have those delegates invoke the click events and whatnot directly.
I've never attempted this approach, but it should work.
You should try Stephens idea instead of scripting a hidden app. A .NET Windows Forms App (EXE) is still a .NET Assembly and that means you can use that the same way as a DLL, just add a reference and use the public classes.
If you still want to try some scripting, take a look on the "Microsoft UI Automation" API and the "System.Windows.Automation" namespace.
Nice article here: http://msdn.microsoft.com/en-us/magazine/cc163465.aspx
MSDN Doc: http://msdn.microsoft.com/en-us/library/system.windows.automation.aspx
I would like to know, if I use WndProc in my C#.net app to handle minimize event in my form, will there be any problem if my app will be installed in different version of windows or other platform? like xp, 2k3 and so on?
Unless you do it wrong, no.
Native C apps work the same way, and they work on all versions of Windows (assuming that they are written correctly).
In general, if you go beyond WinForms and start using WndProc or Win32 API functions (P/Invoke), I recommend that you read Raymond Chen's blog, which describes many common pitfalls when working with native window methods.
No. WndProc is wrapping a standard windows API that has existed for many, many years, across Microsoft's platforms.
The Minimize events are very standardized, and will work on any MS platform with no issues.