I'm learning WPF/C# by developing a litte application.
Actually, i'm trying to embed an exe, in my case a cmd, inside a specific canvas in my main windows.
I've found a lot of examples for WinForm but nothing for WPF.
I've search inside this forum, and others, but the only thing i find is for embed an application inside the main windows without control of position and style (using FindWindow and SetParent).
Is this even possible ?
If this is possible could you explain me how it works ? Code is good but comprehension is better ;)
Related
im trying to implement a toggle switch control in winforms c# i want to recreate the windows 8 pc setting toggle switch control as a metro ui (microsoft design style...whatever!)
http://cloud.addictivetips.com/wp-content/uploads/2012/03/Windows-8-PC-Settings-Sync.png
i need help or direction how to start to create the control?
you can look at my project at github:
https://github.com/viperneo/winforms-modernui
i have implemented an toggle switch control there
The best way to use these type of components, is using component dlls that have the feature already worked and developed with optimal performance, check these:
http://www.devcomponents.com/
http://www.devexpress.com/Subscriptions/DXperience/WhatsNew2012v1/winforms.xml
However, you can find open source projects, or examples of how to develop this in source code repositories like codeplex and codeproject, see this:
http://www.codeplex.com/site/search?query=metro%20components&ac=3
there is only one detail ... as seen in the link above, you will find more resources for these type of development in WPF.
Is it possible use Unity3d app written on C# as part of another WPF or winforms application?
Can i use it as user control?
Yes, it is possible to embed unity exe (PC build) into WPF using WindowsFormsHost.
I'm not sure if it can be used as user control because the unity exe is completely separated from WPF application.
Few time ago, when I had to work with Unity 3d, there was a way to embed it into WebBrowser control.
See this forum for more details.
Hope it can help you.
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 was just wondering if there are ways of creating my own custom winforms controls?
I've been plundering with Visual Studio 2008 now trying to do some c# apps. And the GUI end up looking terrible because of the standard winforms limitations.
And I noticed that I can add images to buttons for example, but ther's no hover effect. Or, the hover effect makes the whole button area gray. I don't want any of that, I just want to either create my own graphics for the controls or find some free (opensource perhaps) controls that already exist.
Any light on any of this, anyone? :)
You can write complete Winforms controls from scratch, doing all the painting and input processing yourself - you just create a class derived from 'Control' and get on with it.
There's a fair bit to making a first-class control which integrates nicely with the VS designer, so people tend to derive their custom control from an existing control which has most of the behaviour they want.
Here would be a good place to start: http://msdn.microsoft.com/en-us/library/6hws6h2t.aspx
I'm puzzled, you are doing WinForms development, yet in comments say you have done many months of WPF development, but WPF is not good enough because it is not cross platform.
How is WinForm more cross platform, and have you seen how ugly WinForms looks under mono on a Mac as it's draw via X11.
If you want style and cross platform, go for Flex or Silverlight, as your already know WPF I'd go the Silverlight route.
It's cross platform, and has all the beauty of WPF, but at the cost of reduced functionality out of the box.
First - may be more pragmatic to look at WPF, or hosting some WPF elements inside winforms (which is supported - like so). Other than that - you can do all your own painting if you want; but it is a lot of work.
Any reason why you don't use WPF? You have much more more UI control if you went down the route.
If you must go with WinForms then there are many commercial solutions like DevExpress. If you really want you own look and feel it'll be alot of work.
Yes. You can create your own controls. It is called a User Control. Just select Add->and User Control.
WPF is a good alternative if you want your windows form to look fancy.
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.