Sorry, I don't have much experience in programming and English and my question might be awkward. It relates to Windows 10 applications for classic desktop and touch screens.
I want to add a nice-looking touch-oriented Modern-style UI to my non-Visual Studio application. It is possible to call an external .NET assembly from my app and use its public constructors, methods, properties, and handle its events.
So I’ve created a new WPF User Control Library project in Visual Studio, replaced default User Control with a new Window, and built a dll file. Now I can use it in my app as described above. Everything seems to work fine.
Here are the questions:
Am I doing it right? Is building a dll from WPF project the only way
to make a UI dll that can be used in external applications?
How can I make the UI looks and acts like Windows Universal Apps (at least I want it to respond screen rotation)? As I understand I
cannot build a dll from Universal App projects and I have to create
WPF window, make it full screen, and add appropriate UI elements.
Is it possible to use Windows 10 contracts and extensions in such UI
dll?
If you want to share your code between different programs, you have to make it a shared library which is dll in windows. I don't know the other two questions.
Related
I want to write a desktop gadget that will group icons on my desktop (using c# & WPF).
It will be a docked window that I can drag icons to it and they will stay their. Also there can be couple of this windows.
Where do I begin?
**I saw all the post here about it but I got lost. Please direct me to examples and explanation pages.
To expand on cevik's answer:
You cannot create WPF applications as gadgets BUT you have two options (which aren't as bad as you'd expect).
The reason is that widgets are composed mainly of web pages (HTML) and not executable (*.exe).
The problem of course is that WPF will only work with & produce executables.
First option - Windows API:
When I said you can't what I really meant is you can't use the Windows Vista/7 gadget platform to make your widgets.
However, you can always achieve a similar effect by using the Windows API.
The Windows API will let you do stuff to windows such as making them always on the background of other programs, which sounds to me like ~80% there (The rest would be stuff like making sure your window doesn't get re-sized or minimized, etc.).
Just as a note, the function you'd be looking for to make the window behind all other windows would be SetWindowPos (specifically the second parameter).
However make sure there isn't a library which already implements these stuff because it can be rather difficult (and consist of A LOT of surprises).
Second option - Silverlight
silverlight can be perceived as WPF for the web.
That obviously solves our problem.
However there is a cost to it, as expected.
Silverlight doesn't have all the features WPF has (possibly not all of the .NET framework as-well, not sure about that as I'm not really using it).
However it should be more than enough to get you by so you should definitely check it out.
Once you have your Silverlight application (and webpage) you'll have to create a manifest & install the gadget to your desktop. See here how to do so.
Maybe this will help you.
Template to easily get started on developing a Sideber Gadget using Silverlight 3.0 or 4.0 controls in C#.
I am going to start a new (Right-To-Left) WPF project and the Main reason is to provide a single UI for the application in Windows and Web.
What Should I consider?
Which WPF Controls should/shouln't (can/can't) I use?
Do I Have to Use Silverlight? (I'm not interest)
Should I use XBAP project orWindows Project with Page base modules?
TIA
Your choices are indeed XBAP (WPF Browser App) and SilverLight.
You can easily google to find lots of comparisons, here is a short and simple one.
You main decision factor is your target audience. Do you want to support the Apple platform and maybe even Linux? Then use SilverLight.
If you're sure you only have Windows clients (Web and Desktop) you could use the more powerful WPF. But do write the WBA first so you don't run into permission issues later.
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
After toying a little with the new Silverlight 4 camera features, and being really disappointed that these were not included in WPF, I looked at the Silverlight assemblies and found that they more or less delegate all work to agcore.dll.
Do you think it is a good idea to package agcore.dll with my WPF application, and copy/paste or rewrite all classes concerning cameras to WPF, to get these nice features there?
That particular approach isn't likely to work, unfortunately. There's a lot more to getting C# code to work with Silverlight than just referencing the appropriate DLL. Silverlight is actually a completely different implementation of the CLR, so you can't just call into agcore.dll from a WPF app and have it run.
If you need Silverlight features in your app, I can think of two ways to get them: (1) you could conceivably host a completely separate instance of Silverlight inside a browser control in your WPF app, though communication with that Silverlight instance becomes complicated (though not impossible); or (2) you could write your entire app in Silverlight OOB (Out-of-browser)/trusted mode.
You can try VideoCaptureElement in my WPF MediaKit. It will show a webcam in WPF. It does have a different API than the Silverlight webcam API, but it should have just as many features.
I'm creating my first WPF application and I wanted to understand if there is some kind of best practice when mixing functionality from the System.Windows.Forms namespace.
Basically I want to have a popup window that opens by default in the bottom right hand corner of the users monitor.
I can't find a Screen.PrimaryScreen.Bounds equivalent in the WPF namespaces. The examples I have seen suggest referencing System.Windows.Forms in the WPF Application.
Which led me to the question, is this bad practice?, considering this reference isn't included by default.
I'm going to reference the WPF required resource in my existing windows forms application so that I can use this new WPF Window.
Is there anything wrong with this approach?
EDIT: I have actually found a property that returns information of the primary screen without referencing Windows Forms. The property is SystemParameters.WorkArea, my question of mixing references does still stand though.
Also you should consider resources and performance overheads as your application will have to load assemblies for both Windows Forms and WPF. It was mentioned several times within MSDN forums that WPF/Winforms interopping takes quite a lot of CPU cycles...
I don't think that referencing WinForms, when needed, is bad. Since WPF is still a relatively new technology, it just doesn't have complete feature parity with WinForms yet. For example, to my knowledge none of the standard Windows dialogs (Open File, Save File, Browse for Folder, etc.) have been implemented in WPF yet. The only way to display these in a WPF application is to use the WinForms version, or use P/Invoke to display the Win32 versions yourself. I go with the WinForms version personally, since they already took the trouble of wrapping the Win32 API.
My approach is to use WPF as much as possible, and only fallback to WinForms if WPF doesn't fill my needs. Hopefully over the next release or so of WPF this will become less and less necessary.