The Lounge is rated PG. If you're about to post something you wouldn't want your
kid sister to read then don't post it. No flame wars, no abusive conduct, no programming
questions and please don't post ads.
Sucks. Yes it is useful, but WHY ON EARTH did they put WinForms and WPF stuff in the same assembly?!??! Some applications would never use the WPF stuff, and trying to take it out is a lost battle, as the WinForms related stuff uses the WPF related stuff, and vice-versa. This just adds useless references to projects, and causes a lot of headaches.
You would think Microsoft would be smart enough to....... ummmm, never mind.
The Windows API Code Pack has WinForms and WPF stuff in the same assembly, requiring a WinForms application to reference the WindowsBase, PresentationFramework, etc libraries, even if they are not used by the application using the Windows API Code Pack!
The Win API Code Pack 1.1 was released in early September, 2010: that's a few epochs ago in devtools time. I suspect with Visual Studio 2010, and Win 7, there are other ways to get the functionality once provided by that code pack. That API pack is now in the MSDN Archive: what does that tell you ?
I'm curious why you are using this, and how (on XP ? on Vista ?), and what specific facilities are you using where you see WinForms stuff dependent on WPF: those two technologies are really mutually exclusive on fundamental levels, imho.
Why not post a detailed statement of your goals, and experiences with the API Pack, on the WinForms, or WPF forums ?
Perhaps these resources on NuGet would be helpful: [^].
"We live in a world ruled by fictions: mass merchandising, advertising, politics as advertising, instant translation of science, technology, into popular imagery, increasing blur of identity in realms of consumer goods, preempting any free, original, imaginative, response to experience by the television screen. We live in an enormous novel. For a writer it's less necessary to invent a novel's fictional content: fiction's already there. A writer's task is to invent a reality." J. G. Ballard, 1974
I am using this in the Windows 7 Specific rewrite of a rich text editor I am creating. I am using the libraries for Task Dialogs, taskbar support, the common open/save file dialogs, etc. I do not know of anything else that has the functionality of the Windows API Code Pack, which is why I am using it.
The code of the libraries is kind of messy, but I think that is to be expected. I gave up and added the references, and I might actually use some WPF controls I have found in the application. So, not all is lost, this just might be a blessing in disguise.
The WPF stuff will be a while, though, as I just want to get the application functional first. Right now only about 10-15% of the application is implemented. I should be able to release it when it gets to about 70-75% done, as the rest will be optional AddIns for scripting and a web browser.
This is because CON is a MS-DOS device file. You cannot create a directory with this name for the same reason you cannot create a directory called COM1 or COM2 etc or LPT1.
Because they are reserved for MS-DOS use.
Imagine trying to create a directory called "C:" and think of the ensuing problems from doing that. This is also why the character : is invalid for a directory/file name.
"Bush Hid The Facts"
Opening the file shows me the exact contents that I saved into it, no change.