|
we converted the .Net application to work for 64 bit machine. The Problem is with communicating the stiSocket dll to the AFP2pDF dll.
|
|
|
|
|
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.
Thanks!
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?)
|
|
|
|
|
You should never be trying to handle exceptions from the whole application in the same place (apart from a last ditch catch-all to put up a message and log a bug report).
In any individual operation, there should be only one or two possible exceptions that can be thrown. You should catch and handle them appropriately as close as possible to the site of the operation.
|
|
|
|
|
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[^]
|
|
|
|
|
Exceptions are part of the layers where they serve the best purpose, not a layer by itself.
|
|
|
|
|
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.
|
|
|
|
|
On Error Resume Next
SMACK ouch, owe that smarts!
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Phanindra261 wrote: When creating big applications(even medium apps) there are so many different kinds of exceptions that can come?
How to go about handling them?
Ideally by the following
1. Anticipate expected conditions that can result in errors. These of course vary by the area of the application/enterprise in which they appear.
2. Consider what the application/enterprise should do when those occur. This includes how or even if it should be logged.
3. Implement the code based on 1/2
4. Unit test the code of 3, including the exception generation
5. Besides the above boundary layers should ALWAYS assume that unexpected errors will occur. Those exceptions should be caught and logged once (not every layer.) Each layer must determine what the result is when an unexpected exception occurs and what the layer (or specific parts of the layer) do when an unexpected exception occurs.
As an example...
A database layer should always expect that communication errors will occur. There are various ways of dealing with this (which do not matter for this discussion) but they should still be expected. Even a clustered database solution can experience communication failure. Whether this is logged depends on how it is handled but even if the database layer is returning it as a result failure is should not log a stack trace, but just log it as a single error (db comm error.)
A database layer should not normally expect a SQL syntax error. That is something that should normally only occur during development or QA. So if it occurs one must log it. The database layer can handle this as a failed result.
|
|
|
|
|
I have this small feeling that we have more control on our application when we manually code it instead of using a code generator. Is it true?
If so then how often should we use a code generator and to what extent?
If not so then can someone guide me to a good place where I can learn about writing code generators?!
THANK YOU
SATYMEVAJAYATHE
|
|
|
|
|
I never use one, I write all my own code.
|
|
|
|
|
Even *.designer.cs files? 
No more Mister Nice Guy... >: |
|
|
|
|
|
I have on occaision been known to remove them and do my own initialization control. The designer.cs files are handy though 
|
|
|
|
|
And what one would do when decide to open designer of such a form? I would guess that they wouold come to you to punch you
I very often edit them but not remove them, so i guess I am not withbout sin. :p
No more Mister Nice Guy... >: |
|
|
|
|
|
They're not really generated code, they're code which is manually edited using a graphical IDE. That is, every line in a .designer.cs file is there because you set a property or clicked something in the graphical editor.
|
|
|
|
|
You do not wrote it yourself, ergo it's generated.
No more Mister Nice Guy... >: |
|
|
|
|
|
If you write everything from scratch, you will have more control by definition.
If you use a code generator you may (depending on the code generator) get better or more consistent code quality, and you will definitely save time.
|
|
|
|
|
What about the performance issues?
Will the code generator not weigh down the application?
Oh and is there any difference a code generator and a template (for an application)? Also is there a relation between the two?
|
|
|
|
|
All occasions I've seen and used code generation tools, that's been a build-time issue, not run-time. You run the tool to create code, which is included in the compiling and build of the software. As such, there's no performance penalty when running, although it can complicat the build process.
For instance, Microsoft has a tool that takes an XML file and creates an XML schema from it. This schema can then be run through the same tool which can generate C# classes to represent it. This means you don't have to hand code the classes needed to serialise the XML, but have used a code generation tool. Typically, you'd only do this when there's been a change in the XML schema, not every time you build the system.
I'm not entirely clear what you mean by template here? Do you mean the different application and library types you can pick from when creating a new project in Visual C#? Those templates are effectivel recipes used by the code generation tool to create the project and its initial files.
|
|
|
|
|
I very much dislike generated code. If you need so much code to accomplish something that you feel the need to generate it, there is a more fundamental problem that needs addressing, perhaps in the language or choice of technology.
I don't include code which is generated from a non-text editor, like WinForms designer files or WPF/Silverlight XAML. You're still in charge of that, it's just the text editor isn't your usual editing environment. But the abominations that Microsoft create for you when you communicate with a COM or WCF server are fairly clear indications that they need to provide better tools to access those technologies.
|
|
|
|
|
The more experienced a developer is, the less likely they are to use any kind of generator.
Snippets as templates will get used, but not generated code.
I wasn't, now I am, then I won't be anymore.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
