Christian Graus wrote:

Steve Mayfield wrote: I'm not sure if you can develop and sell products produced with the Express versions.. Yes, you can

Are you sure!?! I thought the Express versions were strictly for non-commercial development.

I use do...while on occasion. It's actually a useful loop that ensures code is performed at least once. Certainly you can always do the same loop using a standard while loop, but often it increases readability and comprehension.

Member 4044988 wrote:

do you have any idea that how i can get path of office applications.

None at all, sorry.

Member 4044988 wrote:

i am not getting the api which can show the path of office application.

http://www.microsoft.com/downloads/details.aspx?FamilyId=135F4D99-F480-4A81-AF8F-F6E4896611E2[^], I'm refering to this (and obviously the 2007 version as well).

No problem. Your english is VERY good, certainly better than my other languages :)

I don't know how you'd do it for all applications, however for office applications there is a specific programming api. Have a look in there. The only other piece of information I can suggest is watching disk activity; there are certainly applications out there that show which processes are accessing which files. That's the best I can do i'm afraid, sorry and good luck, Derek Bartram.

That's VERY difficult. I'll have a think, however I seriously doubt i'll be able to do that. Do you need the path of the open file for all applications (e.g. internet explorer, notepad, etc., or just word)

Yes. Although perhaps also in terms of code style.

foreach (Process p in System.Diagnostics.Process.GetProcesses()) {

Member 4044988 wrote:

physical location

System.Diagnostics.Process.GetCurrentProcess().MainModule.FileName

Member 4044988 wrote:

size of application

FileInfo class will give you that once you have the FileName }

MidwestLimey wrote:

I once worked on a project where the Project Lead insisted on try catch blocks in every bloody method.

That sounds a little overkill, however generally I do use try...catch blocks in all my gui event handlers so that application is a little more useful when something does go wrong.

MidwestLimey wrote:

I did some performance testing and could determine definitive costs with the setup and teardown of the block, but was unable to measure any discernable difference to the code internally. However the code was entirely managed, perhaps wrapping unmanaged code has other implications.

Thank you for that, personally that is of great interest. I'm actually in the middle of writing a series of articles on language performance so hopefully i'll be able to give further insite on this. Many thanks, Derek Bartram

Firstly, from above //writer is a stream writer to a file.. try { writer.Write("Hello"); } catch (Exception err) { //handle error } In this case you couldn't test for every possible error as some are far out the scope of plausible; e.g. can't access the file as it was on a removable drive that was just unplugged. George_George wrote: "not controlling programming flow"? //slider is a silder whos value is 0 to 100 double y = 100.0 / slider.Value then try { double y = 100.0 / slider.Value } catch (Exception) { //handler exception } is a bad way to write this code (remembing slider.Value could be 0 causing divide by 0 exception), a better way would be.... if (slider.Value != 0) { double y = 100.0 / slider.Value } else { handle error }

George_George wrote:

What do you mean "didn't specify 'massive' which didn't help"

It's all very well saying massive improvement or whatever, but if you don't give some quantative value or referance, massive has no meaning (it could save 0.1ms which in terms of clock cycle is alot, but probably less significant to compared to a complex if statement).

Yes. A breakpoint on the err.GetType() line will give you further information as well however.

The point is sample two doesn't throw an exception but rather just run a different section of code. An if statement inherinatly has less overhead than that of a try...catch statement. Certainly both will perform exactly the same function however the second will run more efficiently and quicker.

See above. I don't know the answer, but use the proceedure above will tell you how to find out.

George_George wrote:

But confused what means "catching untestable errors"

//writer is a stream writer to a file.. try { writer.Write("Hello"); } catch (Exception err) { //handle error } In this case you couldn't test for every possible error as some are far out the scope of plausible; e.g. can't access the file as it was on a removable drive that was just unplugged.

George_George wrote:

"not controlling programming flow"?

//slider is a silder whos value is 0 to 100 double y = 100.0 / slider.Value then try { double y = 100.0 / slider.Value } catch (Exception) { //handler exception } is a bad way to write this code (remembing slider.Value could be 0 causing divide by 0 exception), a better way would be.... if (slider.Value != 0) { double y = 100.0 / slider.Value } else { handle error }

Sorry, I really don't know. Something unicode based is what you're looking for though I think. Personally I would say stop using *nix, but then i'm sure you have a good reason not too (otherwise i'll bash your head in with a really big book :mad:).

perhaps unicode?

Thanks for the link, an interesting article. I probably didn't specify 'massive' which didn't help; I meant relative to performing an if test to prevent the exception.

Crikey sounds complicated! Good luck.

Yes.... run the code with catch (Exception err) and output err.GetType() somehow (Console.WriteLine will do). You'll then know the type of the exception raised so you can go back and modify catch (Exception err) to the specific type.

I've just done some googling on the subject (and confirmed via a lecturer from Uni).... 1) There is a performance hit running code inside a try...catch block but it's negligable 2) There is a BIG performance hit when an exception occurs So, 3) Use try...catch for only catching untestable errors and not controlling programming flow. http://www.javaworld.com/javaworld/javaqa/2001-07/04-qa-0727-try.html[^] http://aspadvice.com/blogs/name/archive/2008/01/18/Try-Catch-Performance-in-CSharp_3A00_-A-Simple-Test-Response.aspx[^]