Well, if you don't have the source for the AFP2PFD.dll and there isn't a 64-bit availble, you have two options.
1) Recompile everything back down to 32-bit because you cannot mix 32- and 64-bit code in the same process.
2) Leave your app as AnyCPU and rework the StiSocket.dll code to load the AFP2PDF.dll in a serperate Process, and write a wrapper around the functionality of the .DLL that will marshal remote calls from your StiSocket.DLL to to the exposed functioanlity of the .DLL.
Frankly, I'd go with number 1.
Unless you've got some 64-bit reason that you absolutely need 64-bit support in your app, your 32-bit-only app will work just fine on a 64-bit machine.
Hello to all,
i finally decided to hide or remove the "Dial.." button from ContextMenuContactItem and add the new button that when i click on my own item button show the telephone numbers that contact righ-clicked and selected. How can i make it? Is there some code but NOT ADDIN EXPRESS (we must pay to use it) or solution to take example how to build it?
Is there someone expert and can help me to build it. I have last one week! And also if i click one of number the event click send the number selected in string format to my own function.
Thanks very much for any help.
I will here every hours!! Thanks!
When creating big applications(even medium apps) there are so many different kinds of exceptions that can come?
How to go about handling them?
And how do prioritize these exceptions?
(We just cannot write a 100 try-catches,can we?)
We divide our whole application into layers , tiers, components etc. for modularity of a functionality. Cant we have a whole layer just to handle exceptions. In that case if we know that an exception is not being handled properly we will know where to go instead of having to browse through the whole code looking for the pertinent error.
Basically you either handle the exception, you ignore it (maybe with a message), or you log it (or combination). If you are logging, then basically you are centralizing the handling of the exceptions. What do you expect to do if you try to centralize the exception handling. That would be extremely complex. There are a number of frameworks for logging. We use log4net: log4net Tutorial[^]
Handle the exceptions you know you can handle as close as possible.
If you have a place no exceptions can be allowed to escape from, catch the root exception type - this will also catch all derived exceptions. But do this catch last, after the exception types you have different handling for.
If all your exception handling does is log an error, you only need to capture the root type.
You should know the .NET framework well enough to know what exceptions a method throws. For example, opening a file may cause an exception if the file doesn't exist, etc. Why would you have an application level exception handler for that? The method that opens the file should pop up a message box saying the file was not found.
Last Visit: 31-Dec-99 18:00 Last Update: 21-Sep-14 10:20