|
First, please put large code snippets like this inside of <pre> tags to keep the formatting and help make it more readable.
try
{
MethodthatraisesException();
}
catch (ExceptionA e1)
{
LogMessage(e1);
}
catch (ExceptionB e1)
{
LogMessage(e1);
}
try
{
MethodthatraisesException();
}
catch (ExceptionA e1)
{
LogMessage(e1);
} There are some differences in runtime behavior between these. In the second example, you will only catch exceptions of type ExceptionA and anything derived from it. So, if ExceptionB is derived from ExceptionA this will work, if not you'll only catch one of the exceptions.
That being said, in your examples, you are "eating" the error. You catch the exception, log it, but don't pass it up the chain by calling throw(); to rethrow the exception. This may be what you want, but generally you should only catch an exception if you can do some meaningful cleanup work as a result; if not, let the exception bubble up to whoever is interested.
There really aren't any differences in performance between the two. The runtime still has to perform a stack walk all the way up the chain looking for something that will handle the exception.
|
|
|
|
|
If ExceptionB is derived from ExceptionA then both samples will work in the same way, because an ExceptionB will be cathced in the first sample by the first catch block, too. To catch them seperately, the catch blocks have to be switched.
-^-^-^-^-^-
no risk no funk ................... please vote ------>
|
|
|
|
|
Urs Enzler wrote: If ExceptionB is derived from ExceptionA then both samples will work in the same way
Right, that's what I said:
In the second example, you will only catch exceptions of type ExceptionA and anything derived from it. So, if ExceptionB is derived from ExceptionA this will work, if not you'll only catch one of the exceptions.
Urs Enzler wrote: To catch them seperately, the catch blocks have to be switched.
Yes, given the first code sample and making the supposition that ExceptionB is derived from ExceptionA , the catch blocks would need to be in the opposite order. However, the original post stated that both exceptions were derived from ApplicationException , so the catch blocks would work correctly in either order. Again, the second example will only provide the same behavior if ExceptionB is derived from ExceptionA , which was one of the original questions.
|
|
|
|
|
I'd like to write a bit of C#/.Net that will generate text in a JPG format. I'm looking for any built-in-bits of .NET that will help me do this. Or, some sample code.
What I'm doing: I want to generate "album cover" JPG's to use on my iPod - but I don't want actual cover art. I just want a square, solid color background with the name of the Artist and the Album title printed on it, in colored text.
Since I have over 1000 albums, I'd like to generate this JPG algorithmically.
I would settle for a fixed font size, with truncation of long Artist or Album Name, but it would be nice if the text scaled to fit into the rectangle.
Thanks in Advance,
JoeRip
|
|
|
|
|
Take a look at the static method Graphics.FromImage() . Graphics.MeasureString() and
Graphics.DrawString() will handle the sizing and text overlay. There are a lot of properties that can handle smoothing and anti-aliasing of the text.
Sorry, I don't know of any existing source.
|
|
|
|
|
I see, you are suggesting that I load an existing JPG of my rectangle, and draw text on that. Sounds do-able.
However, I don't see any methods in the Graphics class for writing the JPG back out as a file. Am I looking in the wrong place? What do you suggest?
|
|
|
|
|
|
Do I really need to work with the Graphics class? I won't be displaying these images within my application... or do I still need to use a Graphics object, just to composite my text onto my background?
|
|
|
|
|
I suppose you could manipulate the bitmap bits directly but, the graphics class makes writing text trivial.
|
|
|
|
|
What Michael suggested is IMO the right approach:
1. create an empty Bitmap of the required size (alternatively load a background image from
a file)
2. get a Graphics object that provides access to that Bitmap
3. draw whatever you like to that Graphics (exactly as if you were painting to a window,
but this Graphics represents the memory-based bitmap)
4. finally save the Bitmap
If you want to show the final result on screen, you could use a PictureBox (set its Image
property) or just do Graphics.DrawImage() in the Paint handler of your Form, or some
other Control on it (I would use a Panel, I don't like PictureBox at all).
Luc Pattyn [Forum Guidelines] [My Articles]
this weeks tips:
- make Visual display line numbers: Tools/Options/TextEditor/...
- show exceptions with ToString() to see all information
- before you ask a question here, search CodeProject, then Google
|
|
|
|
|
JoeRip wrote: or do I still need to use a Graphics object, just to composite my text onto my background?
Yes
using (Bitmap newAlbumArt = new Bitmap(width, height, PixelFormats.Format24bppRgb))
{
using (Graphics gfx = Graphics.FromImage(newAlbumArt))
{
gfx.FillRectangle(Brushes.White, newAlbumArt.Width, newAlbumArt.Height);
gfx.DrawString("Album Title", x, y);
}
newAlbumArt.Save(path, ImageFormats.Jpeg);
}
|
|
|
|
|
Dear All i have a problem with .NET IDE that is all of my control i placed on my forms in ASP.NET web pages, they all are floating control means i could place them any where like control on VB.Net , and if i want to insert control with in a container then also the control behaves like the individuals. so plz help how to i solve the prob.
Thanks you
|
|
|
|
|
There's a property of the page which you can changed from Grid layout to Flow layout which will do what you want. But I can't remember what it's called.
|
|
|
|
|
|
I belive that the runtime is mostly C++, as for the base class libaries they are all C#.
|
|
|
|
|
Are you're looking for what technologies are used inside the framework? If so, there are a lot of different things being used.
The underlying "core" of the runtime (the JIT (Just In Time) compiler, global assembly cache (GAC), assembly loader (Fusion), the garbage collection system (GC) and memory management, plus some others) are all written in C/C++.
The Base Class Library (BCL) and Common Type System (CTS) are all written using managed code. However, a lot of these classes eventually make platform invoke (P/Invoke) calls into unmanaged code (generally the Win32 APIs). This is true even of the Windows Forms classes. This does mean that there is still some COM that ends up getting used, but I believe that it is not a lot.
|
|
|
|
|
I have written a class that allows our application to manipulate the default printer of a workstation. The code below works perfectly on WinXP but not on Win2000...
ManagementObjectSearcher search = new ManagementObjectSearcher("select deviceid from win32_printer where default = TRUE");
Any suggestions?
|
|
|
|
|
I can't seem to find anything on the net about how IPC remoting works. What is the role of the server? What is the role of the client? How does each get/set data in the shared class? What are the criteria for access? What is the meaning of liquid soap?!
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997 ----- "...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
So, john, which version are you using? VS2005/.net3.0 pretty much replaced the VS2003/Net2.0 remoting infrastructure with the WCF framework. The earlier remoting framework was more tightly coupled than WCF.
Generally speaking the server would be the class factory for the remoted class instances: clients would get remote instances from the server. (in WCF/SOA talk the server would provide services that the client was interested in using, rather than act as a class factory).
SOAP is just a protocol for messaging between web (or WCF) servers. The WCF uses a binary infoset implementation, previous (and all non-ms frameworks) use xml infoset based SOAP.
|
|
|
|
|
It's .Net 2.0, so no WCF. I'm going to try using a IPChannel.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997 ----- "...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
I'm not sure this will answer your questions, but here goes.
Remoting works, more or less loosely described, by creating a proxy class as defined by an interface. Through a complicated .NET process, you can intercept the call to a method or property getter/setter (which are methods) and pretty much do anything you like, including serializing the object between a client and a server and executing the method remotely, as if the object were actually local to the client.
The role of the server is to instantiate one (and only one, in singleton mode) object, or, one (and every time one) object in "per call instance" mode. You have to be careful with these, as neither does what you want, usually, which is to have multiple instances for the lifetime of your choice. You therefore typically have a singleton factory class at the server that creates objects as you request them.
The data gets shared typically using .NET's binary formatter. Be careful of that. It's not meant for heavy work. It's slow and consumes lots of memory for large objects.
There are no restrictions to access, you just have to have the methods and getters/setters defined in an interface, and you work with the interface at the client.
Beware of problems with breaking the connection. It can take the OS up to 3 minutes to realize the port is no longer in use. In the meantime, you'll get "port is in use" exceptions if you try to restart the server.
You might look at my article on remoting[^] as it covers a lot of things.
Liquid soap? You mean "Simple Object Access Protocol"? Well, here's an article.[^] Maybe that helps. SOAP is used primarily by web services, I believe, over port 80. .NET remoting is not restricted to HTTP nor port 80.
Marc
|
|
|
|
|
The two apps will be on the same computer, so I was planning on just using a IPCChannel. The communication will be between an windows app (the server) and a service (the client). The server will post a delimited string, and the client will be checking the shared object every 5 seconds or so for a new string (comparing it against the last one it processed). My needs are (in my eyes) simple.
I just found a sample project on Tech Republic that I'm gonna check out.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997 ----- "...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
John Simmons / outlaw programmer wrote: The communication will be between an windows app (the server) and a service (the client).
Hmmm. Usually, one uses the terms "service" and "server" together, and the terms "client" and "windows app" together. A remoting server is often implemented as a service. Are you sure you have these ideas right?
John Simmons / outlaw programmer wrote: My needs are (in my eyes) simple.
Yeah, that's quite simple, however, you're mixing concepts here. Remoting does not use shared memory. What you're describing sounds like you're thinking you could just set up a shared memory object between the two apps.
If you use remoting, then the delimited string would most likely use a property setter. In the implementing class, you could have an event fire to process the string, rather than using a timer to check if it's changed.
Marc
|
|
|
|
|
I was going to describe the processing logic and came to the realization that the service doesn't have to be (and maybe should NOT be) a service. It could be a GUI app or a console app.
In any case...
1) The server app waits for a file to be written.
2) When the file is done being written, the server app posts a delimited string in the shared object.
3) The service (or client app) polls the shared object until the string it retrieves in different from the last one it processed.
4) It processes the string, and then returns to polling the shared object.
Items of note:
The client processes the string (much)faster than the server can indicate that a new file is written (we're talking anywhere from 4-50gb file sizes).
The client needs to be able to handle the server not running at any given time.
I have some code written, but the server and client don't seem to be talking to each other. I'm going to move away from the client "service" paradigm for easier debugging and see what happens. Running as a service introduces security concerns on Vista that I may not be handling correctly.
I'll start a new message thread if I can't get it working.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997 ----- "...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
John Simmons / outlaw programmer wrote: 1) The server app waits for a file to be written.
Not sure if I will be correct since the "where, how, by what, in response to what", a file is written I do not know, but...
John Simmons / outlaw programmer wrote: 2) When the file is done being written, the server app posts a delimited string in the shared object.
3) The service (or client app) polls the shared object until the string it retrieves in different from the last one it processed.
4) It processes the string, and then returns to polling the shared object.
It does not strike me that Remoting is the most appropriate solution for that scenario. Have you considered using message queues?
|
|
|
|
|