I'm trying to set up a C# application which uses TWAIN example from code project
This works fine except that I need to cast Form to IMessageFilter and
call IMessageFilter.PreFilterMessage() to catch TWAIN callbacks.
Also I need to start this filtering by calling
Application.AddMessageFilter();
Is there a way to do same thing in WPF Window? (To add message filter and catch TWAIN callbacks).
Another totally high level question:
Does anybody know about alternative C# TWAIN libraries\wrappers?
Thank you.
I've just wrapped up the code from Thomas Scheidegger's article (CodeProject: .NET TWAIN image scanning) into github project
I've cleaned up the API a bit and added WPF support, so check it out. :)
It has a simple WPF application that shows how the message filtering works with WPF.
You could try it with the ComponentDispatcher.ThreadFilterMessage event. As far as I understand, it serves the same purpose in WPF as Application.AddMessageFilter() in WinForms.
I thought TWAIN is considered obsolete. Maybe take a look at WIA, that does this job since WinXP. There is also a sample at codeproject.
About the WPF related question, no idea, I only used it in windows forms apps.
Related
I have been working for quite a while on a simple graphics engine in C++ using Direct3d 11. I have decided to try and build a GUI just for fun, and after reading some on WPF, I really got fond of it. Thing is, i'm not sure if what I want to do is even possible.
What I would like to do is to load my engine DLL in a WPF application, and use the DX device inside a portion of the WPF window. Basically, what I want to do is similar to a map editor( where the main window has a bunch of controls and a child window that contains the render area - the device ), but instead of converting my engine to XNA, I'd like to use the already working C++ code with WPF. Is that possible?
Also, I have tried just for practice to create a window with Win32 and attach the device to it. It was a simple matter of just assigning the window HWND to the device upon device creation. I assume its the same with a WPF window, or am I wrong? Thank's for reading :)
Edit: Forgot to mention that I'm a complete novice with C#, but I do know you can import a C++ DLL and use its functions, I'm just no sure about the device - wpf window interaction.
WPF supports embedding D3D surfaces.
Start here http://msdn.microsoft.com/en-us/library/system.windows.interop.d3dimage.aspx
WPF mainly works with managed code. Managed code means most of the things are taken care by garbage collector. And as I can see from your post You want to integrate C++ dll which is unmanaged code. It is not so simple using C++ library in WPF but not impossible. C# provides many other aspects to handle these kind of scenarios.
You will have to take a look about Interoperability and unmanaged code.
Have a look on below link:
Sample Project
For the WPF/D3D11 interop, have a look at WPFDXInterop that was written by a Microsoft engineer. This allows you to have a D3D render target inside a WPF window, with proper interaction. There's a sample project at the link.
I'm developping a SmartDevice application (Pocket PC 2003 template) in C# for a device with Windows Mobile 6.1. I need to use the camera of this device (photos, video); to do this work i tried using the CameraCaptureDialog class but it does not work for Pocket PC applications.
So, I documented on the internet and found that I probably refer to DirectShow API, but the problem is that I do not know where to start because I can't found a working/correct example.
My questions:
Is this the right way? Are there alternatives?
Where I can find a very good example that shows how to do this work?
You may try directshowbetcf: http://alexmogurenko.com/blog/directshownetcf/ if you really want to go with DirectShow and NetCF.
There's plenty of examples of directshow on the web. There is a site dedicated to converting the API over to C# which makes it a lot easier, maybe this was it http://directshownet.sourceforge.net/about.html. I struggled with DirectShow until I read the book "programming directshow" from microsoft press. About a third of that way through that book it all seemed incredibly easy and I was able to complete what I wanted. In the end it's a lot like referencing any library and using the classes from within that library. The added difficulty is that you need to add wrappers because they are all COM objects but that has been done for you.
This might be useful to you to understand the DirectShow technology. Basically gives a start to DirctShow and explains some of the important points. But its C++ not C#. Hope this help
Basic Video Capture
DirectShow is the video capture API in Windows Mobile 6. There is a Video Capture Filter there and all in all things are designed pretty much the same way they are in Windows.
The problem is that however that this is a native API, and not just in Windows Mobile. To develop in C# you need some bindings and they are missing. On desktop there is DirectShow.NET, which is a missing piece, but it does not seem to fit well for CE. Yet you still need to fill this gap in Windows Mobile.
To work it around you have a few ways, the first would be to go through DirectShow.NET and update it appropriately to start working on your device, strip parts missing in mobile OS etc. This would get you a twin for DS.NET but for mobile operating system.
Another option would be to do some C++ development and implement the minimal sufficient feature set in that domain, exposing the component via COM. Then you will reference this from managed code and things will get connected together. And another obvious option would be to use a third party solution which already does one of the mentioned above.
Please say name of this component and does c# have it?
As others have suggested, this is commonly called an Outlook Bar after it's most famous usage in the Microsoft Outlook application.
Something similar is available in most third-party control suites, but if you're looking for something that is free and easily customizable, you might check out the OutlookBar control available on CodeProject:
The control itself is pretty simple, and implemented entirely in managed C# code as a UserControl.It should work under all versions of the .NET Framework back to 1.1, and is painless to integrate into your application. Best of all, with the source code freely downloadable, it's infinitely customizable to fit your specific needs!
I think it is called accordion, at least in jQuery.
And I do not know of any such in the basic controlles that comes with c# but I am cetrain that there are many 3:rd party components like this.
ComponentArts or Telerik are the first that comes to mind.
In WinForms, this is called an Outlook Bar or Navigation bar.
Most (if not all) third-party control suites, such as DevExpress, offer it.
I think its name is Accordion and it doesn't exists natively on Windows Forms Architecture.
Accordion ? Try searching among different control toolkits - there should be an implementation.
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
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.