What library is used to create a window form like below?
It certainly does not look/feel/acts like a typical windows forms app.
Spy++ says it's a Windows Forms app, with a Web Browser control embedded for the bottom portion (window 004109AA, bottom). The tabs too are a Windows Forms control (window 006B0D26, 5th from top).
spy++ http://img10.imageshack.us/img10/7308/spyf.png
If you use Spy++ you can see what it is based off of the class name of the window. It looks like it could be WPF or HTML.
Related
Is the stuff that is displayed when you create a GUI with WinForms or WPF still based on the native controls like Common Controls or any of the system provided Window Classes or is everything that is displayed "custom" drawn by the framework?
Note: I'm not talking about stuff like a file dialog, but GUI that was actually implemented with WinForms or WPF.
And yes, this is purely out of interest.
User HighCore commented:
WPF Uses an "HWND" for the Window objects, but then all other objects
(Controls) inside the Window are WPF objects not related to Win32 in
any way, wheareas AFAIK, winforms uses a separate HWND for each UI
element.
And indeed, using Spy++, we can observe the following when we create a test app with a simple dialog/window and a button on it:
MFC/native:
The app window is a Window (HWND) with the Window Class of #32770 (Dialog) (I used a "Dialog based" app.)
The Button is a separate Window (Class: Button)
Windows Forms:
The app window has the Window Class WindowsForms10.Window.8.app.0.2bf8098_r20_ad1 (oh my)
The Button is a separate Window (Class: WindowsForms10.BUTTON.app.0.2bf8098_r20_ad1)
WPF
There's only one top level Window, although for good measure I added a ComboBox, a ListBox, and a Menu to this window in the UI designer.
The Class of the only Window is: HwndWrapper[WpfApplication1.exe;;9b1aec0f-1b88-419c-8730-858906314cd9]
The Window Class names are actually quite interesting: With the MFC/native one you get the classes known for years and documented on MSDN. With Windows Forms, it does appear that it always uses the same class names. And with WPF it seems the name of a Class of a Window also incorporates the executable/process name.
So apparently MS thinks that using more than one Window per window isn't necessary anymore. I think I need to open a second question for that.
Windows Forms uses native controls for some UI elements. WPF draws everything on its own.
We're developing in WPF and are using custom borderless windows like the new Office 2013 windows. Now we are creating CHM help using RoboHelp.
I'd like to know if there's a way to launch a CHM file, but somehow hook into it so that it loads in a custom window that I specify, rather than the default window. Even better would be some kind of CHM display control that could be embedded in a WPF window, analogous to the way you can embed an HTML browser control in a WPF window. That way I could compile the CHM content with RoboHelp, but display it in our own custom borderless window that's part of our application.
CHM is no longer supported by MS since Vista, so you might want to consider using RoboHelp to generate Webhelp instead, and display that in a browser control as you described. Webhelp also supports context sensitivity via the URL, if that is needed.
[EDITED]
After several tries, I found out it was the Microsoft WPF Ribbon that causes the title bar style not rendering correctly.
Application without Ribbon in XP:
Application with Ribbon in XP:
I have already set the theme to be XP style. Still not fix. It is a bug in Microsoft Ribbon or am I missing something? On Window 7, on the other hand, renders OK.
Develop on WPF C# .NET 4, VS2010.
Why do you care? this is a user setting to have Aero enabled or not in Vista or 7 and theming enabled or not in XP like in 2 and 3 pictures you sent.
In general you should ignore this. Office 2007 and 2010 with ribbon UI renders the same but because ribbons are skinning the application windows completely.
My suggestion is to either use skins and do the same or simply ignote this because if I use Vista with Aero enabled I would not like your App to look like classic Win2000 applications.
This is anyways an issue with the window title bar as it will use the default theme of the OS you are using.
I suggest you to neutralize the style by implementing a custom window style that takes the windows 7 look n feel for all windows ion your applications. Have a look at the MessageBox control from latest extended WPF toolkit.
It has a windows 7 style themse that looks exactly same on all the above OS if you use
Window.AllowsTransparency="False"
Window.WindowStyle="None"
Window.Style="{StaticResource Windows7WindowStyle}"
I'm looking to put an application window behind all other windows.
I was thinking of using .NET 4 and WPF or Silverlight.
I don't have any specific drawing code, I just want my application window as my desktop wallpaper while retaining the interactivity (no mucking around with screenshots etc).
Is this even possible and if so, how?
Edit: I'm using Windows 7 x64.
Edit 2: I know the desktop is drawn to a window with id 0 (or something like that). Can't I use interop calls to put my window as a child of window 0?
For Windows XP and previous versions, use Active Desktop ad set a web page that runs a Silverlight application.
I have a Winforms app that was originally created in vs 2005 and that was converted to vs 2008. When running this app in Windows 7, the menus don't look like the standard menus in Windows 7 (i.e., the formatting for the menu items is different than the formatting for other applications). This applies to menus displayed on the menu bar of the application as well as the right-click context menus. FYI, I am using the System.Windows.Forms.MenuStrip and the System.Windows.Forms.ContextMenuStrip controls.
Does anyone know why the menus aren't rendering with the default Windows 7 look and feel?
MenuStrip uses a custom renderer, it doesn't leave it up to Windows to draw the menu. You can change the RenderMode property to System but that doesn't help, it's a pre-Win7 version of what system-drawn menus looked like. If you want Windows to render the menu then you'll have to fall back to the .NET 1.1 MainMenu component. Another way is to assign the Renderer property to your own custom renderer, not really practical.
This is also an issue with WPF, worse because it renders all the controls itself. We are quickly approaching a stage where the look-and-feel of a program is determined by the UI class library, not the operating system.
If you have any OWNERDRAW items in your menus, Windows 7 will revert to a backward compatible drawing mode to avoid breaking your code. Do you override the drawing of any of the items?