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.
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 need to simulate mouse clicks/touchscreen presses and key presses in Windows 8.1 (.NET 4.5, WPF). This is for crude unattended automation for certain processes/applications (all external to the application I am developing) whereby there is nothing exposed to allow me to do it any other way.
A few years ago in .NET 2.0 and WinForms I did something similar using the SendInput API.
Is that still the de-facto method to achieve this in .NET 4.5 and WPF, or is there something newer that has come along, or maybe even a WPF wrapper for SendInput?
This kind of automation could be done Microsoft's UI Automation framework. For better understanding have a look at http://msdn.microsoft.com/en-us/library/ms747327(v=vs.110).aspx
A also nice introduction can be found at http://blog.functionalfun.net/2009/06/introduction-to-ui-automation-with.html
I had to do this just the other day to automate the process of waking a machine up from sleep mode, mouse_event seems to still work fine in Win8. Haven't tried the key events, but I don't see why they wouldn't work also. There's some functional interop code here.
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.
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.
Windows API
So i know that the WinForms touches on the Windows API a little, but frankly its horrible. ESPECIALLY with the layered windows and flickering. So i was wondering if anyone has wrote partial, or full wrappers for the Windows API.Im particularly interested in the Layered Window aspect, but really any part of the API is a good place to start.
Update: I found the Windows API Code Pack here: http://code.msdn.microsoft.com/WindowsAPICodePack but it seems that it doesnt wrap Layered Windows? Am i correct in assuming this?
Native API (Windows)
Ive heard a little bit about the Native API, but im not quite sure what it is for? what features does it provide? would it be a good idea to look into?
Summary (Questions in a nutshell)
Does anyone know of an existing (partial or full) wrapper of the Windows API?
If the answer is no to question one, where would be a good resource to learn about it myself, and potentially write my own?
An explanation of the Native API? What does it do? Can I use it to make applications better? Can I even USE it at all?
An answer to any of those is highly appreciated :) thanks
You could start at PInvoke.NET.
The LayeredWindows actually work better in WinForms than windows.
The native windows controls don't even have the alpha channel support of the WinForms analogues, so native windows flicker, and require massive amounts of subclassing to override the painting to use alpha compatible routines.
You would be better off going to WPF. The windows team has not treated the native control's well at all, going so far as to remove support for a style (WS_EX_COMPOSITED) if aero glass is enabled which, given the way that windows controls paint, effectivly made it impossible for any application to paint flicker free if it uses child window's as controls.
WPF "draws" windows controls, but does not use discrete (native) child windows to represent individual controls. This gives it control over when and how its window surface is rendered.
The Windows API is huge. There is a ton of stuff in it. Windows Forms is a wrapper of parts of it. WPF is a wrapper of parts of it. Parts of the Base Class Libraries (eg System.IO.*) are wrappers of parts of it. The Code Pack is a wrapper specifically of things that were new in Vista and Windows 7 and not in Windows Forms or WPF.
Have you looked into WPF? Combined with P/Invoke of specific API functions, it might take you a long way towards where you want to be.