How exactly are you copying the data from the response stream to the file stream? Another thing to consider is that looking at memory usage in the Task Manager (which is what I assume you are doing) can often be misleading. The allocated memory listed for a .NET-based application often includes memory which has been collected (i.e. released) as far as the application goes, but which simply hasn't been given back to the system by the runtime. However, that memory can be given back if and when the runtime believes the system needs it. If there are specific performance (memory or CPU) requirements for your application, then I would suggest using a profiler to help determine where the bottlenecks are in your application. -Phil

Have you ever heard of Microsoft Visual Studio Tools for Office (VSTO)? It allows one to automate Excel documents using .NET (in C# or VB). It supports dragging-and-dropping WinForms controls onto the worksheet. In addition, you can cache arbitrary data (e.g. the state of the controls) within the document and retrieve them outside of the Excel host environment. For more information: Visual Studio Tools for Office -Phil Disclaimer: I work for Microsoft as a developer on the VSTO product team.

Shouldn't the statement: String sName = (String)oRes.InvokeMember("cName", BindingFlags.GetProperty, null, o, null); be String sName = (String)oRes.InvokeMember("cName", BindingFlags.GetProperty, null, oResult, null); -Phil

There are a number of algorithms that have been developed to determine the similarity between strings (either spelling-wise or pronunciation-wise). A quick Google search brought up this[^], which should give you a good starting point. -Phil

Is there a reason why you're not using the common OpenFileDialog? Unless there is some technical reason or compelling user scenario for not doing so, I'd suggest using the common Windows dialogs because they help to keep a consistent user interface across applications and therefore breeds familiarity for the user. In addition, if Microsoft decides to revamp the dialogs, your application will automatically inherit the improvements. Plus, it's a lot less work. :-) Anyway, just my humble opinion. I realize that the common dialogs won't work well in every possible situation. -Phil

You should be able to include the common resource file in each project, though you may have to do this by hand-editing the project files (.csproj). For example, if both projects are at a peer level, with the resource file in a parent folder, you could include them in the project files like so: <Compile Include="Properties\Settings.Designer.cs"> <AutoGen>True</AutoGen> <DependentUpon>Settings.settings</DependentUpon> <DesignTimeSharedInput>True</DesignTimeSharedInput> </Compile> <EmbeddedResource Include="..\Resource1.resx"> <SubType>Designer</SubType> <Generator>ResXFileCodeGenerator</Generator> <LastGenOutput>..\Resource1.Designer.cs</LastGenOutput> </EmbeddedResource> -Phil

The answer is: it depends! Both XmlDocument and XmlTextReader/Writer are perfectly valid ways to read and write XML files. The reasons for choosing one or the other depend on how the application intends to use the XML files. XmlDocument allows one to add or query XML nodes at random. To do so, it has to load the entire document before it can be used and keep the document in memory. On the other hand, XmlTextReader/Writer are forward-only reader/writers. That is, they visit each node sequentially in a stream-like manner. This makes the classes very fast and light on memory, but at the cost of more limited capabilities and being somewhat more difficult to use. I often find myself using a combination of the two in my applications: XmlDocument to read and extract data from XML documents (because it's easy and flexible) and XmlTextWriter to write XML documents (because it's easy and fast). -Phil

You have a couple of options: 1. Do not derive from CollectionBase and instead implement ICollection and/or IList directly. This will allow you to either not include undesirable insertion/removal methods or, where those methods are required by the collection interfaces, to throw a NotImplementedException. 2. Derive from CollectionBase but override the protected OnInsert() and OnRemove() methods and throw a NotImplementedException. (You have to be careful with OnInsert(), though, as that will also get called for Add(), which you *do* want to allow.) -Phil

Here's one way to create the string "a" via reflection: Type type = Type.GetType("System.String"); object obj = Activator.CreateInstance(type, 'a', 1); In this case, the .NET runtime would use the System.String.String(char, int) constructor in order to create the instance because we passed a character and an integer to Activator.CreateInstance(). In the case of the .NET native types like strings and integers, however, if you already know what the value of the object will be, using reflection is overkill. There are far easier ways to translate between one native type and another. -Phil

The System.String type does not have a parameterless constructor (they all require at least one parameter), and therefore cannot be instantiated via the Activator.CreateInstance(Type) method. -Phil

What are the types that you are trying to create, and do they all have public, parameterless constructors? -Phil

Nope, no hacks required. It was designed to look that way. :-) It's C# attribute[^] syntax. .NET allows you to attach additional bits of "metadata" to .NET objects (assemblies, classes, methods, and properties). Other .NET objects (such as the PropertyGrid) can then extract that data for their own purposes (such as displaying descriptions of properties). -Phil

Are you sure your service is being run from the bin\debug folder? Also, does your CamToJ2K.dll have any dependencies that might also need to be copied to that location? -Phil

You can use the DescriptionAttribute[^] class to set the text of the "help frame" of a property grid. In addition, you can use the CategoryAttribute[^] class to group related properties within the grid. -Phil

Look for Visual Studio Tools for Office[^]. -Phil Disclaimer: I work for Microsoft as a developer on the Visual Studio Tools for Office product team.

This doesn't really answer your question, but rather than use inheritance to add functionality to the ListView class, why not create a user control that simply consists of a fully-docked ListView? This way, you can expose a Items collection of any type you wish. Admittedly it's more work, but you end up with a better fitting control (rather than simply tacking on new specific behavior to a very generic control). -Phil

Under what conditions does the UI freeze? Is it a complete freeze, or does the UI respond after some period of time? I noticed in your UpdateList() method that you do not call Patients.EndUpdate() if your update is interrupted; you should probably put that in a finally statement so that it is always called. -Phil

I am by no means a WPF expert, but could it be because both of your controls have the IsSynchronizedWithCurrentItem set to True? You might also try asking the question on MSDN's WPF forum: WPF[^] -Phil

You might check out: Reading Switches from the Parallel Port[^] -Phil

Office applications expose a COM-based object model. If using .NET, they also include PIAs (Primary Interop Assemblies) that wrap the object model in a slightly more .NET-friendly manner. You could use this model to open, extract from, and write to Excel files. See: Excel Object Model[^] -Phil Disclaimer: I work for Microsoft as a developer on the Visual Studio Tools for Office product team.