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.
Well, I am still working on the Windows 7 version of my Rich Text Editor project, and still have a lot more work to do.
I am completely redesigning the API, and adding a lot of new functionality, such as the ability for AddIns to add new toolbar themes.
The Windows 7 Task Dialogs and Open/Save file dialogs have been implemented with some difficultly, explained in my 'The Windows API Code Pack' message below.
As this is mostly a straight port from the original VB version into C#, I was using some online code converters to cut down on the amount of typing. All of the converters I have tried use NRefactory, and it seems that NRefactory cannot handle inline functions in VB. All I could get is an 'Invalid Expression' error.
EDIT: NRefactory cannot convert the following class (Where in bold):
CONVERSION ERROR: Code could not be converted. Details:
-- line 16 col 12: "Get" expected
Please check for any errors in the original code and try again.
So it wants Public Get ReadOnly.....
EDIT2: The error occurred because of the Auto-Implemented property above the error line. Stupid error message.
I think it will be faster to rewrite it by hand!
On a side note, it seems Visual Studio 2012 tries to run code after importing it from another project. I found this out when I imported a control from one project that used a static property from another class to create a full path, and VS gave me a 'Path Cannot Be Null' error on that line, and crashed the designer. When I switched that line to use another property that gave the same path (the first property was initialized with the value of the second [the first property is in a port of the ICSharpCode.Core PropertyService class]), the designer worked fine. VS2010 did the same thing, so I think it is a goof in the Intellisense parser system.
Not sure when it will be out, as I have run into a number of Visual Studio 'Features' that aren't all that helpful, such as the 'Code Running at Design Time' and some weird formatting errors (some syntax highlighting goofs, although there are less of those than there were in VS2010), as well as randomly changing indentation. It should (hopefully) be within the next few weeks, though.
I used to, but I am now moving fully into C#. I started out with VB, and always compiled with Option Strict On, and tried to never use the 'Shared Instance Methods' thing VB has. I always used either a singleton form or the My.Forms namespace.
Visual Studio 2012 tries to run code after importing it from another project
This is a general problem with Visual Studio, especially with WPF projects. I have it regularly with Visual Studio 2008. The XAML designer routinely fails when supporting classes don't compile cleanly, as is typically the case when you're refactoring. They rely on the runtime to do the heavy lifting while you're editing.
It's almost like a return to the days of the Ada development environments, where you had to implement from the bottom up because the compiler failed otherwise.
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.